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
|