DragonFly BSD
DragonFly kernel List (threaded) for 2004-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Background fsck

From: Gary Thorpe <gathorpe79@xxxxxxxxx>
Date: Wed, 21 Jan 2004 11:10:52 -0500

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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]