2011-06-09 21:33, Paul Kraus пишет:
If some bits in the saved file flipped,
Then you have a bigger problem, namely that the file was corrupted.
That is not a limitation of the zfs send format. If the stream gets
corrupted via network transmission you have the same problem.
No it is not quite a limitation, however the longer you store
a file and the huger it is, the more is the probability of
a single bit going wrong over time (i.e. on old tape stored
in a closet).
And ZFS is very picky about having detected a non-integrity
condition. Where other filesystems would feed you a broken
file, and perhaps some other layer of integrity would be
there to fix it, or you'd choose to ignore it, zfs will
refuse to process known-bad data.
As the original posted has shown, even within ZFS this problem
can be worked around... if ZFS would ask the admin what to do.
Kudos to him for that! ;)
And because of a small chunk you may lose everything ;)
I've had that part under a customer's VMware ESX 3.0, which
did not honour cache flushes, so ZFS broke down upon hardware
resets (i.e. thermal failure) and paniced the kernel upon boot
attempts. Revertng that virtual Solaris server to use UFS was
sad - but it worke for years since then, even through such
mischiefs as hardware thermal resets.
I've tested that VM's image recently with OI_151 dev LiveCD -
even it panics on that pool. It took aok=1 and zfs_recover=1
and "zfs import -o ro -f -F pool" to rollback those last bad
transactions.
BTW, "-F -n" was not honoured - the pool was imported and
the transactions were rolled back despite the message along
the lines "Would be able to recover to timestamp XXX"...
Having said that, I have used dumping "zfs send" to files, rsyncing
them over a slow connection, and zfs recv'ing them on a another
machine - so this is known to work.
I suppose to move data or for an initial copy that makes sense, but
for long term replication why not just use incremental zfs sends ?
This was an initial copy (backing up a number of server setups
from a customer) with tens of Gbs to send over a flaky 1Mbit
link. Took many retries, and zfs send is not strong at retrying ;)
--
+============================================================+
| |
| Климов Евгений, Jim Klimov |
| технический директор CTO |
| ЗАО "ЦОС и ВТ" JSC COS&HT |
| |
| +7-903-7705859 (cellular) mailto:jimkli...@cos.ru |
| CC:ad...@cos.ru,jimkli...@mail.ru |
+============================================================+
| () ascii ribbon campaign - against html mail |
| /\ - against microsoft attachments |
+============================================================+
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
