public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jim Meyering <jim@meyering.net>
To: "Pádraig Brady" <P@draigBrady.com>
Cc: Ted Ts'o <tytso@mit.edu>,
	8411@debbugs.gnu.org, linux-ext4@vger.kernel.org
Subject: Re: bug#8411: due to missing sync even on 2.6.39, cp fails to copy an odd file
Date: Sun, 03 Apr 2011 12:26:55 +0200	[thread overview]
Message-ID: <87r59jd40g.fsf@rho.meyering.net> (raw)
In-Reply-To: <4D9847F5.8030804@draigBrady.com> ("Pádraig Brady"'s message of "Sun, 03 Apr 2011 11:12:05 +0100")

Pádraig Brady wrote:

> On 03/04/11 00:00, Ted Ts'o wrote:
>> On Sat, Apr 02, 2011 at 08:08:34PM +0200, Jim Meyering wrote:
>>> From 0a6d128d0d17c1604245f1caafe6af73584a0bb8 Mon Sep 17 00:00:00 2001
>>> From: Jim Meyering <meyering@redhat.com>
>>> Date: Sat, 2 Apr 2011 19:59:30 +0200
>>> Subject: [PATCH] copy: require fiemap sync also for 2.6.38 and 2.6.39 kernels
>>>
>>> * src/extent-scan.c (extent_need_sync): Require sync also for 2.6.38
>>> and 2.6.39.  Without this, part of the cp/fiemap-empty test would fail
>>> both on F15-to-be and rawhide.  For discussion and details, see:
>>> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/22190
>>
>> FYI, the following fix has been merged into mainline, which should fix
>> the problem for 2.6.39 once it is finally released, at least for ext4.
>> It was merged right before Linus released 2.6.39-rc1.  I'm assuming
>> that Rawhide released a pre-2.6.39-rc1 kernel in the middle of the
>> merge window.
>
> 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 <meyering@redhat.com>
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
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/22190
---
 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-04-03 10:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87fwq0gay0.fsf@rho.meyering.net>
2011-04-02 13:29 ` bug#8411: due to missing sync even on 2.6.39, cp fails to copy an odd file Pádraig Brady
2011-04-02 13:50   ` Jim Meyering
2011-04-02 18:08     ` Jim Meyering
2011-04-02 23:00       ` Ted Ts'o
2011-04-03 10:12         ` Pádraig Brady
2011-04-03 10:26           ` Jim Meyering [this message]
2011-04-03 10:46           ` Theodore Tso
2011-04-03 10:15         ` Jim Meyering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r59jd40g.fsf@rho.meyering.net \
    --to=jim@meyering.net \
    --cc=8411@debbugs.gnu.org \
    --cc=P@draigBrady.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox