[Lustre-devel] [Fwd: flash cache page]

[Peter J Braam <Peter.Braam@Sun.COM>]

-------- Original Message --------
Subject: 	flash cache page
Date: 	Wed, 23 Jan 2008 08:46:43 +0800
From: 	Peter J Braam <Peter.Braam@Sun.COM>
To: 	Vladimir V. Saveliev <Vladimir.Saveliev@Sun.COM>, 
lustre-devel at lustre.org
References: 	<478E29FF.2050306@sun.com> <478E52AE.4060801@sun.com> 
<1200609618.30173.3.camel@linux.site>



<div class="moz-text-flowed" style="font-family: -moz-fixed">Vladimir -

Here are some suggestions to improve the requirements & architecture for 
the flash cache.


1 Use case table.

i. we decided on an implementation constraint to store both file layouts 
as attributes of objects in a redirection layer in the client.  These 
layouts would be obtained from the MDS cluster, see (iv)

ii. We decided that locks would be taken in a hierarchical  manner -  
the flash cache would run a LDLM and locks would be taken there.

iii. Correctness would be handled automatically through the 
hierarchy.    However, to avoid a lot of reading "write only locks" used 
when entire pages are written are probably desirable (i.e. the caching 
infrastructure on the flash OST's is different from a Lustre client).

iv How EA2 is acquired needs more detail.


v Power loss needs a discussion - after restarting the cache an iterator 
is needed to push the data out.

2. QAS scenarios - these do need to be written.  These sketchy notes are 
not getting us much further.

3. Implementation details (many are not)

i.  What was the specific use of the "whole file" bit for MDT locks? We 
had several uses that showed its value - we should write them down 
before we forget.

ii. Please change all of these into detailed well written sentences - 
most are quality attribute scenarios and should be documented with a 
small table for each.

Peter
</div>