From: Alex Kulyavtsev <aik@fnal.gov>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] HSM arch wiki
Date: Tue, 25 Nov 2008 10:59:10 -0600 [thread overview]
Message-ID: <492C2EDE.70507@fnal.gov> (raw)
In-Reply-To: <48FD0F98.9040300@sun.com>
Few questions :
- For large existing archive of tapes (~10,000,000 files) it is
desirable to import file metadata to lustre fs without actually copying
files on disk.
Import shall be done in reasonable time (hours rather than month) or online.
- to provide bandwidth to tape it is desirable to have multiple migrator
nodes connected to HSM. What element of proposed design distributes
copy-out processes across migrator nodes to provide scalability ? Is it
functionality of HSM specific copy tool or does lustre agent provide it ?
- a "smart" HSM system can reorder requests to optimize tape access. It
is common to have 2000 requests pending in queue with tens or hundreds
IO transfers actually served. Current limit of pending requests is about
30,000. We found implementing of pending requests as processes (one
copy-out tool process per request waiting for IO) is resource consuming
and is not scalable. What is the way to serve ~100,000 request waiting
for transfer ?
- how to prestage files ? Send asynchronous request for copy-in file
from tape without blocking on wait. It is needed to stage large data
sets for future processing. Prestaging "file sets" is desirable.
- what proposed scanario to handle OST down ? Suppose file is present on
one of OSTs and it went down (striping is one). My understanding is
client will wait when OST will come back (case[1]) and file will not be
staged from tape automatically. IF file is not present on any OST, it
will be staged immediately (case[2]). Is possible to stage file
automatically (case[1]) to another OST and mark a copy on old OST for
removal ?
We discussed some of these questions with Peter, he suggested to ask on
devel list.
Best regards, Alex.
Nathaniel Rutman wrote:
> High-level architecture page for the Lustre HSM project
> http://arch.lustre.org/index.php?title=HSM_Migration
>
>
> HSM core team - this is intended to be sufficient to write a full
> HLD/DLD from. What is it missing?
> _______________________________________________
> 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-11-25 16:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 22:37 [Lustre-devel] "Simple" HSM straw man Nathaniel Rutman
2008-10-13 16:39 ` Aurelien Degremont
2008-10-14 19:41 ` Nathaniel Rutman
2008-10-15 21:52 ` Nathaniel Rutman
2008-10-16 14:09 ` Aurelien Degremont
2008-10-16 21:56 ` Eric Barton
2008-10-17 9:47 ` Aurelien Degremont
2008-10-17 10:10 ` Eric Barton
2008-10-17 13:54 ` Peter Braam
2008-10-20 23:09 ` [Lustre-devel] HSM arch wiki Nathaniel Rutman
2008-10-21 13:21 ` Aurelien Degremont
2008-11-25 16:59 ` Alex Kulyavtsev [this message]
2008-11-26 16:29 ` Nathaniel Rutman
2008-11-27 19:05 ` Andreas Dilger
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=492C2EDE.70507@fnal.gov \
--to=aik@fnal.gov \
--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.