[Unionfs] Re: timestamp/mtime related bugs, probable fix

Erez Zadok ezk at cs.sunysb.edu
Tue Dec 18 08:36:20 EST 2007


In message <fk87i9$4j3$1 at ger.gmane.org>, pascal at pabr.org writes:
> This patch looks promising, thanks, I will be testing it too.
> 
> Erez Zadok wrote:
> > +	 (upper inode time being the max of all lower ones).
> 
> By the way, I find this policy a little odd.
> 
> For regular files, it looks like if one lower branch has the
> highest mtime and another branch has the highest ctime,
> then the timestamps of the upper file will not match those
> of any individual lower file (which would be disturbing).
> Is that correct ?

We don't mix ctime/atime/mtime: it's the max of each individual type.  So
atime, ctime,and mtime change individually.

For regular files it's a little different b/c the invariant for
non-directories is that only one lower object is looked up at the time (so
the "max" becomes a straight copy).

> Besides, in order to preserve the invariant, the implementation
> seems to assume that lower timestamps can only increase over
> time (which is not true).

If one uses utimes(2) to change the inode time absolutely, we just take
those times as is in ->setattr.

>  Wouldn't it be safer to reset the
> timestamps at the beginning of unionfs_copy_attr_times() too ?

Hmmm, possible, I'll take a look.  Thanks.

> Pascal

Erez.


More information about the unionfs mailing list