[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABqxG0dP5JX+AD2pw=Oq2s+2qzb9LVWxYj0QRc6CxhoK9xQ8FQ@mail.gmail.com>
Date: Sun, 2 Oct 2011 16:46:29 +0800
From: Dave Young <hidave.darkstar@...il.com>
To: Jeff liu <jeff.liu@...cle.com>
Cc: Andreas Dilger <aedilger@...il.com>,
Yongqiang Yang <xiaoqiangnk@...il.com>,
"Ted Ts'o" <tytso@....edu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-ext4@...r.kernel.org
Subject: Re: [BUG] copy file result with zero
2011/10/2 Jeff liu <jeff.liu@...cle.com>:
>
> 在 2011-10-2,下午3:59, Andreas Dilger 写道:
>
>> On 2011-10-01, at 11:41 PM, Jeff liu wrote:
>>>> On Sat, Oct 1, 2011 at 10:39 PM, Ted Ts'o <tytso@....edu> wrote:
>>>>> On Sat, Oct 01, 2011 at 10:01:35PM +0800, Dave Young wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Weird problem, when I build app from source,
>>>>>> make; make install
>>>>>> run the command, but got "cannot execute binary file"
>>>>>>
>>>>>> hexdump shows the installed binary is full of zero
>>>>>>
>>>>>> Is it related to ext4 fiemap problem described below?
>>>>>> http://lwn.net/Articles/429349/
>>>>>
>>>>> There is general agreement that /bin/cp should not have been relying
>>>>> on FIEMAP, and I believe the more recent versions of /bin/cp have
>>>>> removed that code by default pending implementation of
>>>>> SEEK_HOLE/SEEK_DATA. That being said, ext4 had a workaround to its
>>>>> FIEMAP implementation that landed in 2.6.39, and you're using
>>>>> 3.1.0-rc6.
>>>
>>> Actually, upstream cp(1) using FIEMAP only if the source file is sparse, or else, it will do normal copy, i.e, block based.
>>
>> My understanding is that cp uses the blocks count to determine whether the file is sparse or not.
> Yes, it based on blocks count to determine that.
>
>> In the case of delayed allocation (where blocks are not yet allocated, if they are not reflected in the i_blocks count) it might mistakenly think that the file is sparse.
I think this might be my case
> Thanks for pointing this out, I missed this case.
> So for Dave's issue, even if he updated to the upstream Coreutils, this issue will still exists occasionally for delayed allocation, if not run sync in between times.
Not occasionally, I can easily reproduce it recently.
>
>>
>> Given the danger of this bug, it is important to ensure ext4 returns DELALLOC extents for pages in the page cache. I think Yongqiang Yang just submitted a patch series to do this for ext4, so it would be important to verify it fixes this problem.
>
>
> Thanks,
> -Jeff
>>
>>>> Do you means It should work in 3.1.0-rc6 even with cp which depends fiemap?
>>>>
>>>>>
>>>>>> I finally managed to find the way to reproduce this:
>>>>>> just cp a elf binary A to file B, then cp B to file C, then you will get:
>>>>>> A == B != C
>>>>>>
>>>>>> ie.
>>>>>> cp /bin/ls ls1
>>>>>> cp ls1 ls2
>>>>>>
>>>>>> ls2 will be filled with zero
>>>>>
>>>>> If you add a "sync" between the two copies, does that work around the
>>>>> problem? I bet it will...
>>>>
>>>> Yes, it works
>>>>
>>>>>
>>>>> My suggestion is to upgrade to a newer version of coreutils that
>>>>> doesn't try to use FIEMAP.
>>>>
>>>> Thanks, will try
>>>>
>>>>>
>>>>> - Ted
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards
>>>> Dave
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> Cheers, Andreas
>>
>>
>>
>>
>>
>
>
--
Regards
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists