zfs discuss - Jul 2008 - Replicating ZFS filesystems with non-standard mount points

I have 4 filesystems in a pool that I want to replicate into another 
pool, so I''ve taken snapshots prior to replication:

pool1/home1       14.3G   143G  14.3G  /home1
pool1/home1 at snap  1.57M      -  14.3G  -
pool1/home2       4.31G   143G  4.31G  /home2
pool1/home2 at snap      0      -  4.31G  -
pool1/home3       1.11G   143G  1.11G  /home3
pool1/home3 at snap      0      -  1.11G  -
pool1/home4       10.2G   143G  10.2G  /home4
pool1/home4 at snap    44K      -  10.2G  -

# zfs send -vR pool1 at snap | zfs receive -vdF pool3
sending from @ to pool1 at snap
sending from @ to pool1/home4 at snap
receiving full stream of pool1 at snap into pool3 at snap
received 13.6KB stream in 1 seconds (13.6KB/sec)
receiving full stream of pool1/home4 at snap into pool3/home4 at snap
sending from @ to pool1/home3 at snap
cannot mount ''/home4'': directory is not empty

So how do I tell zfs receive to create the new filesystems in pool3, but 
not actually try to mount them?

-- 
Alan Burlison
--

Alan Burlison wrote:
> So how do I tell zfs receive to create the new filesystems in pool3, but 
> not actually try to mount them?
This is even more of an issue with ZFS root - as far as I can tell it''s
impossible to recursively back up all the filesystems in a root pool 
because of this - the reason being that one filesystem in the root pool 
will *always* be mounted as /, and when zfs receive creates the copied 
filesystem for / it also tries to mount it as /, and fails.

NAME                            USED  AVAIL  REFER  MOUNTPOINT
solaris                        6.89G  12.7G    30K  /solaris
solaris/ROOT                   6.88G  12.7G    18K  /solaris/ROOT
solaris/ROOT/onnv_92           65.8M  12.7G  3.98G  /
solaris/ROOT/onnv_94           2.76G  12.7G  3.99G  /
solaris/ROOT/test              4.06G  12.7G  3.98G  /
solaris/ROOT/test at test          296K      -  3.98G  -

# zfs snapshot -r solaris at 20080728
# zfs create -o mountpoint=none -o canmount=off backup/fire/solaris
# zfs send -R solaris at 20080728 | zfs receive -Fdv backup/fire/solaris
receiving full stream of solaris at 20080728 into backup/fire/solaris at
20080728
received 30.5KB stream in 1 seconds (30.5KB/sec)
receiving full stream of solaris/ROOT at 20080728 into 
backup/fire/solaris/ROOT at 20080728
received 13.6KB stream in 1 seconds (13.6KB/sec)
receiving full stream of solaris/ROOT/test at onnv_94 into 
backup/fire/solaris/ROOT/test at onnv_94
cannot mount ''/'': directory is not empty

Shouldn''t there be a flag (-n?) for use with receive -R that prevents 
the newly-copied filesystems from being mounted?  Or am I missing 
something obvious?

-- 
Alan Burlison
--

I have had the same problem too, but managed to work around it by setting the 
mountpoint to none before performing the ZFS send. But that only works on 
file-systems you can quiesce.

How about making a clone of your snapshot, then set the mounpoint of the clone 
to none, take a snapshot of the unmounted clone and then zfs send that?

Trev

Alan Burlison wrote:
> Alan Burlison wrote:
> 
>> So how do I tell zfs receive to create the new filesystems in pool3,
but
>> not actually try to mount them?
> 
> This is even more of an issue with ZFS root - as far as I can tell
it''s
> impossible to recursively back up all the filesystems in a root pool 
> because of this - the reason being that one filesystem in the root pool 
> will *always* be mounted as /, and when zfs receive creates the copied 
> filesystem for / it also tries to mount it as /, and fails.
> 
> NAME                            USED  AVAIL  REFER  MOUNTPOINT
> solaris                        6.89G  12.7G    30K  /solaris
> solaris/ROOT                   6.88G  12.7G    18K  /solaris/ROOT
> solaris/ROOT/onnv_92           65.8M  12.7G  3.98G  /
> solaris/ROOT/onnv_94           2.76G  12.7G  3.99G  /
> solaris/ROOT/test              4.06G  12.7G  3.98G  /
> solaris/ROOT/test at test          296K      -  3.98G  -
> 
> # zfs snapshot -r solaris at 20080728
> # zfs create -o mountpoint=none -o canmount=off backup/fire/solaris
> # zfs send -R solaris at 20080728 | zfs receive -Fdv backup/fire/solaris
> receiving full stream of solaris at 20080728 into backup/fire/solaris at
20080728
> received 30.5KB stream in 1 seconds (30.5KB/sec)
> receiving full stream of solaris/ROOT at 20080728 into 
> backup/fire/solaris/ROOT at 20080728
> received 13.6KB stream in 1 seconds (13.6KB/sec)
> receiving full stream of solaris/ROOT/test at onnv_94 into 
> backup/fire/solaris/ROOT/test at onnv_94
> cannot mount ''/'': directory is not empty
> 
> Shouldn''t there be a flag (-n?) for use with receive -R that
prevents
> the newly-copied filesystems from being mounted?  Or am I missing 
> something obvious?
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080728/24d35ee7/attachment.bin>

Trevor Watson wrote:
> I have had the same problem too, but managed to work around it by 
> setting the mountpoint to none before performing the ZFS send. But that 
> only works on file-systems you can quiesce.
Yeah, and / is always going to be a bit of a problem ;-)
> How about making a clone of your snapshot, then set the mounpoint of the 
> clone to none, take a snapshot of the unmounted clone and then zfs send 
> that?
I think that might work, but it means I''d have to write a script to 
traverse the filesystems in the root pool, which would be a bit fiddly. 
    If there was a ''-nomount'' flag to zfs receive,
snapshotting & saving
a pool would be just 2 commands.

Looks like a RFE is needed to me...

-- 
Alan Burlison
--