From: Nathaniel Rutman <Nathan.Rutman@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Doubly indexed tree / changelogs
Date: Mon, 22 Sep 2008 20:49:21 -0700 [thread overview]
Message-ID: <48D86741.2060101@sun.com> (raw)
In-Reply-To: <C4FCFC69.7CC2%peter.braam@sun.com>
I actually added a "previous record" pointer in each changelog entry,
but fill it in only where it is cheap -- when the metadata object is
already in the cache I record the last changelog entry there. If it's
not in the cache, I don't know where the last record associated with
that fid is. We could store the last record number with the inode (EA?),
but that would potentially be painful if we are recording e.g. file
open/closes.
Forward pointers are also problematic, in that I don't want to go back
and modify the old record every time a new one is recorded (seems like
this will make the disks very seek-y), and I think maybe we don't need
forward pointers anyhow (use case?). Anyhow, this effectively doubles
the changelog write impact. Maybe that's ok: Manoj's measurements put
the changelog overhead at only about 4% using mdsrate.
Peter Braam wrote:
> Hi Nikita, Nathan -
>
> After some pondering I have come to two conclusions.
>
> To encode filesets, we need a tree that makes two iterations fast:
>
> 1. list all filesets that contain a certain object
> 2. list all objects in a certain fileset
>
>
> Is there a doubly indexed tree for this?
>
> Secondly, to make the changelogs useful and scalable for filesets we
> will need to be able to list all changelog entries associated with a
> certain inode efficiently. I see two ways to do this ? one is an
> auxiliary directory file mapping inodes to many changelog entries, the
> second is to embed forward and backward pointers in the changelog
> entries to build a linked list rooted at the inode (using an EA in the
> inode pointing to the first and last element of the list). Both have
> some overheads. What are your thoughts?
>
> Peter
> ------------------------------------------------------------------------
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>
next prev parent reply other threads:[~2008-09-23 3:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-21 23:40 [Lustre-devel] Doubly indexed tree / changelogs Peter Braam
2008-09-22 5:52 ` Alex Zhuravlev
2008-09-22 6:58 ` Peter Braam
2008-09-22 7:05 ` Alex Zhuravlev
2008-09-22 7:13 ` Peter Braam
2008-09-22 7:26 ` Alex Zhuravlev
2008-09-23 3:49 ` Nathaniel Rutman [this message]
2008-09-23 9:20 ` Peter Braam
2008-09-23 21:46 ` Nathaniel Rutman
2008-09-23 22:48 ` Peter Braam
2008-09-23 7:38 ` Nikita Danilov
2008-09-24 2:50 ` 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=48D86741.2060101@sun.com \
--to=nathan.rutman@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.