* [Lustre-devel] flash cache page
[not found] ` <1201135464.14768.13.camel@linux.site>
@ 2008-01-24 9:08 ` Peter J Braam
0 siblings, 0 replies; only message in thread
From: Peter J Braam @ 2008-01-24 9:08 UTC (permalink / raw)
To: lustre-devel
>> 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).
>>
>>
>
>
If a client writes a full page, the page should not first be read by the
flash cache. Almost too obvious perhaps.
- Peter -
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2008-01-24 9:08 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <478E29FF.2050306@sun.com>
[not found] ` <478E52AE.4060801@sun.com>
[not found] ` <1200609618.30173.3.camel@linux.site>
[not found] ` <47968E73.9020401@sun.com>
[not found] ` <1201135464.14768.13.camel@linux.site>
2008-01-24 9:08 ` [Lustre-devel] flash cache page Peter J Braam
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.