[rfc] 64-bit inode numbers

[Oliver Fromme]

Gleb Kurtsou wrote:
 > I've been working on adding support for 64 bit ino_t and 32 bit nlink_t.

Great!

That will enable us to get rid of the MSDOSFS_LARGEFS hack,
right?  So large FAT file systems > 128 GB will finally be
exportable via NFS and don't wast kernel memory anymore.

Best regards
   Oliver

PS:  Just in case someone rading this doesn't know about
the MSDOSFS_LARGEFS hack (i.e. mount_msdosfs -o large),
here's a source comment for reference:

/*
 * Experimental support for large MS-DOS filesystems.
 * WARNING: This uses at least 32 bytes of kernel memory (which is not
 * reclaimed until the FS is unmounted) for each file on disk to map
 * between the 32-bit inode numbers used by VFS and the 64-bit
 * pseudo-inode numbers used internally by msdosfs. This is only
 * safe to use in certain controlled situations (e.g. read-only FS
 * with less than 1 million files).
 * Since the mappings do not persist across unmounts (or reboots), these
 * filesystems are not suitable for exporting through NFS, or any other
 * application that requires fixed inode numbers.
 */


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton