Migration from the KQ Implementation
Jason J. W. Williams
jasonjwwilliams at gmail.com
Wed May 4 12:25:28 EDT 2011
On the rare occasions where that happens you can usually use zdb to coax the file system into mounting and then get your data off.
Keep in mind ext4 is nowhere near as stable in a crash as ZFS. It really does need an fsck.
Sent via iPhone
Is your e-mail Premiere?
On May 4, 2011, at 2:51, "Fajar A. Nugraha" <list at fajar.net> wrote:
> On Wed, May 4, 2011 at 3:43 PM, Matthew Robbetts <wingfeathera at gmail.com> wrote:
>>> Which brings me to another, somewhat tangential point. Sun and Oracle have thus far failed to provide a fsck tool for ZFS. In the absence of such a tool from an official source, is there a future plan/intention for providing such a thing within the scope of this project? I know that ZFS is supposedly designed so that it is always consistently recoverable, but I know of several cases at work where this wasn't the case after a crash, using pure stable Solaris.
>> Would such a tool be needed? I've always thought that scrub provides all of the features of fsck but is also able to work online. Is this not the case?
> In the past there have been some cases where users are unable to mount
> the disk due to various problems (mostly because the disk "lie" about
> whether it has committed writes). The approach taken by Sun to fix
> this problem is to do some "checks" and "fix" during pool import time
> (i.e. somewhat similar to journal reply on ext3/4). One might argue
> that since ext4 still needs fsck, the same thing is also true for zfs.
> But AFAIK there's no such plan in Oracle to create fsck-like tool for
> Scrub is a different matter altogether, designed to detect block
> corruption in used disk space.
More information about the zfs-discuss