Subject: B_ORDERED and bowrite()
To: None <tech-kern@netbsd.org>
From: Mycroft <root@ihack.net>
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.