From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: 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>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: delalloc and reservation.
Date: Mon, 29 Oct 2007 15:30:59 +0530 [thread overview]
Message-ID: <4725AF5B.1000300@linux.vnet.ibm.com> (raw)
Hi All,
I looked at the delalloc and reservation differences that Valerie was observing.
Below is my understanding. I am not sure whether the below will result in
higher fragmentation that Eric Sandeen is observing. I guess it should not. Even
though the reservation gets discarded during the clear inode due to memory pressure
the request for new reservation should get the blocks nearby and not break extents right ?
any how below is the simple case.
without delalloc the blocks are requested during prepare_write/write_begin.
That means we enter ext4_new_blocks_old which will call ext4_try_to_allocate_with_rsv.
Now if there is no reservation for this inode a new one will be allocated. After
using the blocks this reservation is destroyed during the close via ext4_release_file
With delalloc the blocks are not requested until we hit writeback/ext4_da_writepages
That means if we create new file and close them the reservation will be discarded
during close via ext4_release_file.( Actually there will be nothing to clear)
Now when we do a sync/or write back. We try to get the block, the inode will
request for new reservation. This reservation is not discarded untill we call clear_inode
and that results in the behavior we are seeing.
Free blocks: 1440-8191, 8194-8199, 8202-8207, 8210-8215, 8218-8223, 8226-8231, 8234-8239, 8242-8247, 8250-8255, 8258-8263, 8266-8271, 8274-8279, 8282-8287, 8290-8295, 8298-8303, 8306-8311, 8314-8319, 8322-8327, 8330-8335, 8338-8343, 8346-12799
So now the question is where do we discard the reservation in case of delalloc.
-aneesh
next reply other threads:[~2007-10-29 10:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 10:00 Aneesh Kumar K.V [this message]
2007-10-29 11:07 ` delalloc and reservation 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
-- 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=4725AF5B.1000300@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@clusterfs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).