Re: [RFT] major libata update

[Jens Axboe <axboe@suse.de>]

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