One of the basic requirements of it is that the type ino_t has to be 64 bits. Unfortunately, on FreeBSD this is still 32 bits...
So for everybody who thinks that this is just a extra filesystem layer added to the FreeBSD operating system, it is a little bit more difficult. For example, the commit log for the DragonFlyBSD revision 1.11 was:
Update at 2008-10-15: It seems that people are already doing work on experimenting with a 64 bit ino_t:Make nlink_t 32bit and ino_t 64bit. Implement the old syscall numbers for *stat by wrapping the new syscalls and truncation of the values. Add a hack for boot2 to keep ino_t 32bit, otherwise we would have to link the 64bit math code in and that would most likely overflow boot2. Bump libc major to annotate changed ABI and work around a problem with strip during installworld. strip is dynamically linked and doesn't play well with the new libc otherwise. Support for 64bit inode numbers is still incomplete, because the dirent limited to 32bit. The checks for nlink_t have to be redone too.
| Share on Facebook | Share on Twitter<EvilPete> Mavvie: I have patches in perforce (several versions in fact) that bump ino_t to 64 bits. <EvilPete> Mavvie: nfsv3 has 64 bit inodes. we have hacks to hash large nfs inode numbers into freebsd's smaller ones <EvilPete> Mavvie: also, I increased nlink_t and mode_t from 16 to 32 bits. <EvilPete> //depot/user/peter/ino64 is one of them
|Posted on:||2008-10-16 06:35:57|
|Comment||It's not really an obstacle since UFS2 specifically thought about leaving space for 64bit inodes. I think this breaks the on-disk structure but it was planned this could happen (I can't find the specific reference atm, maybe it's around section 8.2 in the FreeBSD Design and Implementation book).
Another problem is the 64bit dirent cookies. Those would bring problems for the our NFS2 (specially in PXE).
And yet another problem is the amount of "features" that Matt added to the VFS.