lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 27 Mar 2010 13:35:17 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andreas Dilger <andreas.dilger@...cle.com>
CC:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: FIEMAP sometimes returns bad information for delalloc extents

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ