Re: Background fsck

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On 21 Jan 2004 07:35:13 GMT
Michel Talon <talon@xxxxxxxxxxxxxxxx> wrote:

> Chris Pressey <cpressey@xxxxxxxxxxxxxxx> wrote in 
> news:20040119112551.2af92c0a.cpressey@xxxxxxxxxxxxxxx:
> 
> >> 
> > My own opinion is that the "speed-up-recovery-after-a-crash" thing,
> > while apparently a very sexy problem for filesystem programmers to
> > tackle, is going to become more and more of a non-problem as UPS's
> > become more and more consumer-friendly.
> > 
> >
> 
> You are simply forgetting that the crash may occur for a completely 
> different reason than power failure, for example crash of the kernel.
> It occurred to me once that i removed sound module from my freebsd box
> which paniced immediately. Unfortunately this may have been in the
> middle of updating the superblock and at reboot fsck was unable to
> correct the situation and asked for a copy of the superblock. Still
> more unfortunately the first backup was corrupt also, and i had to
> find another good one.

Hmm... actually, there are two things here.

One is that I didn't make my point very clear.  It's not actually about
UPSes in particular.  It's more about the general trend in the mass
storage industry towards smarter and more self-contained devices. 

Consider, for example, how many options for newfs(8) are now "of
historical interest only."  What will mass storage devices look like in
another twenty years - how relevant will any of this softupdates and/or
journalling technology be then?  It's hard to say...

The other thing is that the idea that a power failure is not the only
reason you need to recover your disk, may be technically true while
practically being a red herring.  Consider Kris Kennaway's post
(coincidentally, just yesterday) on freebsd-questions:

On Tue, 20 Jan 2004 19:42:17 -0800
Kris Kennaway <kris@xxxxxxxxxxxxxx> wrote:

> On Tue, Jan 20, 2004 at 12:31:30AM +0100, Peter Schuller wrote:
> 
> > Do soft updates, or do they not, algorithmically guarantee
> > filesystem meta-data consistency in the event of a crash?
> 
> If you have a power failure or similar unclean shutdown, then SU
> guarantees consistency.  If there is a kernel panic or hardware
> failure, all bets are off, because there is no way to be sure that the
> kernel was writing the correct bits to the hardware prior to the
> crash, or that the hardware was writing the correct bits to disk.

i.e. if it's the software's fault, the best laid plans o' mice an' men
could be SOL anyway.  (Does the same logic not hold for journalling?)

Anyway, my outlook hasn't really changed.  Hardware problems are best
addressed in hardware, and software problems are better prevented than
worked around by inventing new and improved band-aids.

Sure, band-aids are good things, but it's better not to get cut in the
first place IMO.

Now, I'm not asking for a kernel that never panics (well actually I am,
but I realize that's a wee bit unrealistic at present) but how about a
kernel that doesn't panic when you try to unload a sound driver, for
starters?  :)

-Chris