I've been waiting for a version of FreeNAS/TrueNAS based on FreeBSD 12 for a long time, because that's when 64 bit inodes landed, and with them, mount path support up from 63 or 88 or so characters, to 1024 chars.
From the header info of FreeBSD revision 318736:
Why is this a big deal?
Well, ZFS has to covertly mount snapshots for file searches and so on. And historically, all of those mounts have had very short path lengths. The warnings about unsearchable snaps and snap names, are on about page 2 of every FreeNAS user guide up to 11.3.
With FreeBSD 12 those warnings should be a bygone era. Any reasonable dataset, nested dataset or snapshot name, and sensible mountpoint, should still have a path that fits within statfs / MNAMELEN with 64 bit inode landed. We should finally get that in TrueNAS 12... I get the impression.....
So, do we? can anyone more technical confirm it? :) Thanks!!
From the header info of FreeBSD revision 318736:
"Commit the 64-bit inode project:"
"Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify struct dirent layout to add d_off, increase the size of d_fileno to 64-bits, increase the size of d_namlen to 16-bits, and change the required alignment. Increase struct statfs f_mntfromname[] and f_mntonname[] array length MNAMELEN to 1024."
Why is this a big deal?
Well, ZFS has to covertly mount snapshots for file searches and so on. And historically, all of those mounts have had very short path lengths. The warnings about unsearchable snaps and snap names, are on about page 2 of every FreeNAS user guide up to 11.3.
With FreeBSD 12 those warnings should be a bygone era. Any reasonable dataset, nested dataset or snapshot name, and sensible mountpoint, should still have a path that fits within statfs / MNAMELEN with 64 bit inode landed. We should finally get that in TrueNAS 12... I get the impression.....
So, do we? can anyone more technical confirm it? :) Thanks!!
Last edited: