Re: ext4 features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2006-07-10 at 18:37 -0400, Bill Davidsen wrote:
> Trond Myklebust wrote:
> 
> >On Sat, 2006-07-08 at 17:04 -0400, Bill Davidsen wrote:
> >  
> >
> >>No, I didn't quite mean a manual touch, but a system call to "close and 
> >>set time to high resolution" for files where time uniformity is 
> >>important. Consider that in most cases the inodes times are set by the 
> >>host machine clock, which I close the change reflects the fileserving 
> >>host idea of time. If there were a call to close a file and set the 
> >>times like touch, then that could be used, for both local and network files.
> >>    
> >>
> >
> >Close should never update the time since that would be a violation of
> >POSIX rules. Normally, an NFS client will never need to update the time:
> >RPC calls like WRITE, READ and SETATTR will automatically do it for us
> >whenever necessary.
> >  
> >
> 
> Let me restate this a third time in another way. What I suggest is a 
> system call, NOT NAMED CLOSE, which does a close and touch. This was all 
> blue sky discussion, new system calls are as valid as nanosecond 
> resolution and syncronization between servers. Since this is a new call 
> it is not specified by POSIX.
> 
> And Linus has already suggested that he would accept something similar, 
> when I proposed something like "noatime" mounts, which only updated 
> atime and mtime on open and close, to keep metadata relevant but not 
> have the overhead of constant updates.
> 
> Actually, now that I have more free time I may revisit that idea.

Linus might accept it, but I won't. It is totally unnecessary.

Cheers,
  Trond

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux