Messages in this thread | | | Date | Wed, 01 Apr 2009 09:54:59 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 1/7] block: Add block_flush_device() |
| |
Hello,
Jens Axboe wrote: >> For example, if the drive doesn't support FUA, then you cannot do a >> serialized IO operation, but you can still mostly do a serialized op >> without any IO attached to it. > > FUA we should be able to reliably detect, it's really the cache flush > operation itself that has caused headaches in the past. The -EOPNOTSUPP > really comes from the block layer, not from the device driver. That's > mainly due to the fact that we only send down the actual barrier, if the > driver already said it supported them. If they do fail them, we probably > need to pick up the -EIO bits and pieces and pretend it didn't happen as > well. So it definitely needs more looking into, auditing, and testing. > I'll do that tomorrow.
Yeah, we need to implement some kind of fallback logic such that filesystems get errors iff the underlying device actually failed to flush. For the most part, this shouldn't be too difficult.
There is a corner case for tag ordered requests in that retrying might end up putting the barrier on the platter after writes following it. Well, the problem isn't specific to fallback tho. The root problem is that later command get issued before the previous ones are finished and SCSI ordered tag doesn't mandate failure of earlier request to abort all the following ones, so by the time block layer knows about the failure, writes after the barrier might already be on the platter. I guess we'll have to ignore that for the time being.
Thanks.
-- tejun
| |