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)
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 |
----------------|----------------|----------------|--------- -------|
----------------|-------- --------|----------------|----------------|
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 |
----------------|----------------|----------------|--------- -------|
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?
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.sm and
> > > >
> > > > > 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
