Replication target datasets mounted ro in FreeNAS-9.3-STABLE-201602020212 and newer

[MrToddsFriends]

After updating to FreeNAS-9.3-STABLE-201602020212 the security run output mail of my filter pointed out that all datasets on the pool that I'm using as replication target are mounted ro after this update.

Code:

blunzn.local changes in mounted filesystems:
[...]
< volrep/common        /mnt/volrep/common    zfs    rw,nfsv4acls     0 0
---
> volrep/common        /mnt/volrep/common    zfs    ro,nfsv4acls     0 0

and so on for all other datasets that are replicated to the volrep pool. Just now I checked if these datasets are really mounted ro (the box was updated to FreeNAS-9.3-STABLE-201602031011 in the meantime)

Code:

scr@blunzn:~ % mount | grep volrep/common
volrep/common on /mnt/volrep/common (zfs, local, read-only, nfsv4acls)

The replication tasks seem to have done their work as if no change in mounting had happened (no error messages, new snapshots are there on the PULL side). The questions that arise for me are:

1. Why was this change to ro mounting made in FreeNAS-9.3-STABLE-201602020212?
2. Why are my replication tasks able to do their work unperturbed by this change?

Thanks for any insight on this.

 

[MrToddsFriends]

Hmm, the info shown by the native zfs(8) tool is consistent with the one shown by mount:

Code:

scr@blunzn:~ % zfs list -o name,mountpoint,mounted,readonly volrep/common
NAME           MOUNTPOINT          MOUNTED  RDONLY
volrep/common  /mnt/volrep/common      yes      on

So this doesn't answer my questions.

 

[dlavigne]

Does updating to 201602031011 fix it?

 

[MrToddsFriends]

Does updating to 201602031011 fix it?

The situation is the same in FreeNAS-9.3-STABLE-201602031011. In fact the mount and zfs list commands shown above were executed on that version. Sorry for being unclear.

So far I don't know if a problem exists or if I simply don't understand the mechanism --- ro mounting of datasets on one hand and creation of replicated snapshots (PULL) on these datasets on the other.

Code:

scr@blunzn:~ % zfs list -t snapshot -o name,creation | grep volrep/common | tail -6
volrep/common@auto-20160208.0600-2w                            Mon Feb  8  6:00 2016
volrep/common@auto-20160208.1200-2w                            Mon Feb  8 12:00 2016
volrep/common@auto-20160208.1800-2w                            Mon Feb  8 18:00 2016
volrep/common@auto-20160209.0600-2w                            Tue Feb  9  6:00 2016
volrep/common@auto-20160209.1200-2w                            Tue Feb  9 12:00 2016
volrep/common@auto-20160209.1800-2w                            Tue Feb  9 18:00 2016

Maybe I should have said in my initial posting that replication is done locally within a single FreeNAS box.

 

[depasseg]

I think it makes sense for replication targets to be mounted read only. This avoids the situation where 2 folders get out of sync, and the changes on the replication target get overwritten.

There were some issues (and I believe bugs open) where the fact that replication target being mounted read-write caused problems.

Since ZFS operates at a level lower, the fact that it's mounted as read-only doesn't affect the ZFS replication tasks.