... Bill Studenmund (wrstuden@loki.stanford.edu) wrote:

> Side note: I think I was really flaming ffs's insistance that the disk
> be a certain number of whole cylinders. I want it to just accept that
> it's been given some disk space to live on, and some _HINTS_ about
> how that space is set up, but that it shouldn't get too fussy
> about the details not coming out even. I think your floppies should
> just be happily formatted at the variable sector spacing.

This is closely related to the concept of parametrizing the ffs, which
means: Feed hard disk parameters to high level ffs code so that it can
optimize disk storage layout (cylinder boundaries are an important part
here; see SMM:05 "A Fast File System for UNIX"). 

Unfortunately, with current mass storage technology, the ffs spends
considerable time on optimization based on meaningless parameters. On
the other hand, the given scheme is too rigid to describe the real world
disk; but if you allow 'not coming out even', you have to have
additional consistency checks. Time <-> space tradeoff...

> Uhm, why limit yourself to identical -endian machines?
> Why can't I take a DOS Zip drive and throw it in my Mac's Zip,
> and read it under NetBSD? msdosfs works on both big & small-endian
> machines. Also, why not do the same thing for AmigaDos drives. AmigaOS
> is in the kernel too...
> 
> What about a SunOS drive? HP-UX?

First: Don't mix up 'disklabel' with 'file system' here. For disklabels
there is no performance issue (nor is there for msdosfs or adosfs -- you
are usually happy if you can read/write stuff at all).

But go to current-user and try to suggest ffs metadata be written in
network byte order - and watch the little-endian fraction spout flames.
:-> 

I.e.: With ffs there _is_ a performance tradeoff.

> Why not teach ALL ports about ALL disklabel types?

Kernel bloat?

> We obviously run into a problem when it's hard to tell one
> label from another (they lack magic numbers like MacOS uses). 

Do they? An OS has to know its disks _somehow_, hasn't it?

> Design question for you (maybe it could be a first step to disklabel
> abstraction): how would you tell the kernel that it should write a
> MacOS disklabel as opposed to a *BSD disklabel as opposed to a Sun
> disklabel (I think boot blocks are different) as opposed to an
> Amigs or an Atari disklabel?

I don't think you would actually want to _write_ a foreign disklabel
format. A matter of safety, I suppose, as long as you don't know exactly
what is in those "RESERVED BY APPLE/SUN/DEC/MICRO$OFT" fields. That's
one thing, after all, about a native *BSD disklabel: We all know what it
should look like. 

        hauke

-- 
"It's never straight up and down"  (DEVO)