[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.031 / U:0.016 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site