Uwe Dippel schrieb:
Bob Friesenhahn wrote:
Since it was not reported that user data was impacted, it seems likely
that there was a read failure (or bad checksum) for ZFS metadata which
is redundantly stored.
(Maybe I am too much of a linguist to not stumble over the wording
here.) If it is 'redundant', it is 'recoverable', am I right? Why, if
this is the case, does scrub not recover it, and scrub even fails to
correct the CKSUM error as long as it is flagged 'unrecoverable', but
can do exactly that after the 'clear' command?
Ubuntu Linux is unlikely to notice data problems unless the drive
reports hard errors. ZFS is much better at checking for errors.
No doubt. But ext3 also seems to need much less attention, very much
fewer commands. Which leaves it as a viable alternative. I still hope
that one day ZFS will be maintainable as simple as ext3; respectively do
all that maintenance on its own. :)
Ext3 has no (optional) redundancy by using more than one disc and no
volume managment. You need Device Mapper for redundancy (Multiple
Devices or Linux Volume Management) and volume management (LVM again).
If you want such features on Linux Ext3 is the top of at least 2,
probably 3 layers of storage managment.
Should I add NFS, CIFS and iSCSI exports or the needlessness of resizing
volumes?
You're comparing a single tool with a whole production line.
Sorry for the flaming but yesterday I spend 4 additional hours at work
with recovery of a xen server with a single error somewhere in it's LVM
causing the virtual servers to freeze.
Uwe
Kind Regards, FLorian
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
