[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-ext4
Subject: Re: FIEMAP sometimes returns bad information for delalloc extents
From: Eric Sandeen <sandeen () redhat ! com>
Date: 2010-03-27 18:35:17
Message-ID: 4BAE4FE5.7020004 () redhat ! com
[Download RAW message or body]
Andreas Dilger wrote:
> On 2010-03-27, at 09:07, Theodore Ts'o wrote:
>> I was monitoring the progress of a distributed download program, and saw
>> the following output from two runs of filefrag taken a few seconds
>> apart:
>>
>> 8 790 8825663 8825551 65
>> 9 855 0 8825727 319 unknown,delalloc
>> 10 1174 8798367 318 128
>>
>> 7 790 8825663 8825559 69
>> 8 1174 8798367 8825731 128
>>
>> The length of the delalloc extent, 319, is bogus. The 319 seems to come
>> from 1174 - 855. But it's not actually the number of delayed
>> allocation blocks, as we can see when the blocks finally get written;
>> apparently it was only 4 blocks long.
>
> I'm surprised it shows anything at all for delalloc blocks, since AFAIK
> FIEMAP is only walking the extent tree. It would be interesting if it
> walked the VM pagetable for unallocated extents in the file, and beyond
> i_size.
it does this in the callback for ext4_ext_walk_space:
if (newex->ec_type == EXT4_EXT_CACHE_GAP) {
...
page = find_get_page(inode->i_mapping, offset);
...
bh = page_buffers(page);
...
if (buffer_delay(bh)) {
flags |= FIEMAP_EXTENT_DELALLOC;
...
so it was an attempt, at least, to flag which extents are delalloc.
FWIW, on xfs xfs_bmap initially would cause a file flush, it didn't even ever
try to report delalloc until fiemap came along ...
-Eric
--
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic