From: Noveck, Dave (dave.noveck@netapp.com)
Date: 05/20/99-04:15:24 PM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA033035DE@TAHOE.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: Caching Redeparture (was Re: File handles and hard links)
Date: Thu, 20 May 1999 14:15:24 -0700
> On Thu May 20 19:40:06 1999, Noveck, Dave wrote:
> >
> > >
> > > > In UNIX file systems we have the inode serial number to
> distiguish
> > > > objects which have the same name at different times (mkdir a;
> > > > rmdir a; mkdir a). Is there anything discriminating in your FH?
> > >
> > > The create time of the file is the only thing that can be used in
> > this
> > > manner. The File ID is not there for FAT filesystems.
> >
> > What's the granularity of the create time. Is it
> sufficient to assure
> > uniqueness?
>
> No. On FAT filesystems the time is stored in 2 second intervals... We
> do what we can.
Let's see. We accelerate the system to .999C ... I guess that won't
work either :-)
>
> >
> > >
> > > It is possible but I would like to ask others if any NFS server
> > > implements an in memory database which stores EVERY single file
> > which
> > > the NFS server serves?
> >
> > I'm not sure where the memory database is coming in here.
>
> Unless ALL (accessed) files FileHandle, fileid and pathname are stored
> in memory how can you tell if a given fileid has already been used to
> access a file and what the associated FileHandle is.
>
> Also this memory database would have to store every full pathname to
> all the different names for the link. This is because access is via
> pathnames and should one link be removed we would still have to be
> able to open the file given one of the other pathnames for the file
> object.
The original question (which you don't quote above) to which your
remark about a memorydatabase was a response was this:
>
> If the NFSv4 file attributes included some sort of identity
> (fsid/fileid, cache cookie, whatever), would HCL be able
> to implement it in these hard-link cases? Would it even matter?
I guess your implicit response is that it would be impossible to
implement such a thing without a large memory database. Is that
right?
>
> Hummmm....
>
> What if you have the file /mnt/a which was hardlinked to /mnt/b and
> as is typical the client caches the FileHandle from the LOOKUPFH of
> /mnt/a. Then another user removes /mnt/a and creates an entirely new
> file /mnt/a. What should the behaviour be when the client does a READ
> of /mnt/a after this point, but uses the cached FileHandle?
Well its been my position all along that giving the user the wrong
data from the new /mnt/a is the wrong thing, but that ESTALE or
some other error OK if you can't provide data from the old /mnt/a.
Right now, however, I'm try to design solution but just to understand
the constraints on a solution. I want to understand what combinations
of characteristics of servers are out there. In a particular, I'd like
to know what combinations of the following characteristics exist:
a) Has hard links
b) Can turn a name into a unique-at-a-given-instant id
c) Can turn a name into a unique-for-(almost)-all-time id
>
>
> >
> > First of all, is it the case that you have hard links? I thought NT
> > didn't have them. (I'll stack up my ignorance of NT against
> > anybody's).
>
> NTFS supports hardlinks. The MKS toolkit for NT comes with a LN
> program.
I have the MKS toolkit. It makes me feel calmer given that I have an
NT system on desk. So I try "ln Z ZZ" and then it lets me do,
"ls -i Z*" and it shows me something that at least purports to
be inode#/fileid and it is the same for both links. Is this what it
is or is it something hoked up that you can't really depend on. So,
in my terms above, is NTFS a+b+!c or is it a+!b+!c ?
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:06 AM Z CST