[OpenAFS-devel] Re: [OpenAFS] file timestamp difference
Derrick Brashear
shadow@gmail.com
Wed, 24 Oct 2007 16:02:54 -0400
------=_Part_6507_24952463.1193256174428
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 10/24/07, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
>
> Jim Rees wrote:
> > I don't think that's the right fix. The linux code should just use the
> > timespec returned by the vnodeop, which includes the data version in the
> > nsec field. Otherwise the file could change but still have the same
> mtime.
> > I'm pretty sure that's what most of the other clients do.
>
> Jim:
>
> If you look at all of the Linux support. It appears to be the case that
> the code is written with the assumption that time structures in the
> vattr and the iattr do not have to be the same.
>
> In the !AFS_LINUX26_ENV case the tv_usec field is being set to 0 in the
> iattr2vattr() transition. What I don't know is whether or not this is
> being down because there is no tv_usec field in the iattr or whether it
> is because the value of the tv_usec field of the iattr is expected to be
> invalid.
>
> The same problem might hold true for the inode and vattr case.
>
> The question at the moment is what to do for 1.4.5. Leaving the code as
> it currently exists is clearly wrong.
But safe except when two files have the same creation second, ...
The safest things to do are
> either to assign the entire structure as you have proposed or setting
> the tv_nsec field to 0 since AFS is not going to store nanoseconds anyway.
>
>
------=_Part_6507_24952463.1193256174428
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div><span class="gmail_quote">On 10/24/07, <b class="gmail_sendername">Jeffrey Altman</b> <<a href="mailto:jaltman@secure-endpoints.com">jaltman@secure-endpoints.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jim Rees wrote:<br>> I don't think that's the right fix. The linux code should just use the<br>> timespec returned by the vnodeop, which includes the data version in the<br>> nsec field. Otherwise the file could change but still have the same mtime.
<br>> I'm pretty sure that's what most of the other clients do.<br><br>Jim:<br><br>If you look at all of the Linux support. It appears to be the case that<br>the code is written with the assumption that time structures in the
<br>vattr and the iattr do not have to be the same.<br><br>In the !AFS_LINUX26_ENV case the tv_usec field is being set to 0 in the<br>iattr2vattr() transition. What I don't know is whether or not this is<br>being down because there is no tv_usec field in the iattr or whether it
<br>is because the value of the tv_usec field of the iattr is expected to be<br>invalid.<br><br>The same problem might hold true for the inode and vattr case.<br><br>The question at the moment is what to do for 1.4.5. Leaving the code as
<br>it currently exists is clearly wrong. </blockquote><div><br><br>But safe except when two files have the same creation second, ...<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The safest things to do are<br>either to assign the entire structure as you have proposed or setting<br>the tv_nsec field to 0 since AFS is not going to store nanoseconds anyway.<br><br></blockquote></div><br>
------=_Part_6507_24952463.1193256174428--