> From: Marc Eshel [mailto:[email protected]] > Sent: Wednesday, September 23, 2015 2:20 PM > To: Frank Filz <[email protected]> > Cc: [email protected]; 'NFS Ganesha Developers' > <[email protected]> > Subject: Re: [Nfs-ganesha-devel] Export_id larger than 16 bits > > if we want to continue to support vmware we are limited to 56 bytes file > handle for NFSv3.
Oh, right. I keep forgetting that... Which IS why we are so tight on the size of v3 handles... Without that limitation, we would easily have room for 32 bit exportid... Frank > From: "Frank Filz" <[email protected]> > To: [email protected] > Cc: "'NFS Ganesha Developers'" > <[email protected]> > Date: 09/23/2015 01:45 PM > Subject: Re: [Nfs-ganesha-devel] Export_id larger than 16 bits > ________________________________________ > > > > > Frank Filz [[email protected]] wrote: > > > Exports don't necessarily correspond to connections. > > > > > > The Linux client (and I'm guessing most others) will use one > > > connection > to > > the server (or a few if it does some trunking) for all exports it > > mounts > from > > that server. Now true, if the exports are intended for different > > clients > there > > might be some issues, however, a clustered system would distribute the > > client connections among multiple hosts while having the convenience > > of managing all the exports as if there was a single server. > > > > > > Frank > > > > There are also people who create exports, remove them, and recreate > > exports. They will not have anything close to 64K exports at the same > time, > > but they will pass that mark after few weeks/months as every export > > create needs an unused exportid. > > Well, exportid could be managed to keep within 16 bits in such a scenario. > > Your GPFS handles are one of the larger handles (if not the largest, though > BTRFS has a 40 byte kernel handle). > > > Wondering if we can avoid using exportid in the file handle! > > Only if we were strict and had only one export per FSID, but then a lot of > front end logic would have to change, and handles would not be backward > compatible. > > If folks with the largest handles got creative, we COULD probably squeeze > out an extra 2 bytes. > > There's also an intermediate option, a 24 bit exportid since the header is 5 > bytes. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
