Re: minixfs bitmaps and associated lossage

[Al Viro]

On Sat, May 06, 2006 at 04:42:27PM -0700, Linus Torvalds wrote:
> > If somebody wants to play with that code, they could just merge fs/minix
> > into fs/sysv - that might very well turn out to be the right thing and
> > a fun exercise.  Codebases are very close - minixfs is a derivative of
> > v7 filesystem, after all, and our fs/minix and fs/sysv had been kept
> > mostly in sync.
> 
> Heh. Yes. The physical filesystem layout of minix is close to the old sysv 
> one, and the implementation ends up being pretty closely related too, 
> although the genealogy there is the other way around.

Actually, some things (e.g. indirect block tree handling and directory
handling via pagecache) went the other way - from fs/sysv to fs/minix.

> However, I thought the direct sysv descendants used linked lists of 
> free-block lists, not bitmaps? So while a lot of the _other_ part of the 
> filesystem layout is similar, the actual free-block handling is very 
> different. No?

Yes and no - keep in mind that details of those lists are different for
various sysvfs flavours, so sysv_new_block() et.al. check sbi->s_type
anyway.  And the entry points into [ib]alloc are parallel, so it's not
hard to merge transparently for the rest of code.

Superblock layouts are very different, obviously, but they are just as
different among sysv flavours.  Again, no big deal...
 
BTW, there's a sysv flavour that uses bitmaps (EAFS); we only do it
read-only, so that's not an issue with the current fs/sysv code.

Again, what I'm saying is that figuring out details of doing it clean
way would make a good exercise, not that we can't live without that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/