Thor Lancelot Simon wrote:

> Speaking of "old goo" -- I'd like to propose rotational position optimization
> as "old goo" that is not useful on any disks manufactured in almost 10 years,
> costs CPU, and needlessly complicates the data structures.

You're quite correct, though when I was re-implementing an embedded FFS,
the rotational optimisation did not add very much computational overhead
to the code at all---given the speed of discs, certainly nothing
measurable. Likewise in terms of CPU usage, the calculations are pretty
minimal and optimised via look up tables so there isn't too much
overhead there.

It does seem unnecessary, though, agreed on modern discs, though a lot
of complication in the code comes from fragments.

> Also, it'd be nice to support more fragmentation than the current 1/8
> limit, so we could use larger blocks without wasting so much space
> (and avoid the need to cluster in many cases -- though the current
> limitation of only being able to cluster to MAXPHYS, which is a lot smaller
> than the actual maximum size transfer you could get across the buses to the
> disk on many buses/controllers/disks on many ports, is kinda a separate
> though related lose, and this wouldn't help avoid it).

We could always increase MAXPHYS. I don't know if there are any
dependencies on it being 64KB or not. Interestingly, I've found, on
recommendation on a CVS server, just 4KB/4KB blocks win performance with
< NDADDR blocks and also help file system recoverability. The extra
space usage didn't bother me at all (it was a bit more than when the FS
was previously 8KB/1KB) 'cos disks are cheap these days.

	Neil