UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY

[Derek Kuliński]

Hello Jeremy,

Friday, September 26, 2008, 10:14:13 PM, you wrote:

>> Actually what's the advantage of having fsck run in background if it
>> isn't capable of fixing things?
>> Isn't it more dangerous to be it like that? i.e. administrator might
>> not notice the problem; also filesystem could break even further...

> This question should really be directed at a set of different folks,
> e.g. actual developers of said stuff (UFS2 and soft updates in
> specific), because it's opening up a can of worms.

> I believe it has to do with the fact that there is much faith given to
> UFS2 soft updates -- the ability to background fsck allows the user to
> boot their system and have it up and working (able to log in, etc.) in a
> much shorter amount of time[1].  It makes the assumption that "everything
> will work just fine", which is faulty.

As far as I know (at least ideally, when write caching is disabled)
the data should always be consistent, and all fsck supposed to be
doing is to free unreferenced blocks that were allocated.
Wouldn't be possible for background fsck to do that while the
filesystem is mounted, and if there's some unrepairable error, that
somehow happen (while in theory it should be impossible) just
periodically scream on the emergency log level?

> It also gives the impression of a journalled filesystem, which UFS2 soft
> updates are not.  gjournal(8) on the other hand, is, and doesn't require
> fsck at all[2].

> I also think this further adds fuel to the "so why are we enabling soft
> updates by default and using UFS2 as a filesystem again?" fire.  I'm
> sure someone will respond to this with "So use ZFS and shut up".  *sigh*

I think the reason for using Soft Updates by default is that it was
a pretty hard thing to implement, and (at least in theory it supposed
by as reliable as journaling.

Also, if I remember correctly, PJD said that gjournal is performing
much better with small files, while softupdates is faster with big
ones.

-- 
Best regards,
 Derek                            mailto:takeda at takeda.tk

Programmers are tools for converting caffeine into code.