[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