Linux NFS development
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Does NFS4 need st_gen?
Date: Fri, 21 Oct 2011 12:09:49 -0400	[thread overview]
Message-ID: <4EA1994D.6060700@rath.org> (raw)
In-Reply-To: <1319212854.4537.9.camel@lade.trondhjem.org>

On 10/21/2011 12:00 PM, Trond Myklebust wrote:
> On Fri, 2011-10-21 at 09:54 -0400, Nikolaus Rath wrote: 
>> Trond Myklebust <Trond.Myklebust@netapp.com> writes:
>>> On Thu, 2011-10-20 at 16:37 -0400, Nikolaus Rath wrote: 
>>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>>> On Thu, Oct 20, 2011 at 01:21:31PM -0400, Nikolaus Rath wrote:
>>>>>> I'm working on a FUSE file system that stores file system metadata in an
>>>>>> SQL database (http://code.google.com/p/s3ql/). Not having to keep track
>>>>>> of inode generation numbers would keep the code much simpler, because I
>>>>>> want to delete inode-rows from the SQL table when the last reference to
>>>>>> the inode is deleted (so I can't keep track of the generation no).
>>>>>
>>>>> You can use current time, or a counter, or something, as the generation
>>>>> number.
>>>>
>>>> With current time I'm screwed if the system clock doesn't have
>>>> sufficiently fine granularity. With a counter, I either have to remember
>>>> counter values per-inode even after the inode is deleted, or the global
>>>> counter will overflow at some point (in which case I may just as well
>>>> require unique inodes in the first place).
>>>
>>> The filehandle is between 32 (NFSv2) and 128(NFSv4) bytes long. How long
>>> do you expect it to take you to create+destroy between 2^256 and 2^1024
>>> inodes? I'm guessing that we'll all be long dead and the universe will
>>> have undergone heat death before that happens...
>>
>> Please stop assuming that I'm stupid or haven't thought about the
>> problem at all. The bottleneck is not the length of the NFS file handle,
>> but the length of the inode and generation number (both of which are
>> restricted to 32bit by FUSE) together with the requirement that not only
>> both of them together need to be unique forever, but the inode also
>> needs to be unique at any given instant (so they cannot be trivially
>> combined to form a 64bit value).
> 
> No. The point is you don't need a generation number if you don't want to
> implement one...
> 
> You can use any unique identifier + the inode number, and the unique
> identifier is only limited by the size of the filehandle.

So how do you choose the unique identifier? It's limited by FUSE to
32bit and therefore can't be a global counter, it can't be a timestamp
because the system clock may not have enough resolution, and it can't be
a per-inode counter because then I can't discard the counter after the
inode has been deleted.

Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

  reply	other threads:[~2011-10-21 16:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19 14:17 Does NFS4 need st_gen? Nikolaus Rath
2011-10-19 17:15 ` J. Bruce Fields
2011-10-19 19:11   ` Nikolaus Rath
2011-10-20 12:02     ` J. Bruce Fields
2011-10-20 17:21       ` Nikolaus Rath
2011-10-20 19:57         ` J. Bruce Fields
2011-10-20 20:37           ` Nikolaus Rath
2011-10-21  0:07             ` Trond Myklebust
2011-10-21 13:54               ` Nikolaus Rath
2011-10-21 16:00                 ` Trond Myklebust
2011-10-21 16:09                   ` Nikolaus Rath [this message]
2011-10-21 17:10                     ` Trond Myklebust
2011-10-21 17:44                       ` Nikolaus Rath
2011-10-22 18:47                         ` Boaz Harrosh
2011-10-22 18:59                           ` Boaz Harrosh
2011-10-22 20:10                           ` Nikolaus Rath

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=4EA1994D.6060700@rath.org \
    --to=nikolaus@rath.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    /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