>>>>> "gd" == Gregory Durham <gregory.dur...@gmail.com> writes:
gd> it to mount on boot
I do not understand why you have a different at-boot-mounting problem
with and without lofiadm: either way it's your script doing the
importing explicitly, right? so just add lofiadm to your script. I
guess you were exporting pools explicitly at shutdown because you
didn't trust solaris to unmount the two levels of zfs in the right
order?
Anyway I would guess it doesn't matter because my ``back up file
zpools to tape'' suggestion seems to be bogus bad advice. The other
bug referenced in the one you quoted, 6915127, seems a lot more
disruptive and says there are weird corruption problems with using
file vdev's directly, and then there are deadlock problems with
lofiadm from the two layers of zfs that haven't been ironed out yet.
I guess file-based zpools do not work, and we're back to having no
good plan that I can see to back up zpools to tape that preserves
dedup, snapshots/clones, NFSv4 acl's, u.s.w. I assumed they did work
because it looked like regression tests people were quoting and many
examples depended upon them, but now it seems they don't, which
explains some problems I had last month extracting an s10brand image
from a .VDI. :( (iirc i got the image out using lofiadm and just
assumed I was confused, banging away at things until they work and
then forgetting about them. not good on me.)
There is only zfs send which is made with replication in mind (
* it'll intentionally destroy the entire stream and any incremental
descendents if there's a single bit-flip, which is a good feature
to make sure the replication is retried if the copy's not faithful
but a bad feature for tape. If ZFS rallies against other
filesystems for their fragile lack of metadata copies and
checksums, why should the tape format be so oddly fragile that tape
archives become massive gamma gremlin detectors?
* and it has no scrub-like method analagous to 'tar t' or 'cpio -it'
because it's assumed you'll always recv it in a situation where
you've the opportunity to re-send, while a tape is something you
might like to validate after transporting it or every few years.
If pools need scrubing why don't tapes?
* and no partial-restore feature because it assumes if you don't have
enough space on the destination for the entire dataset you'll use
rsync or cpio or some other tree-granularity tool instead of the
replication toolkit. a tool which does not fully exist (sparse
files, >4GB files, NFSv4 ACL's), but that's a separate problem.
).
how about zpools on zvol's. Does that avoid the deadlock/corruption
bugs with file vdevs? It's not a workaround for the cases in the bug
becuase they wanted to use NFS to replace iSCSI, but for backups,
zvols might be okay, if they work? It's certainly possible to write
them onto a tape (dd was originally meant for such things).
pgpaynQ63iMAj.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
