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.
pgpqNN8B2TQv1.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
