Comment 22 for bug 1366538

Hello! I found the original bug and proposed the original patch to the kernel SCSI guys. Here's some context:

The SCSI flush command was being treated by a zero-byte write, which means that if an error was returned, you wouldn't catch it until a subsequent write (or flush). The way writes work is that all possible bytes are written, and if something bad happens, an error bubbles out on the next write attempt. This holds true even for a zero-byte write. This means that before this bug, to guarantee durability you had to flush twice (and verify both were error-free). I'm working on a storage appliance that relies on the fact that a single flush command guarantees a write made durably to a SCSI device. I'm sure many other storage products rely on this behavior, too.

I'm not sure why certain USB drives are failing in the flush path on unmount. Since the flush bug existed for such a long time, I suspect certain drivers coded around this behavior, and now that it is correct we are seeing new bugs exposed.

Based on the simplicity and obviousness of our patch for the flush bug, it would really be ideal to diagnose this further rather than reverting.