summaryrefslogtreecommitdiffstats
path: root/include/keys
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2013-08-17 04:06:53 +0200
committerTheodore Ts'o <tytso@mit.edu>2013-08-17 04:06:53 +0200
commit0e20270454e45ff54c9f8546159924038e31bfa0 (patch)
tree6fa4fded382ea053ec6ef1d87ec83013a8037e11 /include/keys
parentext4: start handle at least possible moment when renaming files (diff)
downloadlinux-0e20270454e45ff54c9f8546159924038e31bfa0.tar.xz
linux-0e20270454e45ff54c9f8546159924038e31bfa0.zip
ext4: allocate delayed allocation blocks before rename
When ext4_rename() overwrites an already existing file, call ext4_alloc_da_blocks() before starting the journal handle which actually does the rename, instead of doing this afterwards. This improves the likelihood that the contents will survive a crash if an application replaces a file using the sequence: 1) write replacement contents to foo.new 2) <omit fsync of foo.new> 3) rename foo.new to foo It is still not a guarantee, since ext4_alloc_da_blocks() is *not* doing a file integrity sync; this means if foo.new is a very large file, it may not be completely flushed out to disk. However, for files smaller than a megabyte or so, any dirty pages should be flushed out before we do the rename operation, and so at the next journal commit, the CACHE FLUSH command will make sure al of these pages are safely on the disk platter. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'include/keys')
0 files changed, 0 insertions, 0 deletions