My initial thought is lets get all ino_t's in linux to move to 64 bit.
This will take time, but we should do it since file systems will get this
big.
For XFS, this isn't a problem 'till we hit file systems around 4Tbs or so.
But, it does become a problem.
In the shorter term, (while Linux is moving to 64 bit ino_ts), we could
use some index'ing scheme with a hash tabel lookup or ... to map from
internal 64 bit ino_t's to 32 bit values. This would limit XFS to
2^32 inodes. But we could live with this more easily than being limited
to 4tb file systems. Do you want a crack at fixing this?
The inode is a mask of 3 values, ag #, block #, index in cluster.
It is a sparse value in that it is nearly impossible for all block #'s to
exist. Assuming that one is writing data to files. If we keep track of
the block #'s that are inodes, we could change this to ag #, block index
#, index in cluster. This could let us shrink the middle field "block index #"
substantially. This would limit the number of inodes per AG. We then need
a way to keep track of which block each AG index actually refers to. But,
this would be much less storage than a hash table or index for all inode
numbers.
Thinking out loud,
Jim
>
>Since we're on the topic of status reports, I'll try to tell you where
>I'm at with the big filesystem stuff.
>
>In terms of big files, there are no problems, as long as you're
>running a suitably new glibc. I've created sparse files larger than 4
>TB (if the very nice Purolator man brings me a magical giant disk
>array, I'll test non-sparse files too) without any apparent ill
>effects.
>
>[root@caesar xfs]# ls -l /mnt/xfs/test
>-rwxr-xr-- 1 root root 5344754401280 Apr 6 19:15 /mnt/xfs/test
>[root@caesar xfs]#
>
>Now, as far as 64 bit inode numbers go, the story is somewhat
>different (as expected). Unfortunately, glibc unconditionally defines
>__ino64_t to be unsigned long, despite any LARGEFILE64_SOURCE or
>whatever.
>
>As an alternative to dealing with the political mess that wedging
>a 64 bit ino_t into glibc and the kernel, Steve pondered some ideas
>about doing all of the 64 bit work internal to XFS. Unfortunately,
>one of the big things that I think it would break is NFS, which
>(currently) relies on an inode being a unique file identifier.
>
>As someone who would rather see 64 bit ino_ts, even if it takes a long
>time and a bunch of fighting, I've sent off some emails to the glibc
>folks, just to see if they've even been considering this. Hopefully
>I'll hear back from them shortly, and see where to go from there.
>
>Thoughts?
>
>-Phil
>
|