linux-ext4 - Re: delalloc and reservation.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4725FA1F.1090000@linux.vnet.ibm.com>
Date:	Mon, 29 Oct 2007 20:49:59 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Alex Tomas <bzzz.tomas@...il.com>
CC:	Andreas Dilger <adilger@...sterfs.com>,
	Eric Sandeen <sandeen@...hat.com>,
	Valerie Clement <valerie.clement@...l.net>,
	Theodore Tso <tytso@....edu>, Mingming Cao <cmm@...ibm.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: delalloc and reservation.



Alex Tomas wrote:
> sorry, I don't quite understand how do you observe this with nomballoc
> 
> thanks, Alex
> 
> Aneesh Kumar K.V wrote:
>> mballoc by default doesn't give the particular layout only if i force 
>> small
>> size to use inode preallocation i am hitting the problem. ie to change 
>> the
>> below line in ext4_mb_group_or_file
>>
>> if (ac->ac_o_ex.fe_len >= sbi->s_mb_small_req)
>>
>> to
>> if (ac->ac_o_ex.fe_len <= sbi->s_mb_small_req)
>>
>> Do you want to test the patch with this change ?
>>
>> We are observing the problem with delalloc and nomballoc.
>>


As i explained in the previous mail the problem is with the 
the current reservation code using ext4_block_alloc_info.


EXT4_I(inode)->i_block_alloc_info;

Now what is happening is we are not discarding the reservation
with respect to particular inode in case of dealloc. Without
delalloc we discard the reservation during close(). But with
dealloc the we are getting new reservation in the writeback
path and we don't discard the reservation. This results
in the files being spread across and not closely allocated
on disk. 

BTW with your patch and the change i suggested above 
the problem still exist. 


The output is while requesting for 2 blocks
printed by this in ext4_ext_get_blocks

 printk(KERN_CRIT "allocate new block: goal %llu, found %llu/%lu\n",
                       ar.goal, newblock, ar.len);


allocate new block: goal 28672, found 12288/1
allocate new block: goal 8192, found 12292/2
allocate new block: goal 8192, found 12296/2
allocate new block: goal 8192, found 12300/2
allocate new block: goal 8192, found 12304/2
allocate new block: goal 8192, found 12308/2
allocate new block: goal 8192, found 12312/2
allocate new block: goal 8192, found 12316/2
allocate new block: goal 8192, found 1440/2
allocate new block: goal 8192, found 1444/2
allocate new block: goal 8192, found 1448/2
allocate new block: goal 8192, found 1452/2
allocate new block: goal 8192, found 1456/2
allocate new block: goal 8192, found 1460/2
allocate new block: goal 8192, found 1464/2
allocate new block: goal 8192, found 1468/2
allocate new block: goal 8192, found 12320/2
allocate new block: goal 8192, found 12324/2
allocate new block: goal 8192, found 12328/2
allocate new block: goal 8192, found 12332/2
allocate new block: goal 8192, found 12336/2


with the change mballoc was not giving the problem
described because it uses blocks from group
preallocation.

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