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" <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
