From: Andreas Dilger <adilger@sun.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Lustre HSM HLD draft
Date: Mon, 11 Feb 2008 11:18:50 -0700 [thread overview]
Message-ID: <20080211181850.GA6552@webber.adilger.int> (raw)
In-Reply-To: <47AC7B75.30603@cea.fr>
On Feb 08, 2008 16:55 +0100, Aurelien Degremont wrote:
> But the touch could be problematic. Lustre gurus, is there another time
> field we could use instead ? Should we add a
> "last-modification-field-which-ignore-touch" ? Is this really a problem
> is we use display a "touched" time ? In this case, we display what the
> user set on the file, we suppose he did it in purpose.
There was work done in ext4/ldiskfs to add a 64-bit "version" field to
the on-disk inode, for use by lustre and NFSv4. In the ldiskfs case
Lustre was free to store any information in this field it wanted. The
planned use for this field is for "version based recovery" and it has
the semantic that it is an increasing (though not necessarily sequential)
version number that tracks any change to the file. This is stored in
each inode on the MDT and each object on the OSTs.
In ZFS I believe there is also a "last modified transaction group" (txg)
number stored with each dnode that could be used in a similar manner.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2008-02-11 18:18 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 [this message]
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
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=20080211181850.GA6552@webber.adilger.int \
--to=adilger@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.