v...@bb-c.de (Volker A. Brandt) writes: > Harry Putnam writes: >> >> So should I create the zfs fs by >> >> zfs create ... -o mountpoint=/usr/local p0/local >> >> zfs create ... p0/local/src >> >> zfs create ... p0/local/src/git >> >> >> >> (the -p option may be useful above.. I just want it >> >> to be clear what is being done) >> >> >> >> ending with /usr/local/src/git >> >> >> >> OR like this: >> >> >> >> zfs create ... -o mountpoint=/usr/local p0/local >> >> zfs create ... -o mountpoint=/usr/local/src p0/src >> >> zfs create ... -o mountpoint=/usr/local/src/git p0/git >> > >> > Certainly the former. If you use the second version, all three moint- >> > points will be "local". In the first version, the second (src) and >> > third mountpoints will be "inherited". >> > >> > So if you one day decide that you have seen the light and want to con- >> > vert to The One True local Mountpoint as Our Lord Intended It, you can >> > just change the first mount point to /opt/local, and the rest will >> > automatically inherit the new setting. >> >> Thanks for your thoughts. >> >> Sounds like the inherited mount point rates pretty high in your notion >> of what works best. >> >> I suspect you have other reasons as well, and I would like to hear >> about them if you don't mind expounding a bit more. >> >> For example: >> What baring[sp] would either way have on the ability to `send/receive'? >> >> I'm very inexperienced in send/receive: >> >> In the method you prefer, and the first on shown in OP, can $USER >> `send/receive' the whole of `local/src/git' in one move? Or would it >> need to be broken down into three send/receive sessions? > > Both will work. Any dataset snapshot can be sent/received separately, > if you want. But you can also use a recursive send where the dataset > itself and all "child datasets" will be included in the stream. Check > out the "-r" and "-R" flags in the zfs(1M) man page.
I could not find an -r (lowercase) for send sub-command (maybe you are only refering to zfs main cmd). But experimenting with send -R I seem to have gotten myself into some trouble. I attempted to: zfs send -R rpool/export/home/MYUSER |ssh oi0 zfs recv p12x where rpool is from oi installed on hardware, and oi0 is oi running on vbox vm on windows. And p12x is a new pool on the vbox vm created for this experimentation. So the result was that rpool/export/home/MYUSER showed up on the VBox instance of oi as p12x/export/home/MYUSER. But it attempted to retain the mountpoint from the sending os of /export/home/reader. Fortunately the mount was unsucessful since MYUSER was not empty. So the sent fs is setting there and can cbe displayed with zfs list -r and shows the mountpoint that was refused as if it worked. On receiving OS: ,---- | root # zfs list -r p12x | NAME USED AVAIL REFER MOUNTPOINT | p12x 3.86G 203G 3.86G /export/home/reader | | (Shows the data occupying 3.86 of space) `---- However the fs p12x/export/home/MYSUSER will not accept substitute mount point and claims the fs does not exist: ,---- | On the recv OS: | I created an empty directory at /2x-rpool and tried: | (2x is hostname of sending OS) | zfs set mountpoint=/2x-rpool p12x/export/home/reader | cannot open 'p12x/export/home/reader': dataset does not exist `---- So I can't remount it. Or see the data in anyway I can think off. zfs cannot even destroy it: ,---- | On recv OS: | root # zfs destroy -r p12x/export/home/reader | cannot open 'p12x/export/home/reader': dataset does not exist `---- Fortunately `zpool' still knew how: ,---- | On recv OS: | zpool destroy p12x | (Finished with no errors) `---- zfs list -r shows it gone So is there a way to send rpool to a remote host without all that mess? _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss