Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: Linux 2.6.29 | Date | Wed, 25 Mar 2009 16:19:50 +0100 |
| |
Theodore Tso <tytso@mit.edu> wrote:
> OK, so there are a couple of solutions to this problem. One is to use > ext4 and delayed allocation. This solves the problem by simply not > allocating the blocks in the first place, so we don't have to force > them out to solve the security problem that data=ordered was trying to > solve. Simply mounting an ext3 filesystem using ext4, without making > any change to the filesystem format, should solve the problem.
[...]
> However, these days, nearly all Linux boxes are single user machines, > so the security concern is much less of a problem. So maybe the best > solution for now is to make data=writeback the default. This solves > the problem too. The only problem with this is that there are a lot > of sloppy application writers out there, and they've gotten lazy about > using fsync() where it's necessary;
The problem is not having accidential data loss because the inode /happened/ to be written before the data, but having /guaranteed/ data loss in a 60-seconds-window. This is about as acceptable as having a filesystem replace _any_ data with "deadbeef" on each crash unless fsync was called.
Besides that: If the problem is due to crappy VM writeout (is it?), reducing security to DOS level is not the answer. You'd want your fs to be usable on servers, wouldn't you?
| |