lkml.org 
[lkml]   [2009]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2009-04-01 03:03    [W:4.120 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site