Subject: B_ORDERED and bowrite()
To: None <>
From: Mycroft <>
List: tech-kern
Date: 01/24/2000 00:21:56
There seem to me to be some unresolved issues with this code...

1) Why is the bq_barrier stuff in the `general' BUFQ_*() macros?
   Drivers that aren't doing ordering, or are doing strict FIFO
   ordering, don't need this at all, and those that are using
   disksort_*() could just as well do the bq_barrier manipulation
   there -- there's no point in slowing down other code.

2) More importantly, in its current form, bowrite() is not actually
   useful for the file system code.  Although it does return control
   to the user process earlier than bwrite(), the use of B_ORDERED
   causes a strict linearization of the I/O chain, and will make
   performance much worse for other processes, whereas the existing
   algorithm insures that the user doing the synchronous I/O pays the
   time penalty.

3) Truly asynchronous writes with dependencies, a la SOFTDEP, give a
   single process much better performance benefits than any use of
   bowrite() could.

In short, I don't see how bowrite() is useful, and I think it should
be removed.