Re: [Nfs-ganesha-devel] Need a second opinion on some code

2017-06-14 Thread Frank Filz 
> don't blame RGW;  RGW's ability to provide the cookie/offset for any name
> isn't even exposed or in use, at this point; (but it's awesome, isn't it? :)

Not blaming RGW... Just observing I might have goofed up when I tried to 
facilitate RGW's awesomeness...

But I might also not have goofed up, the previous code may have dumped dirents 
anyway...

Frank

> - Original Message -
> > From: "Daniel Gryniewicz" 
> > To: "Frank Filz" 
> > Cc: "NFS Ganesha Developers" 
> > Sent: Wednesday, June 14, 2017 9:56:33 AM
> > Subject: Re: [Nfs-ganesha-devel] Need a second opinion on some code
> >
> > I think it's worse than that.  It will blow away all dirents in a
> > directory on any rename, lookup, or link, if the FSAL is not RGW (or
> > rather, if the FSAL doesn't support computing cookies).  I'm not sure
> > how to handle this, though.  Just putting the dirent into a loose list
> > breaks enumeration order, right?
> >
> > Daniel
> >
> > On Tue, Jun 13, 2017 at 6:08 PM, Frank Filz 
> wrote:
> > > Hmm, I think the following code blows our dirent cache if we are not
> > > able to add the dirent for a created file to a chunk (either because
> > > there isn't a chunk to add it to, or the FSAL is not RGW):
> > >
> > > if (new_dir_entry == allocated_dir_entry &&
> > > mdcache_param.dir.avl_chunk > 0) {
> > > /* If chunking, try and add this entry to a chunk. */
> > > bool chunked = add_dirent_to_chunk(parent,
> > > new_dir_entry);
> > >
> > > if (!chunked && *invalidate) {
> > > /* If chunking and invalidating parent, and
> > > chunking
> > >  * this entry failed, invalidate parent.
> > >  */
> > > mdcache_dirent_invalidate_all(parent);
> > > } else if (chunked && *invalidate) {
> > > /* We succeeded in adding to chunk, don't
> > > invalidate
> > > the
> > >  * parent directory.
> > >  */
> > > *invalidate = false;
> > > }
> > > }
> > >
> > > This means the only time we will actually have any loose dirents is
> > > due to lookups...
> > >
> > > I don't think we should blow out the loose dirents in this case,
> > > though we need to blow out any chunks since they are no longer valid.
> > >
> > > Frank
> > >
> > >
> > >
> > > ---
> > > This email has been checked for viruses by Avast antivirus software.
> > > https://www.avast.com/antivirus
> > >
> > >
> > > 
> > > -- Check out the vibrant tech community on one of the
> > > world's most engaging tech sites, Slashdot.org!
> > > http://sdm.link/slashdot
> > > ___
> > > Nfs-ganesha-devel mailing list
> > > Nfs-ganesha-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
> > --
> >  Check out the vibrant tech community on one of the world's
> > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
> 
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
> 
> http://www.redhat.com/en/technologies/storage
> 
> tel.  734-821-5101
> fax.  734-769-8938
> cel.  734-216-5309


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Need a second opinion on some code

2017-06-14 Thread Matt Benjamin 
don't blame RGW;  RGW's ability to provide the cookie/offset for any name isn't 
even exposed or in use, at this point; (but it's awesome, isn't it? :)

Matt

- Original Message -
> From: "Daniel Gryniewicz" 
> To: "Frank Filz" 
> Cc: "NFS Ganesha Developers" 
> Sent: Wednesday, June 14, 2017 9:56:33 AM
> Subject: Re: [Nfs-ganesha-devel] Need a second opinion on some code
> 
> I think it's worse than that.  It will blow away all dirents in a
> directory on any rename, lookup, or link, if the FSAL is not RGW (or
> rather, if the FSAL doesn't support computing cookies).  I'm not sure
> how to handle this, though.  Just putting the dirent into a loose list
> breaks enumeration order, right?
> 
> Daniel
> 
> On Tue, Jun 13, 2017 at 6:08 PM, Frank Filz  wrote:
> > Hmm, I think the following code blows our dirent cache if we are not able
> > to
> > add the dirent for a created file to a chunk (either because there isn't a
> > chunk to add it to, or the FSAL is not RGW):
> >
> > if (new_dir_entry == allocated_dir_entry &&
> > mdcache_param.dir.avl_chunk > 0) {
> > /* If chunking, try and add this entry to a chunk. */
> > bool chunked = add_dirent_to_chunk(parent, new_dir_entry);
> >
> > if (!chunked && *invalidate) {
> > /* If chunking and invalidating parent, and
> > chunking
> >  * this entry failed, invalidate parent.
> >  */
> > mdcache_dirent_invalidate_all(parent);
> > } else if (chunked && *invalidate) {
> > /* We succeeded in adding to chunk, don't
> > invalidate
> > the
> >  * parent directory.
> >  */
> > *invalidate = false;
> > }
> > }
> >
> > This means the only time we will actually have any loose dirents is due to
> > lookups...
> >
> > I don't think we should blow out the loose dirents in this case, though we
> > need to blow out any chunks since they are no longer valid.
> >
> > Frank
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: gpfs: Fix upcall using an export that could go away

2017-06-14 Thread GerritHub 
>From Malahal :

Malahal has uploaded this change for review. ( 
https://review.gerrithub.io/365479


Change subject: gpfs: Fix upcall using an export that could go away
..

gpfs: Fix upcall using an export that could go away

Some of the upcall processing procedures require a valid export in
op_ctx. Currently we set it to first export and removal of such an
export could cause accessing invalid memory.

Upcall processing is done under upvector mutex to avoid an export going
away. Upcall thread now uses setup_up_vector to select a valid export
from the file system's list of exports.

Also re-organized gpfs_claim_filesystem() to avoid creating file system
upcall thread before the export is put into on_exports map list.

Change-Id: I2ccb78c2ddf5c2f43ced15ecf13add5e410b37cd
Signed-off-by: Malahal Naineni 
---
M src/FSAL/FSAL_GPFS/export.c
M src/FSAL/FSAL_GPFS/fsal_up.c
M src/FSAL/FSAL_GPFS/gpfs_methods.h
3 files changed, 107 insertions(+), 55 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/79/365479/1
-- 
To view, visit https://review.gerrithub.io/365479
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I2ccb78c2ddf5c2f43ced15ecf13add5e410b37cd
Gerrit-Change-Number: 365479
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] FSAL_PROXY : from v4.0 to v4.1

2017-06-14 Thread patrice.lucas 

Hi,


FSAL_PROXY v4.1 code seems now to be stable enough. I removed WIP tag 
from the https://review.gerrithub.io/#/c/357505/ patch.



Regards,

Patrice


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Need a second opinion on some code

2017-06-14 Thread Daniel Gryniewicz 
I think it's worse than that.  It will blow away all dirents in a
directory on any rename, lookup, or link, if the FSAL is not RGW (or
rather, if the FSAL doesn't support computing cookies).  I'm not sure
how to handle this, though.  Just putting the dirent into a loose list
breaks enumeration order, right?

Daniel

On Tue, Jun 13, 2017 at 6:08 PM, Frank Filz  wrote:
> Hmm, I think the following code blows our dirent cache if we are not able to
> add the dirent for a created file to a chunk (either because there isn't a
> chunk to add it to, or the FSAL is not RGW):
>
> if (new_dir_entry == allocated_dir_entry &&
> mdcache_param.dir.avl_chunk > 0) {
> /* If chunking, try and add this entry to a chunk. */
> bool chunked = add_dirent_to_chunk(parent, new_dir_entry);
>
> if (!chunked && *invalidate) {
> /* If chunking and invalidating parent, and chunking
>  * this entry failed, invalidate parent.
>  */
> mdcache_dirent_invalidate_all(parent);
> } else if (chunked && *invalidate) {
> /* We succeeded in adding to chunk, don't invalidate
> the
>  * parent directory.
>  */
> *invalidate = false;
> }
> }
>
> This means the only time we will actually have any loose dirents is due to
> lookups...
>
> I don't think we should blow out the loose dirents in this case, though we
> need to blow out any chunks since they are no longer valid.
>
> Frank
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel