On 9/23/15 4:18 PM, Malahal Naineni wrote:
> Frank Filz [ffilz...@mindspring.com] 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 mou
> From: Marc Eshel [mailto:es...@us.ibm.com]
> Sent: Wednesday, September 23, 2015 2:20 PM
> To: Frank Filz
> Cc: mala...@linux.vnet.ibm.com; 'NFS Ganesha Developers'
>
> Subject: Re: [Nfs-ganesha-devel] Export_id larger than 16 bits
>
> if we want to continu
if we want to continue to support vmware we are limited to 56 bytes file
handle for NFSv3.
Marc.
From: "Frank Filz"
To: mala...@linux.vnet.ibm.com
Cc: "'NFS Ganesha Developers'"
Date: 09/23/2015 01:45 PM
Subject: Re: [Nfs-ganesha-devel]
> Frank Filz [ffilz...@mindspring.com] 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 e
Frank Filz [ffilz...@mindspring.com] 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 export
> 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 hand
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 exi
> From: Gary Ma [mailto:g...@datagravity.com]
> Sent: Wednesday, September 23, 2015 6:21 AM
> To: Frank Filz
> Cc: Dirk Jagdmann ; NFS Ganesha Developers ganesha-de...@lists.sourceforge.net>
> Subject: Re: [Nfs-ganesha-devel] Export_id larger than 16 bits
>
> What are t
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
- Original Message -
> From: "Gary Ma"
> To: "Frank Filz"
> Cc: "NFS Ganesha Developers"
> Sent: Wednesday, September 23, 2015 9:21:15 AM
> Subject: Re: [Nfs-ganesha-devel] Export_id l
What are the options if we need 32-bit export id? Not enabling the FSALs
that have larger handle?
Thanks,
Gary
On Tue, Sep 22, 2015 at 9:50 PM, Frank Filz wrote:
> The problem with expanding export id is making everything fit in a 64 byte
> nfs v3 handle. We have several FSALs that already wind
The problem with expanding export id is making everything fit in a 64 byte nfs
v3 handle. We have several FSALs that already wind up with a 62 byte handle.
Frank
Sent from my iPhone
On Sep 22, 2015, at 5:01 PM, Dirk Jagdmann wrote:
> Currently gsh_export::export_id is a 16 bit unsigned. This
Currently gsh_export::export_id is a 16 bit unsigned. This also corresponds to
a
16 unsigned defined for the EXPORT configuration. Is there any reason why this
Export ID is limited to 16 bit? Could this be increased to 64 bits?
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://ll
12 matches
Mail list logo
