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...
ric
-
: 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
