On Tue, Dec 16, 2003 at 05:20:33PM +0100, Jaromir Dolecek wrote:
> Martin Husemann wrote:
> > I think it's time to bite the bullet and version struct dirent to give us
> > large inode numbers. See PR kern/23773 for a trigger.
> > 
> > Why didn't we do this a long time ago?
> 
> Even today it's not ordinary to have filesystem which would
> require 4G inodes. I'm not sure what's the inode size
> nowadays, but you'd need at least 2048GB (with 512B per inode)
> just to store the inode data.

Well the default is 4 fragments per inode, you only need FFSv2 for
more than 2^31 fragments - so any filesystem that needs FFSv2 is
close to needing more than 2^31 inodes.
(or if 2^31 inodes is way plenty, why do we need 2^31 fragments?)

If hacking struct dirent, add that inode use number (or whatever it is called)
then you nenver need to synchronously update directory entries..

> It _seems_ the msdosfs problem could be solved by different
> fileid calculation - for example using disk block number of first block
> in a file as 'inode' number would work up to 2048GB at least (with
> 512B block size). Maybe even beyond 2048GB - IIRC FAT32 can adress
> 4G blocks maximum, so it would probably force bigger block size
> for >2048GB filesystems (if it's supported at all).

The file allocations are in multi-sector units. So you get >2048GB for free.
Empty files are a problem - the entire disk could be full of directory
entries for zero sized files.

OTOH do we guarantee unique inode numbers for all filesystems?
IIRC union mounts done generate unique numbers - and mkisofs can get confused.

	David

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