zfs receive -u shouldn't mount received filesystem, right?

uisge

uisge

Hi --

I'm trying to send one server's content to another server by applying:

Code: 
zfs send -R zpool@SAVEME | ssh user@otherserver zfs receive -vFdu zpool/BACKUP

According zfs(8) I did expect that ...

Code: 
|      zfs receive [-vnFu] [-d | -e] filesystem
[...]
|         -u      File system that is associated with the received stream is
|                 not mounted.

... wouldn't mount received filesystems, but I do see e.g. ...

Code: 
| zpool/BACKUP/usr       643M  1.23T   642M  /usr

... plus all other filesystems sent, accordingly.

What am I misunderstanding? Shouldn't the "-u" switch omit mounting zpool/BACKUP/usr/local at all? I do need such functionality, otherwise those mounted directories will render my receiving server unusably ... "zfs library not found"

This is 9.1-RELEASE.

Thanks.
 
-R

Generate a replication stream package, which will replicate the specified filesystem, and all descendent file systems, up to the named snapshot. When received, all properties, snapshots, descendent file systems, and clones are preserved.

If the -i or -I flags are used in conjunction with the -R flag, an incremental replication stream is generated. The current values of properties, and current snapshot and file system names are set when the stream is received. If the -F flag is specified when this stream is received, snapshots and file systems that do not exist on the sending side are destroyed.
Click to expand...

The current values of properties, and current snapshot and file system names are set when the stream is received. What will occur, when mounted property on receiving side will be restored?
 
ondra_knezour said:
The current values of properties, and current snapshot and file system names are set when the stream is received. What will occur, when mounted property on receiving side will be restored?
Click to expand...

I do understand the manual page, that all properties including mountpoint are sent by "-R", but I do also understand that by using "-u" while receiving the filesystem will not be mounted although there is a property mountpoint sent. Wrong?

Well, I will try to get rid of "-R" then.
 
I think -u means that the file system won't be mounted once received. Not sure what happens on export/import or reboot, though.
The mountpoint is just a property, indicating where it'll be mounted to when that happens.
 
You can import the pool at the receiving end with altroot set to let's say /mnt so the directory hiercarchy will be rooted at /mnt:

# zpool import -R /mnt zpool

Or import the pool without modifying altroot but tell zpool(8) not to mount any filesystems:

# zpool import -N zpool

Edit: Do you have a separate ZFS pool for back ups at the receiving end? If you're receiving the back up on the system pool ignore my advice.
 
Savagedlight said:
I think -u means that the file system won't be mounted once received.
Click to expand...

Yes, that's my interpretation of the manual page as well.

Savagedlight said:
The mountpoint is just a property, indicating where it'll be mounted to when that happens.
Click to expand...

But in my case the filesystem is being mounted after receival, although the "-u" should prevent that:

Code: 
Source at sending server:
zpool/usr              643M  1.23T   642M  /usr

After receival:
zpool/BACKUP/usr       643M  1.23T   642M  [B]/usr[/B]

In the end I will end up with a server having two /usr mountpoints, one "belonging" to the receiving server, and one mounted "on top" of that mountpoint by zfs receive.

That will render my receiving server unusably. I will get a "zfs library not found" for every command applied, afterwards. I am unsure whether my interpretations are correct, but I need to find a way (besides rsync) to prevent sent filesystems from being mounted upon receival. Any help will is highly appreciated.
 
kpa said:
# zfs set canmount=noauto zpool/BACKUP
Click to expand...

Yesterday, I did try # zfs set mountpoint=none zpool/BACKUP but that didn't work out. I was already thinking about creating the complete filesystem tree and setting all filesystems to mountpoint=none or mountpoint=/BACKUP/...

But, thanks, I will give it a try (tonight).
 
Code: 
| zpool/BACKUP/usr       643M  1.23T   642M  /usr

This is the output from a zfs list showing the mountpoint property, but is the file system actually mounted? I've just tested on a 9.0-RELEASE system and it works as expected. The mountpoint property is sent with the snapshot, but the file system is not mounted and does not appear in mount or df output.

The problem you probably will have though is that it may well get mounted if the backup system reboots (big flaw with -u really, they should of made this option modify the canmount property directly). As kpa says, the easiest way to fix that is to set canmount=noauto/off on the backup system. As far as I'm aware, this will only need doing the first time when the backup file system is first created. I also usually suggest setting readonly=on so that you don't accidently change the backup, stopping incremental sends from working.

Oracle ZFS has had a -o option for zfs recv for quite a while now which allows setting properties such as canmount/compress/etc on the fly as part of a receive. I thought this was old enough that it's in the open version as well but doesn't look like it, hopefully it'll be added at some point, it's extremely useful.
 
usdmatt said:
Code: 
| zpool/BACKUP/usr       643M  1.23T   642M  /usr

This is the output from a zfs list showing the mountpoint property, but is the file system actually mounted?
Click to expand...

Yes, it is, checked with mount and df.

I've just tested on a 9.0-RELEASE system and it works as expected. The mountpoint property is sent with the snapshot, but the file system is not mounted and does not appear in mount or df output.
Click to expand...

Interesting. I am struggeling at 9.1-RELEASE.

The problem you probably will have though is that it may well get mounted if the backup system reboots
Click to expand...

Yes. That is an issue I would have run into if I wouldn't have failed before ;-) I just didn't think about that. So, thanks to everybody mentioning it.

I also usually suggest setting readonly=on so that you don't accidently change the backup, stopping incremental sends from working.
Click to expand...

I did so already. Although I do not understand why one should do so ;-)
 
I just independently/accidentally recreated @uisge's original scenario. I was trying to send a copy of my root filesystem to a child filesystem with the following:

sudo zfs send -vR zroot@tobeadm | sudo zfs recv -vduF zroot/ROOT/91_01102013

zroot/ROOT has no @tobeadm snapshots so it is not recursively sent. My plan was to do the send with the filesystems under zroot/ROOT temporarily unmounted, and then immediately change the mountpoint of zroot/ROOT/91_01102013 so that I won't have it mounted at / upon reboot.

Unfortunately, zfs recv DID mount over my live /, leaving empty mountpoints for /usr, /lib, /proc, /dev, etc., and thus a mostly non-functional machine.

The question is, is this a bug, or is @ondra_knezour's interpretation correct? Expecting the user to know that the mountpoint property needs to be sent separately and that zfs recv setting this will mount the filesystem even despite -u seems excessively tricky. I feel this should at least be clarified in the man page.
 
Last edited by a moderator:
I have prevented this behaviour by first making sure to: # zfs set canmount=noauto zfs/filesystem.

On all filesystems, this property does not seem to "like" inheritance for some reason. You can have ZFS mountpoints set but you also need to add entries in fstab for them to get mounted on reboot in the sending, source system. And to zfs recv with -u. Having canmount=noauto and manual fstab entries could cause problems with other techniques, like beadm, so beware.

When all else fails, set
Code: 
mountpoint=legacy (or none)
on the receiving, destination system.

/Sebulon
 
Thanks for the workaround, @Sebulon.

I was interested in whether or not this is a bug, so I compared behavior with OmniOS (http://omnios.omniti.com). It seems that OmniOS behaves as @uisge and myself originally expected, leading me to believe that this is actually a bug in FreeBSD's ZFS. (I.e., received filesystems are unexpectedly mounted with "-u" on FreeBSD, but are not mounted on OmniOS.)

Unless anyone here thinks I shouldn't, I'll hopefully get some time and submit a bug report.
 
Last edited by a moderator:
Re: zfs receive -u shouldn't mount received filesystem, righ

Did you ever submit a PR for this? If so, what was the number?
 
Problem still occurs.

For example

Code: 
[root@FreeBSD ~]# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot               5.79G  11.5G    96K  /zroot
zroot/ROOT          2.38G  11.5G    96K  none
zroot/ROOT/default  2.38G  11.5G  2.38G  /
zroot/tmp            224K  11.5G   144K  /tmp
zroot/usr           3.41G  11.5G    96K  /usr
zroot/usr/home       156K  11.5G   156K  /usr/home
zroot/usr/ports     2.87G  11.5G  2.87G  /usr/ports
zroot/usr/src        548M  11.5G   548M  /usr/src
zroot/var            808K  11.5G    96K  /var
zroot/var/audit       96K  11.5G    96K  /var/audit
zroot/var/crash       96K  11.5G    96K  /var/crash
zroot/var/log        236K  11.5G   156K  /var/log
zroot/var/mail       188K  11.5G   116K  /var/mail
zroot/var/tmp         96K  11.5G    96K  /var/tmp

Code: 
zfs send -Rv zroot@replica1 | ssh root@gentooqa zfs recv -vudF freebsd

Code: 
GentooQA_ZFS / # zfs list
NAME                            USED  AVAIL  REFER  MOUNTPOINT
freebsd                        4.28G  15.0G    19K  /zroot
freebsd/ROOT                   1.96G  15.0G    19K  none
freebsd/ROOT/default           1.96G  15.0G  1.96G  /
freebsd/tmp                      32K  15.0G    32K  /tmp
freebsd/usr                    2.32G  15.0G    19K  /usr
freebsd/usr/home               36.5K  15.0G  36.5K  /usr/home
freebsd/usr/ports              1.94G  15.0G  1.94G  /usr/ports
freebsd/usr/src                 389M  15.0G   389M  /usr/src
freebsd/var                     156K  15.0G    19K  /var
freebsd/var/audit                19K  15.0G    19K  /var/audit
freebsd/var/crash                19K  15.0G    19K  /var/crash
freebsd/var/log                  58K  15.0G    58K  /var/log
freebsd/var/mail                 22K  15.0G    22K  /var/mail
freebsd/var/tmp                  19K  15.0G    19K  /var/tmp
tank                           25.4G   104G    96K  /
tank/gentoo                    21.1G   104G    96K  /gentoo
tank/gentoo/home                116K   104G   116K  /home
tank/gentoo/portage            5.85G   104G  1.06G  /usr/portage
tank/gentoo/portage/distfiles  3.05G   104G  3.05G  /usr/portage/distfiles
tank/gentoo/portage/packages   1.74G   104G  1.74G  /usr/portage/packages
tank/gentoo/root               14.0G   104G  14.0G  /
tank/gentoo/src                1.26G   104G  1.26G  /usr/src
tank/swap                      4.25G   107G  1.29G  -
 
The mountpoint may have been set but this doesn't mean it's actually mounted. What's mounted set to and what does mount(8) say?
 
You must log in or register to reply here.
Back
Top