Messages in this thread | | | Subject | Re: PATCH: fix the barrier IDE detection logic | From | Alan Cox <> | Date | Fri, 03 Sep 2004 15:05:16 +0100 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |