Date: Wed, 1 Dec 2010 19:18:59 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: [rfc] 64-bit inode numbers Message-ID: <20101201171859.GA5991@tops> In-Reply-To: <201012011333.oB1DXcCB053041@lurza.secnetix.de> References: <x43861x1291194762x@lurza.secnetix.de> <201012011333.oB1DXcCB053041@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On (01/12/2010 14:33), Oliver Fromme wrote: > 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. Yes, that was one of the reasons I've started working on the patch. All the infrastructure work necessary for eliminating largefs should already be there, but patch is really *untested*. Don't expect it just to work yet. Besides situation with ZFS is still unclear for me, looks like it expects 64-bit ino_t and silently shorts inode numbers to 32 bit. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101201171859.GA5991>