Thanks for the explanation, Bart!
I misread the ncache to be indexed purely on names..
Thanks,
Murali
> Murali,
>
> If I understand your question correctly, I don't think that there is a
> problem.
> Rename doesn't create a new object ref when it renames. It uses the same ref
> with the same handle and fsid. Objects in ncache only care about their
> parent's
> object ref, not the name associated with that object ref. Here is a little
> more
> expanded example of the idea.
>
> We'll assume up front all of the fsids are the same, and the root handle is
> 0.
>
> We start with a few nested directories:
> /a has handle 100. parent handle is 0.
> /a/b has handle 200. parent handle is 100.
> /a/c has handle 300. parent handle is 100.
> /a/d has handle 400. parent handle is 100.
>
> readdir("/a"); (patch populates the ncache with all contents of /a)
> ncache would look like this:
> ----------------|-------- --------|----------------|----------------|
> Name : "a" |Name : "b" |Name : "c" |Name : "d" |
> Handle : 100 |Handle : 200 |Handle : 300 |Handle : 400 |
> Parent Ref: 0 |Parent Ref: 100 |Parent Ref: 100 |Parent Ref: 100 |
> ----------------|----------------|----------------|--------- -------|
>
> rename("/a", "/b"); (patch invalidates only the ncache entry for "/a")
>
> At this point, /b has the handle 100, and the parent handle of 0.
>
> So, our directories look like this now:
> /b has handle 100. parent handle is 0. (not in ncache)
> /b/b has handle 200. parent handle is 100. (in ncache, but parent_ref still
> okay)
> /b/c has handle 300. parent handle is 100. (in ncache, but parent_ref still
> okay)
> /b/d has handle 400. parent handle is 100. (in ncache, but parent_ref still
> okay)
>
> ncache would now look like this:
> ----------------|-------- --------|----------------|----------------|
> Name : "b" |Name : "b" |Name : "c" |Name : "d" |
> Handle : 100 |Handle : 200 |Handle : 300 |Handle : 400 |
> Parent Ref: 0 |Parent Ref: 100 |Parent Ref: 100 |Parent Ref: 100 |
> ----------------|----------------|----------------|--------- -------|
>
> mkdir("/a"); (patch populates the ncache for /a)
> /a has handle 500. parent handle is 0. (in ncache. not connected to
> anything else)
>
> lookup("/a/b") This lookup would fail because there is no /b entry that has
> a parent with handle=500
>
> Does this answer your question?
>
> Bart
>
>
>
>
>
> On 6/19/06, Murali Vilayannur <[EMAIL PROTECTED]> wrote:
> >
> > Bart,
> > Sorry for asking more questions..
> > Consider the following scenario,
> >
> > readdir("/a"); (patch populates the ncache with all contents of /a)
> > rename("/a", "/b"); (patch invalidates only the ncache entry for "/a")
> >
> > mkdir("/a"); (patch populates the ncache for /a)
> > lookup("/a/b") (This could get the handle of object b that was under /a
> > prior to the rename!)
> >
> > I guess what I am asking is shouldn't rename invalidate strings
> > matching entire prefixes from the ncache during a rename?
> > Thanks,
> > Murali
> >
> > On Fri, 16 Jun 2006, Bart Taylor wrote:
> >
> > > Attached is an updated version of the patch that just invalidates the
> > ncache
> > > entries when sys-rename is called so there shouldn't be any cache
> > > inconsistencies. I'll submit a spearate patch to have it update
> > properly.
> > >
> > > Bart
> > >
> > >
> > >
> > > On 6/15/06, Bart Taylor <[EMAIL PROTECTED]> wrote:
> > > >
> > > > That's a good point. Rename should at the very least invalidate both
> > > > entries. The old implementation of ncache did not handle this either,
> > so
> > > > this will be new (although needed). I'll update the patch to
> > invalidate the
> > > > two entries and send it out again, and then work on another patch to
> > update
> > > > where appropriate.
> > > >
> > > > Thanks
> > > > Bart
> > > >
> > > >
> > > >
> > > > On 6/14/06, Murali Vilayannur <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Bart,
> > > > > Do tests like dbench or concurrent directory renames and listings
> > pass
> > > > > with the ncache patches?
> > > > > I noticed that renames of files/directories are not handled by the
> > patch
> > > > > (in which case cached names of subdirectories/files under that path
> > may
> > > > > have to be invalidated/updated).
> > > > > Thanks,
> > > > > Murali
> > > > >
> > > > > On Tue, 13 Jun 2006, Bart Taylor wrote:
> > > > >
> > > > > > Sorry about that. It should be attached now.
> > > > > >
> > > > > > Bart
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Murali Vilayannur [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Tuesday, June 13, 2006 10:29 AM
> > > > > > To: Bart Taylor
> > > > > > Subject: Re: [Pvfs2-developers] patch: ncache.patch
> > > > > >
> > > > > >
> > > > > >
> > > > > > Bart,
> > > > > >
> > > > > > Can you resend the patch? I dont think I saw the attachment..
> > Perhaps
> > > > > the
> > > > > >
> > > > > > patch was too big for the list?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Murali
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 12 Jun 2006, Bart Taylor wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > This patch is a reimplementation of name cache based off tcache,
> > and
> > > > > it
> > > > > > now
> > > > > >
> > > > > > > bears a striking resemblance to the attribute cache. There was
> > a
> > > > > >
> > > > > > > significant API change, but that did not have an effect other
> > than
> > > > > > fixing
> > > > > >
> > > > > > > the calls already in place. There are no changes to the wire
> > > > > protocol
> > > > > > or
> > > > > >
> > > > > > > the storage format. It also includes perf-counter support for
> > > > > > monitoring.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > The state machines have several changes to use the new API, but
> > the
> > > > > >
> > > > > > > functionality stayed the same in most places. Sys-readdir.smand
> > > > > >
> > > > > > > sys-lookup.sm had some minor changes/additions to make ncache
> > update
> > > > > >
> > > > > > > properly. Lookup-ncache.sm now only checks the cache for one
> > segment
> > > > > of
> > > > > > the
> > > > > >
> > > > > > > path at a time instead of the entire path at once. The new
> > ncache
> > > > > > stores
> > > > > >
> > > > > > > individual path segments independently.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > There were updates to pvfs2-client.c and pvfs2-client-core.c to
> > > > > accept
> > > > > > the
> > > > > >
> > > > > > > new ncache options and deal with them appropriately. There were
> > also
> > > > > >
> > > > > > > additions in upcall.h and pvfs2-proc.c. Pvfs2-proc has a
> > > > > generalization
> > > > > > of
> > > > > >
> > > > > > > one of the functions to be used for both attribute cache and
> > name
> > > > > cache.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > Tuning for ncache can be done with the proc files in
> > > > > >
> > > > > > > /proc/sys/pvfs2/ncache. They mimic the acache options:
> > hard-limit,
> > > > > >
> > > > > > > soft-limit, reclaim-percentage, and timeout-msecs. The
> > performace
> > > > > > counters
> > > > > >
> > > > > > > also imitate acache and are located in
> > > > > > /proc/sys/pvfs2/perf-counters/ncache.
> > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
