Pádraig Brady wrote: > On 03/04/11 00:00, Ted. > > So this fix is not in 2.6.38? > It was committed before 2.6.38-rc6 was released, > and I would have thought it appropriate for 2.6.38 :( > Anyway I guess that we now have to assume that there > can be 2.6.38 kernels in the wild with this issue, > even if the stable branch does get the fix soon. Yes, this is unfortunate. But it's just an optimization, so probably not a big deal for anyone. I haven't measured the performance difference. Have you? If it's a problem, I suppose once we've seen that most major distros have patched their 2.6.38, we can turn off the sync also for 2.6.38 kernels. > As for 2.6.39, I guess we can assume it's OK, > and ignore the rawhide aberration for a while. Yes. I've adjusted and pushed this: >From 1c3654cb1fb0d8f3c422c766028d0783a40f4a42 Mon Sep 17 00:00:00 2001 From: Jim Meyering <address@hidden> Date: Sat, 2 Apr 2011 19:59:30 +0200 Subject: [PATCH] copy: require fiemap sync also for 2.6.38 kernels * src/extent-scan.c (extent_need_sync): Require sync also for 2.6.38. Without this, part of the cp/fiemap-empty test would fail both on F15-to-be (2.6.38.1-6.fc15.x86_64) and rawhide. For details, see --- src/extent-scan.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/extent-scan.c b/src/extent-scan.c index c0a5de6..d84746c 100644 --- a/src/extent-scan.c +++ b/src/extent-scan.c @@ -31,7 +31,7 @@ # include "fiemap.h" #endif -/* Work around Linux kernel issues on BTRFS and EXT4 before 2.6.38. +/* Work around Linux kernel issues on BTRFS and EXT4 before 2.6.39. FIXME: remove in 2013, or whenever we're pretty confident that the offending, unpatched kernels are no longer in use. */ static bool @@ -50,7 +50,7 @@ extent_need_sync (void) unsigned long val; if (xstrtoul (name.release + 4, NULL, 10, &val, NULL) == LONGINT_OK) { - if (val < 38) + if (val < 39) need_sync = 1; } } -- 1.7.4.2.662.gcbd0