From: Rick Matthews <Richard.Matthews@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Lustre HSM HLD draft
Date: Mon, 11 Feb 2008 16:46:07 -0600 [thread overview]
Message-ID: <47B0D02F.6030803@Sun.COM> (raw)
In-Reply-To: <47B0CCFC.80102@sun.com>
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?
>
>
--
---------------------------------------------------------------------
Rick Matthews email: Rick.Matthews at sun.com
Sun Microsystems, Inc. phone:+1(651) 554-1518
1270 Eagan Industrial Road phone(internal): 54418
Suite 160 fax: +1(651) 554-1540
Eagan, MN 55121-1231 USA main: +1(651) 554-1500
---------------------------------------------------------------------
next prev parent reply other threads:[~2008-02-11 22:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 16:19 [Lustre-devel] Lustre HSM HLD draft Rick Matthews
2008-02-08 0:03 ` JC.LAFOUCRIERE at CEA.FR
2008-02-08 11:52 ` Rick Matthews
2008-02-08 15:55 ` Aurelien Degremont
2008-02-11 18:18 ` Andreas Dilger
2008-02-11 19:38 ` Peter Braam
2008-02-11 21:11 ` Ricardo M. Correia
2008-02-11 21:39 ` Andreas Dilger
2008-02-11 22:07 ` Ricardo M. Correia
2008-02-11 22:32 ` Nathaniel Rutman
2008-02-11 22:46 ` Rick Matthews [this message]
2008-02-12 15:41 ` Aurelien Degremont
2008-02-12 0:25 ` Ricardo M. Correia
-- strict thread matches above, loose matches on Subject: below --
2008-02-07 10:52 DEGREMONT Aurelien
2008-02-08 21:18 ` Nathaniel Rutman
2008-02-11 14:59 ` Aurelien Degremont
2008-02-11 20:33 ` Nathaniel Rutman
2008-02-12 3:55 ` Andreas Dilger
2008-02-12 11:04 ` Eric Barton
2008-02-12 15:25 ` Aurelien Degremont
2008-02-12 17:23 ` Andreas Dilger
2008-02-12 19:43 ` Eric Barton
2008-02-12 23:24 ` Nathaniel Rutman
2008-02-18 21:51 ` Canon, Richard Shane
2008-02-19 17:13 ` Aurelien Degremont
2008-02-25 22:44 ` Peter J Braam
2008-02-21 15:26 ` Aurelien Degremont
2008-02-25 22:38 ` Peter J Braam
2008-02-27 16:51 ` Aurelien Degremont
2008-02-29 4:30 ` Peter Braam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47B0D02F.6030803@Sun.COM \
--to=richard.matthews@sun.com \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.