[Lustre-devel] Lustre HSM HLD draft

[Nathaniel Rutman <Nathan.Rutman@Sun.COM>]

Ricardo M. Correia wrote:
>
> On Seg, 2008-02-11 at 14:39 -0700, Andreas Dilger wrote:
>> The problem with ctime (on Linux as well) is that it is possible for the
>> system clock to go backward, whether due to ntp, or because the hardware
>> clock is incorrect/reset, so it cannot be depended upon to be monotonically
>> increasing for the life of the lustre filesystem.
>>     
>
> Ok. In that case, we could either add a new 64-bit version field to 
> the dnode (or znode) similar to the one in ldiskfs, or we could look 
> at the birth time (txg nr) of all the block pointers in the dnode.
> Using txg numbers might not be very useful if an object is migrated 
> from one storage device to another, but I have not read the HSM HLD so 
> I'm not sure if this is a problem or not.
I'm missing the point of this discussion.  Clearly we shouldn't/can't 
use ctime/mtime for anything internal to Lustre; that is what object 
versions are all about.  Why are we talking about adding new fields or 
anything else?