>>>>> "re" == Richard Elling <richard.ell...@gmail.com> writes:
re> Indeed, but perhaps you'll find the grace to file an
re> appropriate RFE?
for what? The main problem I saw was with the wiki not warning people
away from archiving 'zfs send' emphatically enough, for example by
comparing its archival characteristics to tar (or checksummed cpio)
files and explaining that 'zfs send's output needs to be ephemeral.
This is RFE-worthy:
>> * unresolved bugs. ``poisonous streams'' causing kernel panics
>> when you receive them,
>> http://www.opensolaris.org/jive/thread.jspa?threadID=81613&tstart=0
but I'm not having the problem, so I won't file it when I can't
provide information.
>> * stream format is not guaranteed to be forward compatible
re> Backward compatibility is achieved.
I've read complaints where the zfs filesystem version has to match.
People _have_ reported compatibility problems. Maybe it is true that
a newer system can always receive an older stream, but not vice-versa.
I'd not wish for more, and that removes this (but not other)
objections to archiving 'zfs send'.
not entirely though---When you archive it you care about whether
you'll be able to read it years from now. Suppose there IS some
problem receiving an old stream on a new system. Even if there's not
supposed to be, and even if there isn't right now, a bug may appear
later. I think it's less likely to get fixed than a bug importing an
old zpool. so, archive the zpool, not 'zfs send' output.
re> An enterprising community member could easily put together a
re> utility to do a verification. All of the necessary code is
re> readily available.
fine, but (a) what CAN be written doesn't change the fact that the
tool DOES NOT EXIST NOW, and the possibility of writing one isn't
enough to make archiving 'zfs send' streams a better idea which is
what I'm discussing, and (b) it's my opinion a thorough tool is not
possible, because as I said, a bunch of kernel code is implicated in
the zfs recv which is full of assertions itself. 'zfs recv' is
actually panicing boxes. so I'd not have faith in some userspace
tool's claim that a stream is good, since it's necessarily using
different code than the actual extraction. 'tar t', 'cpio -it', and I
think 'zpool scrub' don't use separate code paths for verification.
>> * supposed to be endian-independent, but isn't.
>>
re> CR 6764193 was fixed in b105
re> http://bugs.opensolaris.org/view_bug.do?bug_id=6764193 Is
re> there another?
no, no other, that is what I remember reading. I read someone ran
into it when importing a pool, too, not just when using 'zfs send'.
so hopefully that fix came for free at the same time.
re> I suggest you consider an Enterprise Backup Solution.
I prefer Free Software, especially for archival. But I will consider
the advice I gave: backup to another zpool, or to a tar/cpio file.
I do not have a problem with the way 'zfs send' works. For
replication-like incremental backups, rolling back the entire recv for
one flipped bit is quite defendable. the lazy panics aren't, but the
architectural decision to trash a whole stream and all its descendent
incrementals for one flipped bit DOES make sense to me. but 'zfs
send' shouldn't be archived! That is what I'm saying, not
``zfs send | zfs recv sucks'', just that it shouldn't be archived.
pgpc47seziEpB.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
