lkml.org 
[lkml]   [2004]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: True fsync() in Linux (on IDE)
    Jens Axboe schrieb am 2004-03-18:

    > > All these ATA fsync() vs. write cache issues have been open for much too
    > > long - no reproaches, but it's a pity we haven't been able to have data
    > > consistency for data bases and fast bulk writes (that need the write
    > > cache without TCQ) in the same drive for so long. I have seen Linux
    > > introduce TCQ for PATA early in 2.5, then drop it again. Similarly,
    > > FreeBSD ventured into TCQ for ATA but appears to have dropped it again
    > > as well.
    >
    > That's because PATA TCQ sucks :-)

    True. Few drives support it, and many of these you would not want to run
    in production...

    > > May I ask that the information whether a particular driver (file system,
    > > hardware) supports write barriers be exposed in a standard way, for
    > > instance in the Kconfig help lines?
    >
    > Since reiser is the first implementation of it, it gets to chose how
    > this works. Currently that's done by giving -o barrier=flush (=ordered
    > used to exist as well, it will probably return - right now we just
    > played with IDE).

    This looks as though this was not the default and required the user to
    know what he's doing. Would it be possible to choose a sane default
    (like flush for ATA or ordered for SCSI when the underlying driver
    supports ordered tags) and leave the user just the chance to override
    this?

    > Only PATA core needs to support it, not the chipset drivers. md and dm

    Hum, I know the older Promise chips were blacklisted for PATA TCQ in
    FreeBSD. Might "ordered" cause situations where similar things happen to
    Linux? How about SCSI/libata? Is the situation the same there?

    > aren't a difficult to implement now that unplug/congestion already
    > iterates the device list and I added a blkdev_issue_flush() command.

    So this would - for SCSI - be an sd issue rather than a driver issue as
    well?

    --
    Matthias Andree

    Encrypt your mail: my GnuPG key ID is 0x052E7D95
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.022 / U:4.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site