All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Tomas <bzzz.tomas@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Andreas Dilger <adilger@clusterfs.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Valerie Clement <valerie.clement@bull.net>,
	Theodore Tso <tytso@mit.edu>, Mingming Cao <cmm@us.ibm.com>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: delalloc and reservation.
Date: Mon, 29 Oct 2007 19:26:40 +0300	[thread overview]
Message-ID: <472609C0.3030606@gmail.com> (raw)
In-Reply-To: <4725FA1F.1090000@linux.vnet.ibm.com>

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
> 

  reply	other threads:[~2007-10-29 15:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 10:00 delalloc and reservation Aneesh Kumar K.V
2007-10-29 11:07 ` Aneesh Kumar K.V
2007-10-30 11:01   ` [RFC/PATCH] ext4: Clear the reservation window correctly with delayed allocation Aneesh Kumar K.V
2007-10-30 11:24     ` Alex Tomas
2007-10-29 15:14 ` delalloc and reservation Alex Tomas
2007-10-29 14:33   ` Aneesh Kumar K.V
2007-10-29 15:44     ` Alex Tomas
2007-10-29 15:19       ` Aneesh Kumar K.V
2007-10-29 16:26         ` Alex Tomas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-10-29 14:24 Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=472609C0.3030606@gmail.com \
    --to=bzzz.tomas@gmail.com \
    --cc=adilger@clusterfs.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    --cc=valerie.clement@bull.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.