On Tue, Oct 18, 2011 at 11:46 AM, Mark Sandrock <mark.sandr...@oracle.com>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? > > Not really. fsck will work on an offline filesystem to correct errors and bring it back online. Scrub won't even work until the filesystem is already imported and online. If it's corrupted you can't even import it, hence the -F flag addition. Plus, IIRC, scrub won't actually correct any errors, it will only flag them. Manually fixing what scrub finds can be a giant pain. > > > > 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 > > We all hope to never have to run fsck, but not having it at all is a bit of a non-starter in most environments. --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
