On 9/23/15 12:05 PM, Frank Filz wrote: > We could use the flag byte to indicate 32 bit or 64 bit exportid. > > I would suggest if an exortid is between 0 and 65535 that it be packed into a > 16 bit, this would allow an installation that wanted to expand to do so > without changing handles for existing exports. Then if the exportid fits in > 32 bits use 32 bits, otherwise use 64 bits. > > This will have some impact on decoding but would allow the most flexibility. > Combined with the flexibility to specify the size of the FSID embedded in the > FSAL_VFS handles, it would allow the possibility of using 32 bit or even 64 > bit exportid with at least some exported filesystems in FSAL_VFS even over > NFS v3. > > I'm pretty sure the ability to fit a handle into 64 bytes vs 128 bytes is > made at the response forming stage so if the resulting handle would be too > big for v3, the export could still be available over NFS v4. > I'm confused. How exactly are you going to handle more than 64K exports with a maximum of 64K connections to your host?
We looked (and looked and looked) at this 20+ years ago, and concluded that even with flows in IPv6, we would require a new transport to handle more ports. Moreover, from the security side, the TCB of potential and expired connections is already being swamped. A larger number of exports is a Denial-of-Service attack waiting to happen. On the RDMA side, the amount of memory reservation required would be a self-DoS of your system. ------------------------------------------------------------------------------ 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
