I was following the handbook in trying to create a backup of the whole filesystem of a system that I had installed & configured. I ran into an issue when trying to send/receive the snapshot of the datasets.
If a user takes a recursive snapshot of an entire pool, such as with
test-system1# zfs snapshot -r zroot@TEST
and then sends that to a second ZFS system, such as with
test-system1# zfs send -vR zroot@TEST | ssh test-system2 zfs recv -Fdvu zroot/TEST/test-system1_zroot
the resulting datasets on the receiving side will have mountpoints that are exactly the same as some of the datasets that already exist. ZFS does not warn about this and upon a reboot, important datasets will be masked. This requires booting into a livecd and manually changing the mountpoints so that they are no duplicates. This has happened to me before and I think there should be at least a warning in the handbook so that users who are not familiar with ZFS are aware of this danger.
I spoke to Allan Jude about this at BSDCan 2016 and he responded positively to making this change. I am happy to submit a patch, I have attended 2 of the Doc Sprints at BSDCan 2016 and I will be familiarizing myself with the process of submitting a patch for documentation.
Please change the assignee to me.
Bug assignment set to Allan Jude. At this time, I don't believe setting bug assignment to non-committers is permitted.
My understanding of the theory of only assigning PRs to committers is that non-committers are not actually able to effect changes to the source code. I hope that having the Submitter in the Cc: field will be sufficient.
Hi Jason, Mark
Thanks for the clarification. I just wanted to indicate that I am taking responsibility for this proposed change.
I will learn how to submit a patch to phabricator, it's my first time using that site. I have an account set up and a rough idea of the warning I would like to add, I will update this bug within the next few days with a proposed patch.
Looks like others have had this issue too.
junovitch made a good point, I will format the post for addition into the handbook.
There's the documentation issue, but there's also the actual behavior that could use some POLA improvement. It would be nice (tm) if zfs would refuse to mount over itself, with a rule of "If <path> is mounted from a ZFS dataset, refuse to mount a different dataset at <path>". If you have two zpools attached where both have a filesystem with mountpoint='/' and canmount='on', you are in for some excitement at your next boot. (And as described above, you can easily create this situation with send/recv.)
I typically keep my backup destination in an altroot for just this reason, but I accidentally imported it manually (without my scripted altroot setup), at one point, and it's a comedy of errors from that point. Nothing permanently broken, just painful. Having a standard way to persist altroot settings could be helpful...
Or am I missing something? I can open a separate item if this seems like a reasonable behavior to change. If bug #173234 ever got resolved, it would be another option to avoid these situations without impacting the mounting behavior.