[lkml]   [2001]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] 2.4.10 improved reiserfs a lot, but could still be better
    On Mon, 24 Sep 2001, Nicholas Knight wrote:

    > Would you like to read the rest of my message please? Cheap UPS's can
    > provide protection against power failures. If your data is that
    > valuble, you can afford a cheap UPS to give you 5 minutes to shut down.

    No UPS can protect you from system crashes. The problem is, with the
    drive cache on, the drive will acknowledge having written the data early
    and reorder its writes, but who makes guarantees it can write its whole
    2 MB to disk should the power fail? No-one. ATA6 drafts have a NOTE that
    says, the FLUSH CACHE command may take longer than 30 s to complete.

    Journalling File systems don't get you anywhere if the drive reorders
    its blocks before the write (I presume, most will do), they may instead
    turn the whole partition to junk without notice, because any assumptions
    as to the on-disk structure don't hold.

    > > Linear writing as dd mostly does is BTW something which should never
    > > be affected by write caches.
    > Explain the numbers then.

    I can't, any explanation right now would be conjecture. I can reproduce
    the numbers on my IBM DTLA-307045 (Promise) and on my Western Digital
    CAC420400D (VIA KT133, the disk looks like an IBM DJNA-352030 OEM,

    However, would you care to elaborate how switching OFF the cache should
    harm data, provided you don't need to cater for power outages (UPS
    attached, e. g.)?


    " -W Disable/enable the IDE drive's write-caching fea­
    ture (usually OFF by default)."

    > I followed *YOUR* instructions for disabling write caching.

    No-one doubts you did. I said it's weird that the drive write cache has
    an impact on dd figures. It may be worthwhile to investigate this, but
    again, any try to explain this would be a guess.

    It may be an implementation problem in our IBM drives which ship with
    their write caches enabled, someone please do this test on current
    Fujitsu, Maxtor or Seagate IDE drives or with different controllers.

    It would suffice if the kernel could flush the drive's buffers on
    fsync() and other synchronous operations, but a flush command has only
    recently appeared in the ATA standards, as it seems. I only have drafts
    here, ATA 3 draft rev. 6 did not offer any command to flush the cache,
    ATA 6 draft makes it mandatory for all devices that do offer a PACKET
    interface. Not sure about the actual ATA 3, 4, or 5 standards.

    Why are disk drives slower with their caches disabled on LINEAR writes?

    Matthias Andree

    "Those who give up essential liberties for temporary safety deserve
    neither liberty nor safety." - Benjamin Franklin
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:03    [W:0.026 / U:59.800 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site