From: Cordenner jean noel <jean-noel.cordenner@bull.net>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@clusterfs.com>, linux-ext4@vger.kernel.org
Subject: Re: [RFC] [patch 2/3] change attribute for ext4: ext4 specific code
Date: Fri, 15 Dec 2006 11:36:40 +0100 [thread overview]
Message-ID: <45827AB8.6020400@bull.net> (raw)
In-Reply-To: <20061214160307.GE9079@thunk.org>
Theodore Tso a écrit :
> On Wed, Dec 13, 2006 at 06:31:50PM +0100, Cordenner jean noel wrote:
>
> There was discussion on yesterday's call about whether or not 32-bit
> was enough for NFSv4, or whether it also requried 64-bits of change
> notification in the RFC's. So one of the questions is whether this is
> something that would justify requiring 64-bits --- and if so, maybe we
> need to require that big inodes be used and store the entire 64-bit
> value beyond 128 bytes. This would mean that NFSv4 cache management
> couldn't be fully implemented without big inodes, or we'd have to make
> do by using the inode ctime as a partial substitute.
>
> What do you think?
>
> - Ted
>
Well it seems that NFSv4 RFC requires a 64-bits notification.
The interest of the change attribute is that it has a simple
implementation and doesn't seem to penalize the performance.
Using a 32bits counter and the ctime can give a resolution less than ns.
But it seems to me that finner timestamp could be usefull in the future.
As the ns patch also use a counter, I don't know if a common
implementation would avoid using big inode.
I agree with Andreas saying that the "change_attribute" can be stored in
the i_version field.
Jean noel
prev parent reply other threads:[~2006-12-15 10:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 18:54 [RFC] [patch 2/3] change attribute for ext4: ext4 specific code Jean-Noel Cordenner
2006-12-06 21:49 ` Andreas Dilger
2006-12-13 17:31 ` Cordenner jean noel
2006-12-14 16:03 ` Theodore Tso
2006-12-14 22:57 ` Andreas Dilger
2006-12-15 10:36 ` Cordenner jean noel [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=45827AB8.6020400@bull.net \
--to=jean-noel.cordenner@bull.net \
--cc=adilger@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.