Re: ext4 features

[Bill Davidsen <davidsen@tmr.com>]

J. Bruce Fields wrote:

> 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.
>  
But with timestamps I need remember only one number, the time of my last 
backup. Skipping over the question of "who's idea of time" inherent in 
network filesystems. I compare all ctimes with the time of the last 
backup and do incremental on the newer ones. If we use versioning I have 
to remember the version for each file! In practice I really question if 
the benefit justified keeping all that metadata between backups. And if 
I delete a file and create another by the same name, what is it's version?

I'll say it again, I think ms resolution is readily achieved today, even 
over network files, I think greater resolution or versions are going to 
be more trouble than they are worth.

> (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.

No comment, I would have to see a state table to be sure I saw the races 
or that there were none. With a single writer and a sinple dirty bit 
there is no issue, it behaves like an elevator, more or less. With 
multiple writers I bet changes are written in the order submitted rather 
than the order done, but multiple writers without locks are a train 
wreck waiting to happen anyway.

--
bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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