Messages in this thread | | | Subject | Re: [PATCH 1/7] block: Add block_flush_device() | From | Chris Mason <> | Date | Tue, 31 Mar 2009 11:22:56 -0400 |
| |
On Tue, 2009-03-31 at 07:55 -0700, Linus Torvalds wrote: > > On Tue, 31 Mar 2009, Ric Wheeler wrote: > > > > Now you are just being silly. The drive and the write cache - without barriers > > or similar tagged operations - will almost certainly reorder all of the IO's > > internally. > > You do realize that the "drive" may not be a drive at all? > > But apparently you don't. You really seem to see just your own case, and > have blinders on for everything else. > > That "drive" may be some virtualized device. It may be some super-fancy > memory mapped and largely undocumented random flash thing. It might be a > network block device, it may be somebody's IO trace dummy layer, it may be > anything at all. >
The part that we seem to be skipping over in talking about EOPNOTSUPP is not what do we do when a barrier isn't supported (print a warning and move on), it's what do we do when a barrier works. I very much agree that EOPNOTSUPP tells us almost nothing.
The idea behind the original implementation was that when barriers did work, we could make some assumptions about how IO would be ordered around the barrier, and those assumptions would let us optimize things for the lying cheating cache enabled storage that we all know and love.
It turns out 6 years later that very few people are interested in those optimizations, and we're probably better off skipping them in favor of reducing the complexity of the code involved.
Jens has a little burial site all prepped for pdflush in his yard, dumping EOPNOTSUPP in there too wouldn't be a bad thing.
-chris
| |