openebs / mayastor

Dynamically provision Stateful Persistent Replicated Cluster-wide Fabric Volumes & Filesystems for Kubernetes that is provisioned from an optimized NVME SPDK backend data storage stack.
Apache License 2.0
735 stars 106 forks source link

Shared snapshot should be read-only #699

Closed exalate-issue-sync[bot] closed 3 years ago

exalate-issue-sync[bot] commented 3 years ago

A snapshot shared over nvmf:

# nvme id-ctrl /dev/nvme20
NVME Identify Controller:
vid       : 0
ssvid     : 0
sn        : 33' ~'~._`o##o>     
mn        : Mayastor NVMe controller                
fr        : 20.10.1 
...
sgls      : 0x100005
mnan      : 0
subnqn    : nqn.2019-05.io.openebs:00000000-76b6-4fcf-864d-1027d4038756-snap-1601481116
ioccsz    : 260
iorcsz    : 1
icdoff    : 0
ctrattr   : 0
msdbd     : 1
ps    0 : mp:0.00W operational enlat:0 exlat:0 rrt:0 rrl:0
          rwt:0 rwl:0 idle_power:- active_power:-

appears as read/write to Linux:

# lsblk /dev/nvme20n1
NAME         MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme20n1     259:44   0  64M  0 disk 
├─nvme20n1p1 259:45   0   4M  0 part 
└─nvme20n1p2 259:46   0  59M  0 part 

This also feeds through to the Nexus when the snapshot is added as a child of the Nexus and the Nexus is published over nvmf. This can help when mounting some filesystems in a snapshot so that it does not attempt to replay its journal. From mount(5):

      -r, --read-only
              Mount the filesystem read-only.  A synonym is -o ro.

              Note that, depending on the filesystem type,  state  and  kernel
              behavior,  the  system may still write to the device.  For exam‐
              ple, ext3 and ext4 will replay the journal if the filesystem  is
              dirty.   To  prevent  this kind of write access, you may want to
              mount an ext3 or ext4 filesystem with the  ro,noload  mount  op‐
              tions  or set the block device itself to read-only mode, see the
              blockdev(8) command.
exalate-issue-sync[bot] commented 3 years ago

Jonathan Teh commented:

NVMe has Namespace Write Protection (section 8.19 in the NVMe 1.4 spec) but it appears SPDK, 20.10 at least, doesn't support it:

# nvme id-ctrl /dev/nvme0n1 -H
NVME Identify Controller:
vid       : 0
ssvid     : 0
sn        : 33' ~'~._`o##o>     
mn        : Mayastor NVMe controller                
fr        : 20.10   
rab       : 6
ieee      : 000000
cmic      : 0xb
  [3:3] : 0x1   ANA supported
  [2:2] : 0     PCI
  [1:1] : 0x1   Multi Controller
  [0:0] : 0x1   Multi Port
...
nwpc      : 0
  [2:2] : 0     Permanent Write Protect Not Supported
  [1:1] : 0     Write Protect Until Power Supply Not Supported
  [0:0] : 0     No Write Protect and Write Protect Namespace Not Supported
exalate-issue-sync[bot] commented 3 years ago

Jonathan Teh commented:

Mounting an XFS filesystem requires the flags ro,norecovery, even if it was cleanly unmounted:

       norecovery
              The filesystem will be mounted without running log recovery.  If
              the filesystem was not cleanly unmounted, it is likely to be in‐
              consistent when mounted in "norecovery" mode.  Some files or di‐
              rectories may not be accessible because  of  this.   Filesystems
              mounted "norecovery" must be mounted read-only or the mount will
              fail.
exalate-issue-sync[bot] commented 3 years ago

Origination: MayaData Jira, issue null

GlennBullingham commented 3 years ago

Cleanup: Closing manually since the automation of jira<->github synchronisation has been suspended and this issue will receive no further updates.