Posted on 2008-10-15 11:30:00, modified on 2008-10-15 14:30:00
Tags: FreeBSD, HammerFS
I was just listening to the talk Matthew Dillon gave at the NYCBSDCon 2008 about the HAMMER File System.
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.
<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