On Dec 14, 2006 11:48 -0500, Trond Myklebust wrote:
> > The only requirement is that it be unique (assuming a file is never
> > modified 2^64 times). Clients can't compare them except for equality.
>
> The other requirement is that they be updated in more or less any
> situation where you would
On Wed, 2006-12-13 at 20:52 -0500, J. Bruce Fields wrote:
> > What kind of requirements does NFSv4 place on the version? Monotonic is
> > probably a good bet.
>
> The only requirement is that it be unique (assuming a file is never
> modified 2^64 times). Clients can't compare them except for equ
On Wed, Dec 13, 2006 at 06:24:28PM -0700, Andreas Dilger wrote:
> On Sep 13, 2006 14:11 -0400, Trond Myklebust wrote:
> > I would really have preferred a full-blown 64-bit counter as per
> > RFC3530, but I suppose we could always combine this change attribute
> > with the high word from ctime in o
On Sep 13, 2006 14:11 -0400, Trond Myklebust wrote:
> On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> > here is a small patch that adds the "change attribute" for ext3
> > file-systems;
> >
> > the change attribute is a simple counter that is reset to zero on
> > inode creation and
On Sep 15, 2006 12:19 +0200, Alexandre Ratchov wrote:
> BTW, note that when we'll add support for nanosecond time-stamps, we still
> have the same problem, because with a very high clock and time-stamp
> resolutions, we'll have to update the inode on every change.
If we have a journal commit call
On Thu, Sep 14, 2006 at 03:01:48PM -0600, Andreas Dilger wrote:
> On Sep 14, 2006 15:21 +0200, Alexandre Ratchov wrote:
> > IMHO, the natural place to do this stuff is the VFS, because it can be
> > common to all file-systems supporting this feature. Currently it's the same
> > with ctime, mtime a
On Sep 14, 2006 15:21 +0200, Alexandre Ratchov wrote:
> IMHO, the natural place to do this stuff is the VFS, because it can be
> common to all file-systems supporting this feature. Currently it's the same
> with ctime, mtime and atime. These are in the VFS even if there are
> file-systems that don
On Thu, Sep 14, 2006 at 09:46:03AM -0400, Peter Staubach wrote:
> Trond Myklebust wrote:
> >On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> >
> >>hello,
> >>
> >>here is a small patch that adds the "change attribute" for ext3
> >>file-systems;
> >>
> >>the change attribute is a sim
On Thu, 2006-09-14 at 09:46 -0400, Peter Staubach wrote:
> Wouldn't the generation count work better than ctime to differentiate
> between
> instances of files using the same inode number? That way, there wouldn't be
> a clock resolution issue.
No. This is about distinguishing updates to the met
On Thu, Sep 14, 2006 at 03:23:18AM -0600, Andreas Dilger wrote:
> On Sep 13, 2006 20:30 +0200, Alexandre Ratchov wrote:
> > On Wed, Sep 13, 2006 at 02:11:11PM -0400, Trond Myklebust wrote:
> > > On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> > > > the change attribute is a simple co
Trond Myklebust wrote:
On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
hello,
here is a small patch that adds the "change attribute" for ext3
file-systems;
the change attribute is a simple counter that is reset to zero on
inode creation and that is incremented every time the in
On Wed, Sep 13, 2006 at 01:31:30PM -0600, Andreas Dilger wrote:
> On Sep 13, 2006 18:42 +0200, Alexandre Ratchov wrote:
> > the change attribute is a simple counter that is reset to zero on
> > inode creation and that is incremented every time the inode data is
> > modified (similarly to the "ctim
On Sep 13, 2006 20:30 +0200, Alexandre Ratchov wrote:
> On Wed, Sep 13, 2006 at 02:11:11PM -0400, Trond Myklebust wrote:
> > On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> > > the change attribute is a simple counter that is reset to zero on
> > > inode creation and that is incremen
On Wed, Sep 13, 2006 at 01:31:30PM -0600, Andreas Dilger wrote:
> On Sep 13, 2006 18:42 +0200, Alexandre Ratchov wrote:
> > The patch also adds a new ``st_change_attribute'' field in the stat
> > structure, and modifies the stat(2) syscall accordingly. Currently the
> > change is only visible on i
On Wed, 13 Sep 2006 15:06:02 -0400 Trond Myklebust wrote:
> On Wed, 2006-09-13 at 20:30 +0200, Alexandre Ratchov wrote:
> > On Wed, Sep 13, 2006 at 02:11:11PM -0400, Trond Myklebust wrote:
> > > On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> > > > hello,
> > > >
> > > > here is a
On Sep 13, 2006 18:42 +0200, Alexandre Ratchov wrote:
> the change attribute is a simple counter that is reset to zero on
> inode creation and that is incremented every time the inode data is
> modified (similarly to the "ctime" time-stamp).
To start, I'm supportive of this concept, my comments a
On Wed, 2006-09-13 at 20:30 +0200, Alexandre Ratchov wrote:
> On Wed, Sep 13, 2006 at 02:11:11PM -0400, Trond Myklebust wrote:
> > On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> > > hello,
> > >
> > > here is a small patch that adds the "change attribute" for ext3
> > > file-system
On Wed, Sep 13, 2006 at 02:11:11PM -0400, Trond Myklebust wrote:
> On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> > hello,
> >
> > here is a small patch that adds the "change attribute" for ext3
> > file-systems;
> >
> > the change attribute is a simple counter that is reset to ze
On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote:
> hello,
>
> here is a small patch that adds the "change attribute" for ext3
> file-systems;
>
> the change attribute is a simple counter that is reset to zero on
> inode creation and that is incremented every time the inode data is
> m
hello,
here is a small patch that adds the "change attribute" for ext3
file-systems;
the change attribute is a simple counter that is reset to zero on
inode creation and that is incremented every time the inode data is
modified (similarly to the "ctime" time-stamp).
Its purpose is to make possi
20 matches
Mail list logo
