[Drbd-dev] [PATCH] Supporting barriers in DRBD, part 1
Graham, Simon
Simon.Graham at stratus.com
Sun Nov 25 21:30:42 CET 2007
Thanks for the comments Lars,
To answer questions/comments:
> since you say "part 1", what will the next part be?
> defer "_req_is_done" until the corresponding barrier ack,
> even for protocol C?
>
Well, Part 2 will be integrating the TL into recovery when we lose
contact with the secondary - not sure I want to add this feature as
well.
>
> or, preferably, we finally allocate local and remote error flag
> members in struct drbd_request, and properly deal with it :)
>
> meaning we could (at least for protocol C) notice, distinguish,
> and recover from both local and remote ENOTSUPP, for a barrier
> request.
I thought about something like this but it gets (more) complicated --
what we should really do in the case where a barrier request results in
-EOPNOTSUPP from either side is return -EOPNOTSUPP to the master bio (so
that we tell the DRBD user that barriers don't work) - I don't think,
for example, that we should retry the request without the barrier bit on
behalf of our user.
As far as protocol goes - I think we need to make sure this failure is
reported in all protocols which means more protocol changes.
> > 4. Forced a meta data write when a disk is attached so that we
> > determine early on whether or not barriers are supported.
>
> remains the problem of storage area device != meta data area device.
>
Rats! I always forget that -- I guess that means we really have to
implement per-I/O checking until we know barriers are not supported on
one or both sides _and_ save a separate bit for metadata and storage
area devices in case they are different...
> > 5. Extended the tracing of BIO's to include internally
> generated
> > BIOs as well as the ones from above
>
> would you agree if we changed that to no longer use printk,
> but to netlink-broadcast to userspace,
> so you'd be able to see them with "drbdsetup events"?
>
> I did that already for some other reasons,
> so the code is basically there.
>
I think that would be fine.
> > 3. I think we can remove the #ifdef BIO_RW_XXX - certainly
they
> > are not present everywhere these macros are referenced...
>
> I'll have to check that. we still try to support even 2.6.5-something.
>
So, there are some places where you unconditionally checked
BIO_RW_BARRIER previously (I either fixed these or used bio_barrier(bio)
instead, but that shouldn't change whether or not this thing builds on
older releases.
More information about the drbd-dev
mailing list