Re: ext4 features

[J. Bruce Fields]

On Wed, Jul 05, 2006 at 05:12:54PM -0400, Bill Davidsen wrote:
> J. Bruce Fields wrote:
> >Or we could add an entirely separate attribute that's guaranteed to
> >increase whenever the ctime is updated, and that doesn't necessarily
> >have any connection with time--call it a version number or something.
> >
> There are versions in both VMS and the ISO filesystem. I have a sneaking 
> suspicion that those of us who ever use them are few and far between. 
> The other issue is that unless the field is time, programs like make 
> can't really use it, at least without becoming Linux specific.

Sure.

> I'm not sure exactly how a "version" value would be used other than 
> detecting the fact that the file had been changed in some way.

I agree.  But "detecting the fact that the file has been changed" is a
really important use!  I think the challenge would be to come up with
applications that really depend on timestamps and that use them for
anything *other* than detecting when a file has changed.

(OK, so make is a special case--it cares not only about whether a file
has changed, but also about whether it has changed more recently than
some other file.  But I'd think a simple version would useful to any
network filesystem, or more generally to anything that caches a view of
the filesystem either on another machine or in userspace.)

> Feel free to show me, I seem to come up empty on using this value.

Betraying my own interests--the NFSv4 protocol (unlike v2 or v3) uses a
specialized "change" attribute to maintain cache consistency instead of
depending on mtime/ctime.  So nfsd would be one immediate in-kernel
user.  Currently we're using ctime, which causes obvious problems.

But an improved ctime--one that actually increased whenever the file
changed--would also do the job.

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/