[Lustre-devel] WBC HLD outline
Alexander Zarochentsev
Alexander.Zarochentsev at Sun.COM
Mon Apr 6 03:23:51 PDT 2009
Hello Eric,
Thanks for the review,
On 1 April 2009 12:17:17 Eric Barton wrote:
> Zam,
>
> Some notes on the WBC HLD outline
[...]
>
> 5. Is ensuring file data is delayed until file creation is
> reintegrated sufficient for correct operation? Are we not
> effectively doing create-on-write with a WBC? I'm sure there
> are more issues (e.g. orphans).
>
> Does including the OSTs in epoch recovery solve all the issues?
> If so, what are the expected bounds on client redo and server undo
> storage? Can we avoid needing server undo for data with some
> compromises? Can we exploit the DMU at all?
I think we can't avoid tagging OST object creation w/ epoch counter.
Would Lustre users complain if file writes are out-of-epochs?
So a write to existing OST object may survive loosing the context of MD
operations where the write operation was issued, object
creation/deletion may not.
The alternative is to implement undo logging for file data. It would
require support from underlaying server fs. It could be done for
ldiskfs, not sure about DMU.
There is a security problem with out-of-epochs writes and setting
file attributes (especially permissions):
chmod 400 foo; cat /etc/secret-file >> foo. Chmod/chown can be a special
case which triggers wbc flush.
> 6. The section on recovering from WBC client death seems imprecise.
> Is (a) just describing V1-4 in Nikita's original post - similarly
> (b) for V1-2, V3'-5'? Also, for (c) I think we may have discussed
> the possibility of always sending updates as the full operation +
> context to select which updates apply locally so that an operation
> can always be recovered from any of its updates.
It is only a rough schema of client eviction to list what support might
be needed in wbc protocol, like sending full MD op instead of update--
what you just mentioned. BTW, I thought Epochs HLD would cover the
detailed algorithm descriptions, no?
> Cheers,
> Eric
Thanks,
--
Alexander "Zam" Zarochentsev
Staff Engineer
Lustre Group, Sun Microsystems
More information about the lustre-devel
mailing list