> 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. Frank --- 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
