Bug 210222

Summary:	FreeBSD Handbook: add warning about ZFS silently masking datasets with the same mount points when recursively sending/receiving the root dataset
Product:	Documentation	Reporter:	Manas B <email>
Component:	Books & Articles	Assignee:	Allan Jude <allanjude>
Status:	Open ---
Severity:	Affects Some People	CC:	allanjude, doc, eborisch+FreeBSD, email, gardose2, mav
Priority:	---	Keywords:	honeypot, needs-patch, needs-qa
Version:	Latest
Hardware:	Any
OS:	Any

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

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.

Comment 7 eatandrunpolice123 2023-09-20 10:12:13 UTC

MARKED AS SPAM

Comment 8 krisitina 2023-09-25 07:15:37 UTC

MARKED AS SPAM

Comment 9 cydia impactor 2023-09-25 09:35:55 UTC

MARKED AS SPAM

Comment 10 Graham Perrin freebsd_committer

2023-10-17 11:33:02 UTC

Is what was true in 2016 true with OpenZFS in 2023?

^Triage: 

* summary (no longer 19.4.7.2; numbering within the FreeBSD Handbook has changed)
* status
* keywords
* make former assignee doc@ a CC recipient