lkml.org 
[lkml]   [2009]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/7] block: Add block_flush_device()


    On Mon, 30 Mar 2009, Jeff Garzik wrote:
    >
    > Indeed -- if the drive tells us it failed the cache flush, it seems
    > self-evident that we should be passing that failure back to userspace where
    > possible.

    That's not what EOPNOTSUPP means!

    EOPNOTSUPP doesn't mean "the cache flush failed". It just means "I don't
    support cache flushing".

    No failure anywhere. See?

    Maybe the operation isn't supported becasue there are no caches? Who the
    hell knows? Nobody. The layer just said "I don't support this". For
    example, maybe it just cannot translate the "flush cache" op into its own
    command set, because the thing doesn't _do_ anything like that.

    For a concrete example, look at the "loop" driver. It literally returns
    EOPNOTSUPP if the filesystem doesn't have a "fsync()" thing. Ok, so it
    can't do serialization - does that mean that the caller should fail
    entirely? No. But it means that the caller cannot serialize, so now the
    caller has two choices:

    - not work at all

    - ignore it, and assume that a device without serialization is serialized
    enough as-is.

    Those are the two only choices. The caller knows that it can't flush. What
    would you _suggest_ it do? Just stop, and do nothing at all? I rally don't
    think that's a useful or valid approach.

    And notice - at NO TIME did anythign actually fail. It's just that the
    particular protocol didn't support that empty flush op.

    (Also note that block/blk-barrier.c really does an empty barrier command.
    If we were to be talking about a real IO with a real payload and the
    "barrier" bit set, that would be different. But we really aren't.)


    Linus


    \
     
     \ /
      Last update: 2009-03-30 22:17    [W:4.025 / U:0.524 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site