[lkml]   [2004]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH: fix the barrier IDE detection logic

    On Tuesday 31 August 2004 18:50, Alan Cox wrote:
    > This fixes the logic so we always check for the cache. It also defaults
    > to safer behaviour for the non cache flush case now we have the right bits
    > in the right places. I've also played a bit with timings - the worst case
    > timings I can get for the flush are about 7 seconds (which I'd expect
    > as the engineering worst cases will include retries)
    > Probably what should happen is that the barrier logic is enabled providing
    > the wcache is disabled. I've not meddled with this as I don't know what
    > the intended semantics and rules are for disabling barrier on a live disk
    > (eg when a user uses hdparm to turn on the write cache). In the current
    > code as with Jens original that cannot occur.

    I think that logic is reversed here, I guess it should be: enable barrier
    if user enables wcache and disable it if user disables wcache.

    > I've also fixed the new printk's as per a private request from Matt Domsch.

    Patch looks fine except:

    > + /* Now we have barrier awareness we can be properly conservative
    > + by default with other drives. We turn off write caching when
    > + barrier is not available. Users can adjust this at runtime if

    This is not true because there is a check for flush cache in write_cache().

    I agree that disabling write cache by default is a good thing but user
    should be informed about this fact (ideally there also should be easily
    available FAQ somewhere) otherwise we will get a lot of bogus bugreports
    about decreased performance...

    > + they need unsafe but fast filesystems. This will reduce the
    > + performance of non cache flush supporting disks but it means
    > + you get the data order guarantees the journalling fs's require */
    > +
    > + write_cache(drive, barrier);

    I'll drop this chunk and resend to Linus.


    PS: please also cc: linux-ide on all ATA related stuff
    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 14:05    [W:0.022 / U:74.828 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site