linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@cse.unsw.edu.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: nfs@lists.sourceforge.net, linux-fsdevel@vger.kernel.org
Subject: Re: i_generation = 0 special casing
Date: Thu, 25 Nov 2004 09:48:03 +1100	[thread overview]
Message-ID: <16805.4003.661292.438937@cse.unsw.edu.au> (raw)
In-Reply-To: message from Christoph Hellwig on Wednesday November 24

On Wednesday November 24, hch@infradead.org wrote:
> export_iget (and routines based on it such as xfs_vget) check for
> i_generation beeing 0 meaning that every generation is okay.  Where in
> the NFS code is this wildcard needed?

On reflection, it is largely a coding convenience :-(

A filehandle can identify both an object, and it's parent directory.
An earlier version of the filehandle (2.2 kernel) contained the
generation number for the object, but not for the parent direction.
To stay compatible with that, we need to cope with not knowing the
generation number.

So the routine that finds a dentry given inode number and generation
number needs to be able to be told "I don't know the generation
number, just accept whatever you find", as that is safe enough when
hunting for the parent directory (if you get the wrong thing by
mistake, you will find out some other way).

To tell the "inum+generation -> dentry" routine "don't worry about the
gernation number", we use a generation number of 0.  This obviously
has problems as you have noted.

It should probably be changed to have an explicit "ignore the
generation number" flag, or just possibly require callers to map '0'
to (e.g.) 1 when passing in a genuine generation number (whether for
filehandle creation or lookup).

> 
> I had to find out that XFS starts it's i_generation at zero and either
> I have to fix up the i_generation or drop this wildcard if it's not
> actually used.

It would certainly be easiest to simply not have generation numbers
ever being zero, but it isn't a nice requirement to put on a
filesystem.

However I cannot immediately see a real solution that is anything
close to clean.  I might try again in a week or so and see if anything
comes to mind.

NeilBrown



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      parent reply	other threads:[~2004-11-24 22:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-24  9:43 i_generation = 0 special casing Christoph Hellwig
2004-11-24 12:25 ` Anton Altaparmakov
2004-11-24 22:48 ` Neil Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16805.4003.661292.438937@cse.unsw.edu.au \
    --to=neilb@cse.unsw.edu.au \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).