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
> 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.
zfs-discuss mailing list