Lori Alt wrote:
The -n option does some verification. It verifies that the record headers distributed throughout the stream are syntactically valid. Since each record header contains a length field which allows the next header to be found, one bad header will cause the processing of the stream to abort. But it doesn't verify the content of the data associated with each record.
So, storing the stream in a zfs received filesystem is the better option. Alas, it also is the most difficult one. Storing to a file with "zfs send -Rv" is easy. The result is just a file and if your reboot the system all is OK. However, if I zfs "receive -Fdu" into a zfs filesystem I'm in trouble when I reboot the system. I get confusion on mountpoints! Let me explain:
Some time ago I backup up my rpool and my /export ; /export/home to /backup/snaps (with zfs receive -Fdu). All's OK because the newly created zfs FS's stay unmounted 'till the next reboot(!). When I rebooted my system (due to a kernel upgrade) the system would nog boot, because it had mounted the zfs FS "backup/snaps/export" on /export and "backup/snaps/export/home on /export/home. The system itself had those FS's too, of course. So, there was a mix up. It would be nice if the backup FS's would not be mounted (canmount=noauto), but I cannot give this option when I create the zfs send | receive, can I? And giving this option later on is very difficult, because "canmount" is NOT recursive! And I don't want to set it manualy on all those backup up FS's.
I wonder how other people overcome this mountpoint issue. -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | SunOS 10u7 5/09 | OpenSolaris 2010.02 b122 + All that's really worth doing is what we do for others (Lewis Carrol) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
