lkml.org 
[lkml]   [2010]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
    Below is an updated version of the documentation.  It fixes several
    typos Zach Brown noticed and replaces all references to a physical
    medium with the term non-volatile storage. I haven't added any examples
    yet as I need to figure how they fit into the rest of the document.

    ---

    Explicit volatile write cache control
    =====================================

    Introduction
    ------------

    Many storage devices, especially in the consumer market, come with volatile
    write back caches. That means the devices signal I/O completion to the
    operating system before data actually has hit the non-volatile storage. This
    behavior obviously speeds up various workloads, but it means the operating
    system needs to force data out to the non-volatile storage when it performs
    a data integrity operation like fsync, sync or an unmount.

    The Linux block layer provides two simple mechanism that lets filesystems
    control the caching behavior of the storage device. These mechanisms are
    a forced cache flush, and the Force Unit Access (FUA) flag for requests.


    Explicit cache flushes
    ----------------------

    The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from
    the filesystem and will make sure the volatile cache of the storage device
    has been flushed before the actual I/O operation is started. This explicitly
    guarantees that previously completed write requests are on non-volatile
    storage before the flagged bio starts. In addition the REQ_FLUSH flag can be
    set on an otherwise empty bio structure, which causes only an explicit cache
    flush without any dependent I/O. It is recommend to use
    the blkdev_issue_flush() helper for a pure cache flush.


    Forced Unit Access
    -----------------

    The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the
    filesystem and will make sure that I/O completion for this requests is only
    signaled after the data has been commited to non-volatile storage.


    Implementation details for filesystems
    --------------------------------------

    Filesystem can simply set the REQ_FLUSH and REQ_FUA bits and do not have to
    worry if the underlying devices need any explicit cache flushing and how
    the Forced Unit Access is implemented. The REQ_FLUSH and REQ_FUA flags
    may both be set on a single bio.


    Implementation details for make_request_fn based block drivers
    --------------------------------------------------------------

    These drivers will always see the REQ_FLUSH and REQ_FUA bits as they sit
    directly below the submit_bio interface. For remapping drivers the REQ_FUA
    bits need to be propagated to underlying devices, and a global flush needs
    to be implemented for bios with the REQ_FLUSH bit set. For real device
    drivers that do not have a volatile cache the REQ_FLUSH and REQ_FUA bits
    on non-empty bios can simply be ignored, and REQ_FLUSH requests without
    data can be completed successfully without doing any work. Drivers for
    devices with volatile caches need to implement the support for these
    flags themselves without any help from the block layer.


    Implementation details for request_fn based block drivers
    --------------------------------------------------------------

    For devices that do not support volatile write caches there is no driver
    support required, the block layer completes empty REQ_FLUSH requests before
    entering the driver and strips off the REQ_FLUSH and REQ_FUA bits from
    requests that have a payload. For devices with volatile write caches the
    driver needs to tell the block layer that it supports flushing caches by
    doing:

    blk_queue_flush(sdkp->disk->queue, REQ_FLUSH);

    and handle empty REQ_FLUSH requests in its prep_fn/request_fn. Note that
    REQ_FLUSH requests with a payload are automatically turned into a sequence
    of empty REQ_FLUSH and the actual write by the block layer. For devices
    that also support the FUA bit the block layer needs to be told to pass
    through that bit using:

    blk_queue_flush(sdkp->disk->queue, REQ_FLUSH | REQ_FUA);

    and handle write requests that have the REQ_FUA bit set properly in its
    prep_fn/request_fn. If the FUA bit is not natively supported the block
    layer turns it into an empty REQ_FLUSH request after the actual write.


    \
     
     \ /
      Last update: 2010-08-23 16:09    [W:0.026 / U:93.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site