On Fri, Mar 20, 2009 at 11:26 AM, Samuel J. Greear <s...@evilcode.net> wrote: > Better might be to work toward fixing the applications. ee has bitten > me a number of times on crash after editing a config file. > > One option for ffs might be to have it optimistically flush when load > is low; but to be honest I think fixing the applications is much more > important.
I agree, but if it is practical to implement behaviour similar to ext3's "data=ordered" for UFS soft updates, then that is certainly a good measure. The issue with fixing applications is that a user has no idea which ones are fixed without reading the code themselves. It's not bad to have a system-wide hack that's almost as good as a per-application solution. Then when all applications that want the more robust semantics fix their code, people can more confidently turn off the heavyweight ordering mode. The problem many people have with ext3 fsync arises because they have huge partitions that store everything, and therefore have to wait for potentially everything when doing an fsync even on a tiny config file. I for one run dozens of very small (per purpose) partitions on LVM, so fsync, data=ordered and even the occasional data=journal do not really impact my performance, because at most I'm only syncing the other changes to that same partition. I am also much more resistant to write cache crash when I do run with write cache. This is very similar to the BSD philosophy of having separate partitions where possible, though in LVM the limit is much higher. This has its benefits besides just minimising the cost of poorly written applications, but it does take far more management effort than one big partition. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia
