Miles Nordin wrote:
"rm" == Robert Milkowski <mi...@task.gda.pl> writes:
rm> Personally I don't blame Sun that implementing the CR took so
rm> long as it mostly affected home users with cheap hardware from
rm> BestBuy like sources
no, many of the reports were FC SAN's.
rm> and even then it was relatively rare.
no, they said they were losing way more zpools than they ever lost
vxfs's in the same environment.
Well, who's they? I've been depolying ZFS for years on many different
platforms from low-end, jbods, thru midrange, SAN, and high-end disk
arrays and I have yet to loose a pool (hopefully not).
It doesn't mean that some other people did not have problems or did not
loose they pools - in most if not in all such cases almost all data
could probably be recovered by following manual and "hackish" procedure
to rollback to a previous uberblock. Now it is integrated into ZFS and
no special knowledge is required to be able to do so in such circumstances.
Then there might have been other bugs... life, no software is without them.
rm> called enterprise customers were affected even less and then
rm> either they had enough expertise or called Sun's support
rm> organization to get a pool manually reverted to its previous
rm> uberblock.
which is probably why the tool exists. but, great!
The point is that you don't need the tool now as it is built-in in zfs
starting with snv_126.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
