[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 Gwe, 2004-09-03 at 14:54, Bartlomiej Zolnierkiewicz wrote:
    > 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.

    Thinking about it from the drive side. If the drive wcache is off then
    you have barrier semantics anyway.

    So the logic is something like

    has-flush cache-on barrier semantics
    no-flush cache-on random semantics
    no-flush cache-off barrier semantics
    (the barrier itself is a nop)

    > > + /* 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...

    Agreed. Unfortunately a lot of users are getting burned by journalling
    fs's and IDE write caching. As the caches get bigger the risk gets
    bigger. SCSI turns it off (and prints a message) so I'd rather see the
    write_cache() changed to something like "write_cache_verbose()" and the
    printk done than the issue ignored for longer.


    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.021 / U:88.628 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site