On Jul 11, 2007 16:04 -0400, J. Bruce Fields wrote:
> A 32-bit i_version could in theory wrap pretty quickly, couldn't it?
> That's not a problem in itself--the problem would only arise if two
> subsequent client queries of the change attribute happened a multiple of
> 2^32 i_version increments ap
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 knf
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 a
On Tue, Jul 10, 2007 at 08:19:16PM -0400, Mingming Cao wrote:
> On Tue, 2007-07-10 at 18:22 -0700, Andrew Morton wrote:
> > And how does the NFS server know that the filesystem implements i_version?
> > Will a zero-value of i_version have special significance, telling the
> > server to not send th
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 i_version? I would think that if all it was doing
was to compare (i_v
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 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
> > > upd
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 numb
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,
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
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, 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 o
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 se
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 16:30 -0700, Andrew Morton wrote:
> > > > On Sun, 01
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 o
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 rem
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 16:30 -0700, Andrew Morton wrote:
> > > On Sun, 01 Jul 2007 03:37:04 -0400
> > > Mingming Cao <[EMAIL PROTECTED]> wrote:
> > >
> > > > T
On Tue, 10 Jul 2007 18:09:40 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> > 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-b
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> 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 rea
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 chang
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 featur
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 i
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 parti
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 i
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 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, 2007-07-02 at 10:58 -0400, Mingming Cao wrote:
> Trond or Bruce, can you please review these patch series and ack if you
> agrees? Thanks.
>
> As to performance concerns that raise before the inode version counter
> (at least for ext4) is done inside ext4_mark_inode_dirty), so there is
> n
Trond or Bruce, can you please review these patch series and ack if you
agrees? Thanks.
As to performance concerns that raise before the inode version counter
(at least for ext4) is done inside ext4_mark_inode_dirty), so there is
no extra IO work to store this counter to disk.
Mingming
On Sun, 20
This patch converts the 32-bit i_version in the generic inode to a 64-bit
i_version field.
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
Signed-off-by: Jean Noel Cordenner <[EMAIL PROTECTED]>
Signed-off-by: Kalpak Shah <[EMAIL PROTECTED]>
Index: linux-2.6.21/include/linux/fs.h
=
29 matches
Mail list logo