From: Peter Braam <Peter.Braam@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Wide area use of Lustre and client caches
Date: Thu, 08 May 2008 22:55:56 -0600 [thread overview]
Message-ID: <C449357C.4160%peter.braam@sun.com> (raw)
During the LUG I was approached by a customer who wants to use a Lustre file
system at the far end of a WAN link. Since the situation may be of general
interest, I thought I would post a short report of the discussion here.
His use pattern was interesting ? a number of Windows clients must be
browsing files stored in Lustre in this remote location. It was expected
that the files would be fairly large, would be viewed by multiple clients,
and that few or no modifications would be made.
After some discussion we proposed a solution that involved a deployment as
follows:
1. A single Lustre client with lots of RAM. The settings on the client
would be (1) that the memory available for caching by lustre is large (2)
that the number of locks that can be held by this client is fairly large (3)
that this client uses the ?open cache?.
2. A samba server on this Lustre client.
With the settings above, we can expect that many of the files can be cached
in the Lustre client, hence after the initial read, I/O would be local in
the remote site. With the open file cache enabled, even the open and close
traffic will not go to the servers, but can be handled by the client. We
think that this will lead to a very good solution, that can work today.
A refinement is possible, that requires some development. There is a
feature in the Linux kernel to use a disk partition as a cache for a file
system ? it is called cachefs. This requires a few hooks in Lustre to
store chunks of files that are transferred to the client into this cache,
and cache invalidation calls to remove them. It allows us to achieve the
same performance as with the solution above, except that the disk will be a
bit slower than memory, but it can also be much larger.
We are eagerly awaiting the results of testing this configuration!
- peter -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20080508/480a7bd2/attachment.htm>
next reply other threads:[~2008-05-09 4:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-09 4:55 Peter Braam [this message]
2008-05-09 14:25 ` [Lustre-devel] Wide area use of Lustre and client caches Brian J. Murrell
2008-05-09 15:08 ` Peter Braam
2008-05-09 17:08 ` Brian J. Murrell
2008-05-09 18:17 ` Nikita Danilov
2008-05-09 23:01 ` Andreas Dilger
[not found] <372618435.977041214909597153.JavaMail.root@dahlback.prod.local>
2008-07-01 11:03 ` Daire Byrne
2008-07-01 14:56 ` 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=C449357C.4160%peter.braam@sun.com \
--to=peter.braam@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.