zfs discuss - Feb 2010 - getting tangled with recieved mountpoint properties

I have a machine whose purpose is to be a backup server.  It has a
pool for holding backups from other machines, using zfs send|recv. 

Call the pool dpool. Inside there are datasets for hostname/poolname,
for each of the received pools.  All hosts have an rpool, some have
other pools as well.  So the upper level datasets look similar to:

 dpool/foo/rpool
 dpool/bar/rpool
 dpool/bar/lake
 dpool/bar/tank
 dpool/baz/rpool
 dpool/baz/pond

and so on.  Under each of those are the datasets from the respective
pools, received using zfs recv -d <one of the above>

The trouble comes from the received properties, mountpoint in
particular.  Every one of those rpools has a dataset rpool/export with
mountpoint=/export, and home and so forth under there.

There was an issue until recently that meant these mountpoints got
some strangely-doubled prefix strings added, so they were mounted in
odd places. That was fixed, and now with an upgrade to b132, I have
many filesystems all with the same mountpoint property. At boot time,
one of these wins, and the rest fail to mount, filesystem/local svc
fails and not much else starts from there.

With the new distinction between received and local properties, I was
hoping for a solution. The zfs manpage says that I can use inherit to
mask a received property with an inherited one.  This flat-out seems
not to work, at least for mountpoint.

I''d be happy enough if none of these was mounted, but annoyingly in
this case, the canmount property is not inheritable, so I can''t just
set this somewhere near the top and be done.  My workaround so far:
 # zfs list -t filesystem -o name | egrep ^dpool | xargs -n 1 zfs set
canmount=noauto
but this is annoying and manual and I sometimes forget when a new
filesystem is added and sent from the source host.

I can''t use the altroot pool property, it''s not persistent and
anyway
would just prefix the same thing to all of the datasets, for them to
collide under there.  It would at least ensure I get the backup
machine''s own /export/home/dan and /var and some others, though :)

The same issue applies to other properties as well, though they don''t
cause boot failures. For example, I might set copies=2 on some dataset
on a single-disk laptop, but there''s no need for that on the backup
server. I still want that to be remembered for the restore case, but
not to be applied on the backup server.

How else can I solve this problem? What else have others done on their
backup servers?

Separately, if I override recvd properties, in the restore use case
when I want to send the dataset back to the original host, is there
some way I can tell zfs send to look at the received properties rather
than the local override?  

I was hoping the new property source stuff would help with all this,
but I''m not really clear on the whole process, it doesn''t
quite seem
to be fully fleshed out yet.  I can imagine something like a
property-sed, that you could insert in between send and recv pipeline,
as being helpful - but a properly thought-out framework would be much
better. 

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100217/b4354747/attachment.bin>

On Wed, February 17, 2010 03:35, Daniel Carosone wrote:
> I''d be happy enough if none of these was mounted, but annoyingly
in
> this case, the canmount property is not inheritable, so I can''t
just
> set this somewhere near the top and be done.  My workaround so far:
>  # zfs list -t filesystem -o name | egrep ^dpool | xargs -n 1 zfs set
> canmount=noauto
> but this is annoying and manual and I sometimes forget when a new
> filesystem is added and sent from the source host.
That''s exactly where I''ve ended up, except it''s not
manual, it''s built
into the send / receive command (mine are local USB disks rather than a
remote system, so things are just a bit different).  I haven''t found a
better solution yet, but I''m still back on build 111b, so I
don''t have the
new property replication capabilities (or complexities) to deal with.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info