> 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" <d...@redhat.com>
> > To: "Frank Filz" <ffilz...@mindspring.com>
> > Cc: "NFS Ganesha Developers" <nfs-ganesha-devel@lists.sourceforge.net>
> > 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 <ffilz...@mindspring.com>
> 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
