Re: EXT4_IOC_MOVE_EXT file corruption!

[Greg Freemyer <greg.freemyer@gmail.com>]

On Thu, Apr 15, 2010 at 3:17 PM, Darrick J. Wong <djwong@us.ibm.com> wrote:
> On Thu, Apr 15, 2010 at 05:27:50PM +0900, Akira Fujita wrote:
>> 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.
>
> Hmm.  I was running with 2.6.34-rc3 on x86-64, same block size, though with a
> 2TB mdraid0.  It usually took a few hours to reproduce, though I've noticed
> that if I kick off at least as many e4defrags and e4frags, it will show up much
> sooner.  Thank you for trying this out!

If its not reproducible on a simple disk, it could be a bug in the
barrier code for mdraid.

But I think raid0 support for barriers has been around for a long time.

Greg
--
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