xfs
[Top] [All Lists]

Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?)

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?)
From: Yongqiang Yang <xiaoqiangnk@xxxxxxxxx>
Date: Fri, 15 Apr 2011 00:04:09 +0800
Cc: Pádraig Brady <P@xxxxxxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, coreutils@xxxxxxx, Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KqHYLsAePM4jw1FjqbIQ1N4R6jC9Vy7nKhgsWVTUQes=; b=ov/KkYS3fc6mCC7XZ84wr96p2ibD59lLSyquxPLPhQ+or0FFC9+Hs5YffDNct8Y152 bPdF/sIUgEaI4xOBZMUQKD8aZt8fpMaPiBB4/e46PksiwGQ8/1r0LBFTamwWa20ICCxa 8DLfviaO1KQiBjRJ3n+4ovOpqlqIAxiXk5Md0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UT3znAME/29LDakV9fHucopoV4jL+XkF/sN2wA9kzO482KRXZ3h1aly0sDr/ZQtPNX kl4RRtxOJ2ZjpwrqhiMV/dtGalX9F5RBpdbSspTcW7E/wgX8TGZpWPKbcGbO+cvf+OLC +AReYeoWFl4WQBSG7s/crOtQsv6swGodZm4O0=
In-reply-to: <4DA71920.9@xxxxxxxxxxx>
References: <20110414102608.GA1678@xxxxxxxxxxxxxx> <20110414120635.GB1678@xxxxxxxxxxxxxx> <20110414140222.GB1679@xxxxxxxxxxxxxx> <4DA70BD3.1070409@xxxxxxxxxxxxxx> <4DA717B2.3020305@xxxxxxxxxxx> <4DA7182B.8050409@xxxxxxxxxxxxxx> <4DA71920.9@xxxxxxxxxxx>
2011/4/14 Eric Sandeen <sandeen@xxxxxxxxxxx>:
> On 4/14/11 10:52 AM, Pádraig Brady wrote:
>> On 14/04/11 16:50, Eric Sandeen wrote:
>>> On 4/14/11 9:59 AM, Pádraig Brady wrote:
>>>> On 14/04/11 15:02, Markus Trippelsdorf wrote:
>>>>>>> Hi Pádraig,
>>>>>>>
>>>>>>> here you go:
>>>>>>> + filefrag -v unwritten.withdata
>>>>>>> Filesystem type is: ef53
>>>>>>> File size of unwritten.withdata is 5120 (2 blocks, blocksize 4096)
>>>>>>>  ext logical physical expected length flags
>>>>>>>    0       0   274432            2560 unwritten,eof
>>>>>>> unwritten.withdata: 1 extent found
>>>>>>>
>>>>>>> Please notice that this also happens with ext4 on the same kernel.
>>>>>>> Btrfs is fine.
>>>>>>
>>>>> `filefrag -vs` fixes the issue on both xfs and ext4.
>>>>
>>>> So in summary, currently on (2.6.39-rc3), the following
>>>> will (usually?) report a single unwritten extent,
>>>> on both ext4 and xfs
>>>>
>>>>   fallocate -l 10MiB -n k
>>>>   dd count=10 if=/dev/urandom conv=notrunc iflag=fullblock of=k
>>>>   filefrag -v k # grep for an extent without unwritten || fail
>>>
>>> right, that's what I see too in testing.
>>>
>>> But would the coreutils install have done a preallocation of the 
>>> destination file?
>>>
>>> Otherwise this looks like a different bug...
>>>
>>>> This particular issue has been discussed so far at:
>>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8411
>>>> Note there it was stated there that ext4 had this
>>>> fixed as of 2.6.39-rc1, so maybe there is something lurking?
>>>
>>> ext4 got a fix, but not xfs, I guess.  My poor brain can't remember, I 
>>> think I started looking into it, but it's clearly still broken.
>>>
>>> Still, I don't know for sure what happened to Markus - did something 
>>> preallocate, in his case?
>>
>> Well that preallocate test is failing for him
>> when the source file is either on ext4 or xfs.
>> He noticed the issue initially on XFS when copying
>> none preallocated files, so XFS probably just has
>> the general issue of needing a sync before fiemap,
>> where as EXT4 just has this preallocate one
>> (though I've not seen it myself).
>>
>> cheers,
>> Pádraig.
>>
>
> well, if I simply take the preallocation step out of the testcase, it works 
> fine on xfs without a sync.
>
> So I still don't know what Markus hit...
Sorry for that my patch ignored fallocate.  The situation is like this:
An user allocated space for a file with fallocate, and write a small
part of it. and the written is not flushed.
The extent stays one unwritten extent in disk and memory with delayed
allocation.

In ext4 ext4_ext_walk_space() thinks an extent does not exist only if
there is no any extents on disk.  So ext4_ext_walk_space()
thinks there is a extent and   ext4_ext_fiemap_cb() thus ignores pagecache.

I think ext4_ext_walk_space() should take unwritten extent not exist.

Yongqiang.
>
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Wishes
Yongqiang Yang

<Prev in Thread] Current Thread [Next in Thread>