[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <472609C0.3030606@gmail.com>
Date: Mon, 29 Oct 2007 19:26:40 +0300
From: Alex Tomas <bzzz.tomas@...il.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.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.
ah, got it now. I think the solution would be to discard preallocated blocks
once blocks for all dirty data are allocated and file is closed. In the previous
version of delalloc I did this passing NOPREALLOC hint. something similar should
be done in the newer one, I guess.
thanks, Alex
Aneesh Kumar K.V wrote:
>
>
> 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
Powered by blists - more mailing lists