[Drbd-dev] DRBD-8 - handling data write errors
Graham, Simon
Simon.Graham at stratus.com
Thu Jan 11 16:50:27 CET 2007
> this is not a short-term project, but
> how about this:
> introduce an additional "badblocks" bitmap -- actually, I think
> probably
> a "range-list" type of storage would be appropriate here.
>
> local read error:
> mark dirty, read full blocks remotely (which may be more than the
> application requested), write -- written ok: mark clean again.
> local write error:
> mark block (range) as bad,
> mark system "degraded"
> both blocks bad, or remote not reachable:
> pass to upper layers.
>
You are right - it's not short term! Also;
. I think it'd be necessary to write this new badblocks structure to the
on-disk
meta-data so we'd need to allocate space for it
. We'd then need to deal with the case of having no more space to record
badblocks (the
disk is pretty toasty in this case - maybe just detach).
You know, the underlying disks already include a lot of this
functionality and the more I think about it, the more convinced I am
that detaching on any error is the right thing to do --
. DRBD already (I think) correctly handles things if you re-attach
following this (it'll try
to resync the failed blocks and if that fails it would detach again).
. Although this seems like you end up doing a lot of work, these errors
are unlikely so I
think it's OK to use a large hammer.
I'm going to do some experiments with the error handler set to Detach -
will report back on results.
Simon
More information about the drbd-dev
mailing list