Re: PATCH: fix the barrier IDE detection logic

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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.

Alan