Re: Background fsck

[Gary Thorpe <gathorpe79@xxxxxxxxx>]

Chris Pressey wrote:

> 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. 


Smarter and more self-contained devices that lie about caches being 
on/off and cannot even automatically relocate bad sectors properly?

> 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...


You mean like IDE drives that have to lie about their geometry to 
overcome limitations of PC BIOS's to allow you to boot your OS? SCSI 
drives I think actually provide real figures which would still be useful 
for FFS's algorithms. Data consistency is still the responsibility of 
the OS and there is zero activity to change this, because all commercial 
OS's have journaling available as an option at least. Hardware 
manufacturers won't make a solution when one already exists for zero 
cost to them in development.

> 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?)


The same logic should apply to databases also...but the whole point of a 
journal is to do transactions in a file system. Bugs in the sound driver 
are unlikely to seriously corrupt the file system, but a journal will 
make the recover faster and less error prone.

> 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.


Throwing hardware at a problem instead of thinking up a workable 
solution in software is just a stop gap. New and improved bad aids would 
be softdeps but journaling is probably in the line of preventative 
measures: do operations in the file system in such a way that corruption 
is avoided (barring design/implementation bugs).

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


Right: so design a file system with atomicity. The way this is most 
commonly do is with journaling. Or do you mean avoid secondary storage 
altogether?

> 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?  :)


Suppose the driver has a bug which cause the kernel to use an invalid 
pointer: since most OS's are still monolithic, you are more unsure about 
what you may have just corrupted (including FS code). This is why fsck 
will still be necessary even for a journaling FS, but in the common case 
it would not be necessary and you would save lots of time.

> -Chris