Re: Background fsck

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

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

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

OK, "cleverer" (in quotes) might have been a better choice of word than
"smarter". :)

> Data consistency is still the responsibility of the OS

I respectfully disagree - data consistency is the responsibility of the
filesystem.

There are two models you can follow here - roughly, the BSDs treat the
filesystem as part of the OS while the Linuxes don't.  I'd rather DFBSD
go on a path closer to the Linux model.  Instead of inventing a new
journalled filesystem, why not use existing ones.  At least to start.

This means fixing VFS, but that's got to be done anyway.

Perhaps the filesystem will never migrate to the device itself, but on
the other hand, there's no reason not to cut its umbilical cord.

> Right: so design a file system with atomicity.

Right, or adopt one, or several.

> The way this is most commonly do is with journaling.

Sure.  But journalling != atomicity, and I don't care nearly as much
about the former as I do the latter.

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

Or suppose the kernel just refuses to use the invalid pointer.

I guess the usual argument against that is that it's inefficient to
determine the validity of every single pointer before using it, and to
a great extent that's true.  There's always going to be a tradeoff
between efficiency and robustness.

So this brings me to something that's got me in a bit of a tizzy. 
Basically, the website is good at describing the technical goals of
DFly, but it's a bit light on overall philosophy.  The following design
goals are mentioned on the main page: 

  - Scaleability
  - Robustness
  - Debuggability
  - Compatibility (forwards and backwards)
  - Upgradeability

The rest is nuts-and-bolts stuff, which is fine, but from it, you can't
easily take Idea X for Improvement Y and see how well it fits in The
Big Picture[tm].  That's why it's hard to evaluate stuff like
internationalization and other suggestions that cross this list every so
often - sure, they'd be great, lots of things would be great, but
there's really nothing in the project that implies that it should (or
shouldn't) get a high (or low) priority.

Another (although much more hackneyed) way to put this, to paraphrase
Ulrich Spoerlein's sig: "FreeBSD is the most powerful OS.  NetBSD is the
most portable OS.  OpenBSD is the most secure OS.  Linux is the most
popular OS.  So what is DragonFlyBSD?"

Most scaleable?  Most robust?  Most debuggable?

Just-plain-best-designed?

Can the design goals of DFly even *be* reduced to a sound bite that fits
in a sig?  In a sense, I hope not, but in another sense, if they can't,
the project's direction risks being unclear.

Not sure what can be done about this except to lay out DFly's
philosophical goals more explicitly.

Anyway, sorry for ranting, take it with a grain of salt.

-Chris