Re: [PATCH 1/7] block: Add block_flush_device()

[Ric Wheeler <rwheeler@redhat.com>]

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.

Of course I realize that.

Most of the SSD devices, including ones that don't speak normal S-ATA/SCSI/etc, 
they have a write cache and will combine and re-order IO's.

Some of them have non-volatile write caches and those don't need barriers 
(flush, fua, what ever) because of batteries, capacitors or other magic hardware 
people came up with.

For the ones that do have a volatile write cache and can reorder IO's, 
transactions will still need the ordering primitives to survive a power failure 
reliably.

If you don't need or want to pay the price of ordering, you can today easily 
disable this by mounting without barriers.

As Mark pointed out, most S-ATA/SAS drives will flush the write cache when they 
see a bus reset so even without barriers, the cache will be preserved (or 
flushed) after a reboot or panic.  Power outages are the problem 
barriers/flushes are meant to help with.

> 
> Your filesystem doesn't know. It damn well not even _try_ to know, because 
> it isn't the low-level driver.
> 
> The low-level driver - which you don't have a friggin clue about - may say 
> that it doesn't support barrier IO for any random reason that has 
> absolutely _nothing_ to do with any write caches or anything else. Maybe 
> the device has the same ordering semantics as an Intel CPU has: writes are 
> always seen in order on the disk, and reads are always speculated but will 
> snoop in write buffers, and ther is no way to not do that.
> 
> See? EOPNOTSUPP means just that - it means that the driver doesn't support 
> the notion of ordered IO. But that does not necessarily mean that the 
> writes aren't always in order. It may well just mean that the drive is a 
> thin shimmy layer over something else (for example, just a user level 
> pipe), and the driver has NO IDEA what the end result is, and the protocol 
> is simplistic and is just 'read' and 'write' and absolutely nothing else.
> 
> But you seem to NOT UNDERSTAND THIS.
> 
> I'm not interested in your inane drivel. Let's just say that your lack of 
> understanding just means that your input is irrelevant, and leave it at 
> that. Ok? Until you can see the bigger picture, just don't bother.
> 
> 			Linus


If the low level device returns EOPNOTSUPP on a barrier op, that is fine. 
Running a transactional file system on that storage might or might not be a good 
idea, but at least we can log that and move on.

I agree with Chris that what happens when the device does not support the 
primitives is not the core issue.

The question is really what we do when you have a storage device in your box 
with a volatile write cache that does support flush or fua or similar. Using 
barriers & ordered transactions for these types of devices will give you a more 
reliable file system - less fsck time needed and better data integrity support 
for the (few?) applications that use fsync properly.


Ric