Re: minixfs bitmaps and associated lossage

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 7 May 2006, Al Viro wrote:
> 
> FWIW, the only way to really deal with such structure would be to treat
> on-disk values as "fs-endian" and make the conversion to and from
> host-endian check the superblock.  That would _really_ consolidate
> minix_..._bit() (turning them into __test_bit(nr ^ sbi->mangle, p), etc.)

Yeah, especially for bitmaps, it really _should_ be pretty simple, since 
it's literally a bitwise xor of the bit number. It's actually worse for 
things that truly have byte order dependencies where the values span bytes 
and need re-ordering. For bits, that obviously will never be the case.

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

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?

So there are things that are very similar (directory layout, inode 
format), and could probably be share, while other things (free block and 
inode handling) are fundamentally different, no?

			Linus