From: Ryan Lortie Date: Tue, 4 Jun 2013 13:48:12 +0000 (-0400) Subject: g_file_set_contents(): don't fsync on ext3/4 X-Git-Tag: 2.37.2~32 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=9d0c17b50102267a5029b58b1f44efbad82d8f03;p=platform%2Fupstream%2Fglib.git 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 EXT3_SUPER_MAGIC. https://bugzilla.gnome.org/show_bug.cgi?id=701560 --- diff --git a/glib/gfileutils.c b/glib/gfileutils.c index 7e5bedc..05a46ee 100644 --- a/glib/gfileutils.c +++ b/glib/gfileutils.c @@ -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; } #endif