[Drbd-dev] FLUSH/FUA documentation & code discrepancy

[NeilBrown]

On Mon, 10 Sep 2012 16:31:59 -0700 Kent Overstreet <koverstreet at google.com>
wrote:

> cc'ing Neil
> 
> On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
> > Hello, again.
> > 
> > cc'ing Kent and Vivek.  The original thread is at
> > 
> >   http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
> > 
> > On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
> > > > We can possibly work around that by introducing an additional submitter thread,
> > > > or at least our own list where we queue assembled bios until the lower
> > > > level device queue drains.
> > > > 
> > > > But we'd rather have the elevator see the FLUSH/FUA,
> > > > and treat them as at least a soft barrier/reorder boundary.
> > > > 
> > > > I may be wrong here, but all the necessary bits for this seem to be in
> > > > place already, if the information would even reach the elevator in one
> > > > way or other, and not be completely stripped away early.
> > > > 
> > > > What would you rather see, the elevator recognizing reorder boundaries?
> > > > Or additional higher level queueing and extra thread/work queue/whatever?
> > > > 
> > > > Both are fine with me, I'm just asking for an opinion.
> > > 
> > > First of all, using FLUSH/FUA for such purpose is an error-prone
> > > abuse.  You're trying to exploit an implementation detail which may
> > > change at any time.  I think what you want is to be able to specify
> > > REQ_SOFTBARRIER on bio submission, which shouldn't be too hard but I'm
> > > still lost why this is necessary.  Can you please explain it a bit
> > > more?
> > 
> > The problem with exposing REQ_SOFTBARRIER at bio submission is that it
> > would require block layer not to reorder bios while passing through
> > stacked adrivers until it reaches a rq-based driver.  I *suspect* this
> > has been true until now but Kent's pending patch to fix possible
> > deadlock issue breaks that.
> 
> Yeah, you might be right about that. I think Neil Brown would know
> better than I if this ordering was ever explicitly broken.

While don't deliberately re-order bios just for the fun of it, there is no
real effort to keep the bios "in order" (assuming that even means something
in a multi-processor environment).  The old barrier code did impose ordering
but thankfully we don't have that any more.

RAID5 can certainly re-order write bios as it tries to assemble complete
stripes.  RAID1/4/5/6/10 can certainly re-order things if there is an error
that needs to be handled.

The only way to ensure one request completes before another is to not submit
the other until the one has completed.

NeilBrown


> 
> But I don't think anything else is relying on that kind of ordering any
> more.
> 
> >   http://thread.gmane.org/gmane.linux.kernel.bcache.devel/1017/focus=1356250
> > 
> > As for what the resolution should be, urgh... I don't know. :(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-dev/attachments/20120911/b8fe570e/attachment.pgp>