All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akira Fujita <a-fujita@rs.jp.nec.com>
To: djwong@us.ibm.com
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: EXT4_IOC_MOVE_EXT file corruption!
Date: Thu, 15 Apr 2010 17:27:50 +0900	[thread overview]
Message-ID: <4BC6CE06.3070302@rs.jp.nec.com> (raw)
In-Reply-To: <20100405220220.GT29604@tux1.beaverton.ibm.com>

Hi Darrick,

(2010/04/06 7:02), Darrick J. Wong wrote:
> Hi all,
>
> I wrote a program called e4frag that deliberately tries to fragment an ext4
> filesystem via EXT4_IOC_MOVE_EXT so that I could run e4defrag through its
> paces.  While running e4frag and e4defrag concurrently on a kernel source tree,
> I discovered ongoing file corruption.  It appears that if e4frag and e4defrag
> hit the same file at same time, the file ends up with a 4K data block from
> somewhere else.  "Somewhere else" seems to be a small chunk of binary gibberish
> followed by contents from other files(!)  Obviously this isn't a good thing to
> see, since today it's header files but tomorrow it could be the credit card/SSN
> database. :)
>
> Ted asked me to send out a copy of the program ASAP, so the test program source
> code is at the end of this message.  To build it, run:
>
> $ gcc -o e4frag -O2 -Wall e4frag.c
>
> and then to run it:
>
> (unpack something in /path/to/files)
> $ cp -pRdu /path/to/files /path/to/intact_files
> $ while true; do e4defrag /path/to/files&  done
> $ while true; do ./e4frag -m 500 -s random /path/to/files&  done
> $ while true; do diff -Naurp /path/to/intact_files /path/to/files; done
>
> ...and wait for diff to cough up differences.  This seems to happen on
> 2.6.34-rc3, and only if e4frag and e4defrag are running concurrently.  Running
> e4frag or e4defrag in a serial loop doesn't produce this corruption, so I think
> it's purely a concurrent access problem.

I couldn't reproduce this problem, somehow.

My environment is:
Arch: i386
Kernel: 2.6.34-rc3
e2fsprogs: 1.41.11
Mount option: delalloc, data=ordered, async
Block size: 4KB
Partition size: 100GB

Is there any difference in your case?
And how long does this file corruption take to be detected?

I ran below program all day long, but problem did not occur.

---
#!/bin/bash

TARGET="/mnt/mp1/TEST/linux-2.6.34-rc3"
ORIG="/mnt/mp1/TEST/linux-2.6.34-rc3-orig"

cp -pRdu $TARGET $ORIG
while true; do ./e4defrag -v $TARGET & done
while true; do ./e4frag -m 500 -s random $TARGET & done
while true; do diff -Naurp $ORIG $TARGET; done
---

# The OOM killer sometimes runs while running this program
   because this is a heavy load for system, though.

Regards,
Akira Fujita

  parent reply	other threads:[~2010-04-15  8:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-05 22:02 EXT4_IOC_MOVE_EXT file corruption! Darrick J. Wong
2010-04-09 16:20 ` Darrick J. Wong
2010-04-09 17:15   ` Greg Freemyer
2010-04-15  8:27 ` Akira Fujita [this message]
2010-04-15 19:17   ` Darrick J. Wong
2010-04-15 19:25     ` Greg Freemyer

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=4BC6CE06.3070302@rs.jp.nec.com \
    --to=a-fujita@rs.jp.nec.com \
    --cc=djwong@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.