[Lustre-devel] Global generic database
Canon, Richard Shane
canonrs at ornl.gov
Wed Feb 13 12:35:02 PST 2008
JC mentioned this when we were talking about the Space Manager component
in the HSM design. The Space Manager would have some type of policy
language and the policies need to be stored some where. Another use
case would be QoS policies when that starts to appear.
--Shane
-----Original Message-----
From: lustre-devel-bounces at lists.lustre.org
[mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Nathaniel
Rutman
Sent: Wednesday, February 13, 2008 1:24 PM
To: lustre-devel at lists.lustre.org; aurelien.degremont at cea.fr;
Eric.Barton at Sun.COM
Subject: [Lustre-devel] Global generic database
The design of various new features in Lustre call for global (filesystem
wide) databases, accessible from
clients or other servers:
A. pools - pool descriptions (pool #1 = OSTs 1-10,30-60), pool policies
(all .jpg files to pool #1)
B. filesets - fileset policies (log creates on fileset #1 to feed "foo")
C. HSM - (aureleien - what was the use case here?)
We've already implemented at least 2 of these:
D. Fid Location Database - (is this done?)
E. configuration parameters - stored in MGS llogs
Rather than continue 1-off implementations, I think it's time we came up
with a consistent,
global, generic database mechanism for A-C as well as other future uses.
Needs to be:
1. Fast. We need to cache database entries locally, which also means
having them under locks.
a. local caching
b. locks
2. Generic. Store any kind of data, not limited to 8k page boundaries,
etc.
3. Transactional. Power loss doesn't lead to inconsistent state.
4. Recoverable. Client changes are replayed if need be.
5. Remotely accessible, from a client or other servers.
_______________________________________________
Lustre-devel mailing list
Lustre-devel at lists.lustre.org
http://lists.lustre.org/mailman/listinfo/lustre-devel
More information about the lustre-devel
mailing list