On Thu, May 18 2006, Ric Wheeler wrote: > > Mark Lord wrote: > >> > >>A different discussion is what we should do or log when we detect this > >>- i.e., write cache enabled and barrier ops not supported (disable > >>write cache? log a scarier message? ignore it?). Today's behavior is > >>probably what most home users want (run as fast as I can, absolute > >>data integrity over power failures not a big deal) but not the right > >>behavior for critical data (i.e., forget performance, make sure my > >>data is always safe ). > > > >Yes, 99.99% of Linux users would really complain like mad > >if the *kernel* took over the *policy* decision of disabling > >write-caching. The long-term kernel rule has always been, > >leave *policy* to user-space. > > > >Cheers > > Agreed - I think that only challenge is for us to make sure that the > messages in the upstream kernel are informative enough to let people know > what this means and some level of their exposure. > > Maybe the "enterprise" distro install programs would want to treat write > barrier like we do support for 3D video card acceleration with a good > overview & let the user configure the system as best suits their needs. I > think that it is still quite difficult to get right today for most casual > users... Yep certainly something needs to be done, it's currently far too unlikely that: a) the user even sees the barrier message from the file system, telling them that the fs turned it off and b) he/she knows the implications of such a message. This is data integrity after all, we probably should be a little more careful. -- Jens Axboe - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
