> > > The problem is that "fd"s are an internal detail that we do not want
> > leaking
> > > out into the general server.
> > >
> > > There are several reasons for this adduced in my and Adam's comments
> > in
> > > gerrit.
> > >
> > > I may be missing something, but what is the generic (non-VFS or
Hi,
- "Frank Filz" wrote:
> > The problem is that "fd"s are an internal detail that we do not want
> leaking
> > out into the general server.
> >
> > There are several reasons for this adduced in my and Adam's comments
> in
> > gerrit.
> >
> > I may be missing something, but what is the ge
> The problem is that "fd"s are an internal detail that we do not want leaking
> out into the general server.
>
> There are several reasons for this adduced in my and Adam's comments in
> gerrit.
>
> I may be missing something, but what is the generic (non-VFS or few other
> FSAL-specific) concep
> -Original Message-
> From: Daniel Gryniewicz [mailto:d...@redhat.com]
> Sent: Tuesday, July 28, 2015 10:42 AM
> To: nfs-ganesha-devel@lists.sourceforge.net
> Subject: Re: [Nfs-ganesha-devel] Multiple-fd work
>
> On 07/27/2015 12:33 PM, Frank Filz wrote:
>
>
>
> Is there a reason we
On 07/27/2015 12:33 PM, Frank Filz wrote:
Is there a reason we can't just pass state_t to the FSAL on the correct
calls? That seems the simplest, most straight forward way to do this.
Dan
--
_
The problem is that "fd"s are an internal detail that we do not want
leaking out into the general server.
There are several reasons for this adduced in my and Adam's comments
in gerrit.
I may be missing something, but what is the generic (non-VFS or few
other FSAL-specific) concept that is being
> Hi Frank, list.
>
> Frank Filz wrote on Mon, Jul 27, 2015 at 09:33:54AM -0700:
> > FSAL_LUSTRE actually also uses fcntl to get POSIX locks, so it has the
> > same issues as FSAL_VFS.
>
> LUSTRE would actually like one fd per open or equivalent if we can reap them
> efficiently, for the same rea
Hmm, that looks like a constant that needs to be replaced with a config value…
That does appear to be an absolute hard limit on directory size (and if there
are multiuple READDIR operations in progress, it would seem like you need even
more).
One option would be to make it some percentage
