Bug 210222 - 19.4.7.2. -- Add warning about ZFS silently masking datasets with the same mountpoints when recursively sending/receiving the root dataset
Summary: 19.4.7.2. -- Add warning about ZFS silently masking datasets with the same mo...
Status: New
Alias: None
Product: Documentation
Classification: Unclassified
Component: Documentation (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Allan Jude
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-11 21:52 UTC by Manas B
Modified: 2016-08-24 14:16 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manas B 2016-06-11 21:52:40 UTC
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.
Comment 1 Manas B 2016-06-11 22:00:11 UTC
Please change the assignee to me.
Comment 2 Jason Helfman freebsd_committer 2016-06-12 17:09:01 UTC
Bug assignment set to Allan Jude.  At this time, I don't believe setting bug assignment to non-committers is permitted.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2016-06-13 16:01:37 UTC
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.
Comment 4 Manas B 2016-06-13 16:09:48 UTC
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.

Thanks,
Manas
Comment 5 Manas B 2016-07-28 05:12:59 UTC
https://forums.freebsd.org/threads/28010/

Looks like others have had this issue too.

junovitch made a good point, I will format the post for addition into the handbook.

Thanks,
Manas
Comment 6 eborisch+FreeBSD 2016-08-24 14:16:11 UTC
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.