On 10/18/11 11:46 AM, Mark Sandrock wrote:
On Oct 18, 2011, at 11:09 AM, Nico Williams wrote:
On Tue, Oct 18, 2011 at 9:35 AM, Brian Wilson wrote:
I just wanted to add something on fsck on ZFS - because for me that used to
make ZFS 'not ready for prime-time' in 24x7 5+ 9s uptime environments.
Where ZFS doesn't have an fsck command - and that really used to bug me - it
does now have a -F option on zpool import. To me it's the same
functionality for my environment - the ability to try to roll back to a
'hopefully' good state and get the filesystem mounted up, leaving the
corrupted data objects corrupted. [...]
Yes, that's exactly what it is. There's no point calling it fsck
because fsck fixes individual filesystems, while ZFS fixups need to
happen at the volume level (at volume import time).
It's true that this should have been in ZFS from the word go. But
it's there now, and that's what matters, IMO.
Doesn't a scrub do more than what
'fsck' does?
Oh yes, I wasn't trying to talk about scrub, in comparison with 'fsck' -
I was talking about zpool import -F. I believe scrub does a lot more.
It's also true that this was never necessary with hardware that
doesn't lie, but it's good to have it anyways, and is critical for
personal systems such as laptops.
IIRC, fsck was seldom needed at
my former site once UFS journalling
became available. Sweet update.
Mark
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
-----------------------------------------------------------------------------------
Brian Wilson, Solaris SE, UW-Madison DoIT
Room 3114 CS&S 608-263-8047
brian.wilson(a)doit.wisc.edu
'I try to save a life a day. Usually it's my own.' - John Crichton
-----------------------------------------------------------------------------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
