On Sun, Apr 23, 2006 at 04:17:32PM -0400, Thor Lancelot Simon wrote:
> > Is there much of that code left?  I think it almost all went when the
> > FFSv2 code was imported.
> 
> Gone from the kernel, yeah, some of them.  Gone from the on-disk format,
> even less so.  That space is reserved for all kinds of physical-geometry
> stuff in every cylinder group is one reason why we have to have so many
> cylinder groups -- which should really just be allocation groups, to
> allow parallel allocations once we have multiple processors in-kernel --
> for any disk of modern size.

No - the limiting factor for the size of a 'cylinder group' is that the
allocation map for the fragments and inodes must fit into a single
filesystem block.
The on-disk format still has per-cylinder info, but (IIRC) each cylinder
group looks as though it is made up of a single cylinder, so the
per-cylinder data areas are actually small.
The first cylinder-group does have an array of info about free space (etc)
in all the other groups - but that summary info is only in the first CG
and isn't (usually) a limiting factor.

> Extents would be a lot more sensible than the current block -- plus up
> to 8 sizes of fragments, but only 8 -- plus some new giant-block scheme;
> and eliminating multiple levels of block indirection would eliminate a
> major source of bugs in the code.

Some big-block scheme might be useful, especially if the allocation map
itself could be sparsed?  But it will all add complications - and worse
than the multi-level indirections.

> If one started out to design a simple filesystem that didn't know about
> disk geometry, it sure wouldn't look like FFS, even with everything that
> was ripped out for FFSv2.  That's all I'm getting at, really.

I'd not so sure, the limits would be different, and you might not care
about the actual physical geometry, but the problems are similar.

	David

-- 
David Laight: david@l8s.co.uk