Hans Reiser wrote:
> Nikita Danilov wrote:
> >
> > Hans Reiser writes:
> > > A file change notification API is an inherently reasonable thing to
> > have, for use by more than just
> > > NFS (emacs for instance).
> >
> > What's wrong with fcntl( F_NOTIFY )?
> > I mean, there is standard notification API (and several non-standard
> > ones, stolen from BSD) in Linux.
> >
> > >
> > > Hans
> >
> > Nikita.
> >
> > >
> > > Xuan Baldauf wrote:
> > > >
> > > > Ragnar Kjørstad wrote:
> > > >
> > > > > > > For each open file you have:
> > > > > > >
> > > > > > > struct file (96b)
> >
> > Nikita.
> It might be perfect for NFS. My man page for fcntl doesn't list F_NOTIFY. I
> will guess at what it
> does though (yah, I know, I should read the source, but it is late), and say
> that it or something
> resembling it should be used by NFS. Generation numbers have the feel of a
> hack, to my mind. I
> would probably feel better about generation numbers if they didn't take up
> space in the stat data,
> but they would still feel like a hack.
>
> So, do I understand right that Xuan's solution could eliminate the need to
> store the generation
> number in the stat data? The problem with Xuan's solution though, is that it
> is easier to randomly
> obtain identical generation numbers for differing versions of the same file.
> Am I right?
>
> Maybe in V4 we can make the attribute holding generation numbers be
> dynamically allocated. That
> way, NFS doesn't burden other FS uses. I bet we won't have time for that
> extra touch of programming
> before we ship code though. Sigh.
>
> Hans
Maybe we're talking about different things, maybe not:
You need generation numbers for not creating a filesystem object with the same
object_id after deleting a
filesystem object with that object_id?
If this is the case, you apparently need to reserve some space within the
object_id for the generation
number (e.g. 32 bits should be sufficient). Because in this case, the
generation number is part of the
object_id, why do you need another stat data field?
How long is the object_id? 16 bytes? The NFS filehandle is 32 bytes wide (at
maximum), so where is the
problem (except maybe that object_ids are converted to VFS inode numbers, which
are exportet then by nfsd,
but this is a linux-, not a NFS-problem)?
Xuân.
|