[Lustre-devel] [RFC] two ideas for Meta Data Write Back Cache
Alexander Zarochentsev
Alexander.Zarochentsev at Sun.COM
Sun Apr 5 13:50:27 PDT 2009
Hello,
There are ideas about WBC client MD stack, WBC protocol and changes
needed at server side. They are Global OSD and another idea (let's name
it CMD3+) explained in the WBC HLD outline draft.
Brief descriptions of the ideas:
GOSD:
a portable component (called MDS in Alex's presentation) transates MD
operations into OSD operations (updates).
MDS may be at client side (WBC-client), proxy server or MD server.
The MDS component is very similar to current MDD (Local MD server) layer
in CMD3 server stack. I.e. it works like a local MD server, but the OSD
layer below is not local, it is GOSD.
It is simple as the local MD server and simplifies MD server stack a
lot. Current MD stack processes MD operations at any level of MDT, CMM
and MDD. First two levels should understand what is CMD and MDD layer
should understand that some MD operations can be partial. It sounds
like a unneeded complication. With GOSD those layers will be replaced
by only one as simple as MDD layer! (however LDLM locking should be
added).
CMD3+:
The component running on WBC client is based on MDT excluding transport
things. Code reuse is possible.
The WBC protocol logically is the current MD protocol with the partial
MD operations (object create w/o name, for example). Partial operations
are already used between MD servers for distributed MD operations. MD
operations will be packed into batches.
Both ideas (GOSD and CMD3+) assume a cache manager at WBC client to do
caching & redo-logging of operations.
I think CMD3+ has minimum impact to current Lustre-2.x design. It is
closer to the original goal of just implementation of WBC feature. But
the GOSD is an attractive idea and may be potentially better.
With GOSD I am worrying about making Lustre 2.x unstable for some period
of time. It would be good to think about a plan of incremental
integration of new stack into existing code.
It is a request for comments and new ideas because design mistakes would
be too costly.
Thanks,
--
Alexander "Zam" Zarochentsev
Staff Engineer
Lustre Group, Sun Microsystems
More information about the lustre-devel
mailing list