Lustre-devel archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nathaniel Rutman <Nathan.Rutman@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] HSM arch wiki
Date: Wed, 26 Nov 2008 08:29:56 -0800	[thread overview]
Message-ID: <492D7984.10708@sun.com> (raw)
In-Reply-To: <492C2EDE.70507@fnal.gov>

Alex Kulyavtsev wrote:
> 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.
Agreed.  Probably best done via a special ioctl that would create a stub 
file and populate the metadata.
>
> - 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 ?
Lustre agents can run on multiple Lustre clients in parallel.  
Coordinator distributes copyout jobs to different agents.
>
>
> - 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 ?
>
Coordinator decides when to request copyin/out jobs, and could throttle 
the total number of concurrent accesses.

> - 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.
Policy engine would request copyin of files before cache miss on open.  
Policy could define file sets.
>
> - 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 ?
With our V2 HSM, we will have the ability to keep more detailed layouts; 
this optimization could be part of those changes.
>
> We discussed some of these questions with Peter, he suggested to ask 
> on devel list.
We greatly appreciate it!  Please ask/suggest away.
>
> 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
>>   
>

  reply	other threads:[~2008-11-26 16:29 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
2008-11-26 16:29       ` Nathaniel Rutman [this message]
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=492D7984.10708@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox