DragonFly kernel List (threaded) for 2004-01
Re: Background fsck
Chris Pressey wrote:
Hmm... actually, there are two things here.
Smarter and more self-contained devices that lie about caches being
on/off and cannot even automatically relocate bad sectors properly?
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.
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.
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 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.
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?)
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).
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.
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
Sure, band-aids are good things, but it's better not to get cut in the
first place IMO.
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.
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