On Tue, 2007-07-10 at 22:17 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 22:09:08 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
David Chinneer pointed that we need to journal the version number
updates together with the operations that causes the change of the inode
version number, in
On Tue, 10 Jul 2007 23:18:50 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
On Tue, 2007-07-10 at 22:17 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 22:09:08 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
David Chinneer pointed that we need to journal the version number
updates together
On Jul 10, 2007 23:34 -0400, Trond Myklebust wrote:
On Wed, 2007-07-11 at 13:21 +1000, Neil Brown wrote:
So my vote is to increment i_version in common code every time any
change is made to the file, and alloc_inode should initialise it to
current time, which might be changed by the
On Wed, Jul 11, 2007 at 01:21:55PM +1000, Neil Brown wrote:
And just by-the-way, the server doesn't really have the option of not
sending the attribute. If i_version isn't defined, it has to fake
something using mtime, and hope that is good enough.
ctime, actually--the change attribute is
On Wed, Jul 11, 2007 at 09:28:06AM -0500, Dave Kleikamp wrote:
On Wed, 2007-07-11 at 15:05 +1000, Neil Brown wrote:
It just occurred to me:
If i_version is 64bit, then knfsd would need to be careful when
reading it on a 32bit host. What are the locking rules?
How does knfsd use
On Sun, 01 Jul 2007 03:37:04 -0400
Mingming Cao [EMAIL PROTECTED] wrote:
This patch converts the 32-bit i_version in the generic inode to a 64-bit
i_version field.
That's obvious from the patch. But what was the reason for making this
(unrelated to ext4) change?
Please update the changelog
On Tuesday July 10, [EMAIL PROTECTED] wrote:
Yes, thanks. It doesn't actually tell us why we want to implement
this attribute and it doesn't tell us what the implications of failing
to do so are, but I guess we can take that on trust from the NFS guys.
You would like to think so, but
On Wed, 2007-07-11 at 13:21 +1000, Neil Brown wrote:
On Tuesday July 10, [EMAIL PROTECTED] wrote:
Yes, thanks. It doesn't actually tell us why we want to implement
this attribute and it doesn't tell us what the implications of failing
to do so are, but I guess we can take that on trust
It just occurred to me:
If i_version is 64bit, then knfsd would need to be careful when
reading it on a 32bit host. What are the locking rules?
Presumably it is only updated under i_mutex protection, but having to
get i_mutex to read it would seem a little heavy handed.
Should it use a
On Tue, 10 Jul 2007 22:09:08 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
David Chinneer pointed that we need to journal the version number
updates together with the operations that causes the change of the inode
version number, in order to survive server crashes so clients won't see
the
On Wed, 11 Jul 2007 15:05:27 +1000 Neil Brown [EMAIL PROTECTED] wrote:
It just occurred to me:
If i_version is 64bit, then knfsd would need to be careful when
reading it on a 32bit host. What are the locking rules?
Presumably it is only updated under i_mutex protection, but having
On Tue, 2007-07-10 at 21:22 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 20:19:16 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
On Tue, 2007-07-10 at 18:22 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 18:09:40 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
On Tue, 2007-07-10 at
On Fri, 2007-07-06 at 16:53 -0600, Andreas Dilger wrote:
On Jul 06, 2007 09:51 -0400, J. Bruce Fields wrote:
The use of a mount option means the change attribute could be
inconsistent across mounts. If we really need this, wouldn't it make
more sense for it to be a persistent feature of
On Tue, Jul 03, 2007 at 05:32:00PM -0600, Andreas Dilger wrote:
On Jul 03, 2007 18:15 -0400, J. Bruce Fields wrote:
How will nfsd tell whether it can really on a given filesystem's
i_version, or whether it should fall back on ctime?
Good question.
Well, we don't need anything
On Jul 06, 2007 09:51 -0400, J. Bruce Fields wrote:
The use of a mount option means the change attribute could be
inconsistent across mounts. If we really need this, wouldn't it make
more sense for it to be a persistent feature of the filesystem, set at
mkfs time?
Yes, having it stored into
On Jul 03, 2007 10:24 -0400, Trond Myklebust wrote:
It looks OK to me, but you might want to strip out the now redundant
i_version updates in add_dirent_to_buf(), ext4_rmdir(), ext4_rename().
Agreed, and I thought we discussed that already on the ext4 list.
I also have some questions about
On Mon, Jul 02, 2007 at 10:58:33AM -0400, Mingming Cao wrote:
Trond or Bruce, can you please review these patch series and ack if you
agrees?
Thanks, looks like what we need!
How will nfsd tell whether it can really on a given filesystem's
i_version, or whether it should fall back on ctime?
On Jul 03, 2007 18:15 -0400, J. Bruce Fields wrote:
How will nfsd tell whether it can really on a given filesystem's
i_version, or whether it should fall back on ctime?
Good question.
As to performance concerns that raise before the inode version counter
(at least for ext4) is done inside
18 matches
Mail list logo
