[Lustre-devel] Lustre HSM HLD draft
Aurelien Degremont
aurelien.degremont at cea.fr
Tue Feb 12 07:41:41 PST 2008
It is important to note that all comparisons and modifications are done
at Lustre-object level: OST stripe object or MDT file object, each of
those objects already has a version field, in the FID.
This is the version inside the FID that we will use for all treatments.
All purges are always requested for a specific FID.
The mtime is stored only for information, for the users. It is simpler
to display to the user:
user$ list_hsm_copies ./foo
Date
============
Feb 2 2006
Jun 18 2007
Jun 19 2007
than:
user$ list_hsm_copies ./foo
Version
============
0x0012356
0x001a250
0x001a011
If the user "touched" the file sometime, he knew what he has done. Just
the output will be different, but internaly, we manipulate Lustre FID
and so we don't care of mtime.
So the "version" in the backend is not a problem. We do not rely on the
ldiskfs/zfs inode versioning.
Aurelien Degremont
Rick Matthews a écrit :
> I'm probably responsible for opening this can of worms. I inferred from
> the HSM HLD that
> mtime was proposed to be used for state change, or version of the
> file/object. As the discussion
> bears out, mtime for this purpose would be a bad idea. A reliable way of
> detecting change is
> needed, and if it already exists withing Lustre, great!.
>
> What I think is far more significant is the involvement of the community
> on issues
> such as this. More folks examining (and critiquing) the details, the
> better.
> Nice to see such an active community.
> --
>
> Nathaniel Rutman wrote:
>> 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?
>>
>>
>
>
--
Aurelien Degremont
CEA
More information about the lustre-devel
mailing list