Commit 9d0c17b5 authored by Allison Karlitskaya's avatar Allison Karlitskaya
Browse files

g_file_set_contents(): don't fsync on ext3/4

ext3 and ext4 (for quite some time) with default mount options don't
need fsync() to ensure safety of replace-by-rename.  Stop doing that for
these filesystems.

Note: this patch also impacts ext2, which is probably not safe, but I
don't know of any way to check ext2. vs the others because they all have
the same magic numbers (short of opening /proc/mount).

This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
parent 16b26231
......@@ -1088,9 +1088,16 @@ write_to_temp_file (const gchar *contents,
/* On Linux, on btrfs, skip the fsync since rename-over-existing is
* guaranteed to be atomic and this is the only case in which we
* would fsync() anyway.
* ext3 and ext4 are also safe in this respect under the default
* mount options (and if someone picks non-default options to
* improve their performance at the cost of reliability, who are we
* to argue?)
* Note: EXT[234]_SUPER_MAGIC are equal.
if (fstatfs (fd, &buf) == 0 && buf.f_type == BTRFS_SUPER_MAGIC)
if (fstatfs (fd, &buf) == 0 && (buf.f_type == BTRFS_SUPER_MAGIC || buf.f_type == EXT3_SUPER_MAGIC))
goto no_fsync;
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment