xfs
[Top] [All Lists]

Re: [reiserfs-list] Re: benchmarks

To: Hans Reiser <reiser@xxxxxxxxxxx>
Subject: Re: [reiserfs-list] Re: benchmarks
From: Xuan Baldauf <xuan--reiserfs@xxxxxxxxxxx>
Date: Wed, 18 Jul 2001 01:08:22 +0200
Cc: Nikita Danilov <NikitaDanilov@xxxxxxxxx>, Xuan Baldauf <xuan--reiserfs@xxxxxxxxxxx>, "Ragnar Kjørstad" <reiserfs@xxxxxxxxxxxxxxxxxxx>, Russell Coker <russell@xxxxxxxxxxxx>, Chris Wedgwood <cw@xxxxxxxx>, rsharpe@xxxxxxxxxx, Seth Mos <knuffie@xxxxxxxxx>, Federico Sevilla III <jijo@xxxxxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, reiserfs-list@xxxxxxxxxxx
References: <Pine.BSI.4.10.10107141752080.18419-100000@xs3.xs4all.nl> <3B5169E5.827BFED@namesys.com> <20010716210029.I11938@weta.f00f.org> <20010716101313.2DC3E965@lyta.coker.com.au> <3B52C49F.9FE1F503@namesys.com> <15186.51514.66966.458597@beta.namesys.com> <3B5341BA.1F68F755@baldauf.org> <15187.18225.196286.123754@beta.namesys.com> <3B534B74.BDE19961@baldauf.org> <20010716223240.D14564@vestdata.no> <3B5363FE.3A7D892F@baldauf.org> <3B53F65D.265034CB@namesys.com> <15188.10675.283457.862145@beta.namesys.com> <3B54BF39.4826A17A@namesys.com>
Sender: owner-linux-xfs@xxxxxxxxxxx

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.



<Prev in Thread] Current Thread [Next in Thread>