From: jim owens <owens6336@gmail.com>
To: Valdis.Kletnieks@vt.edu
Cc: David Newall <davidn@davidnewall.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Jeff Garzik <jeff@garzik.org>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
Akira Fujita <a-fujita@rs.jp.nec.com>
Subject: Re: defrag deployment status (was Re: [PATCH] ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode)
Date: Mon, 08 Mar 2010 15:48:33 -0500 [thread overview]
Message-ID: <4B9562A1.2020205@gmail.com> (raw)
In-Reply-To: <4987.1268077130@localhost>
Valdis.Kletnieks@vt.edu wrote:
> On Mon, 08 Mar 2010 11:22:15 EST, jim owens said:
>
>> No. Your logic would be correct if rotating disks had
>> similar speed at all locations. Current disks are much
>> faster at the 0 end than at the middle or highest address.
>>
>> It is not unusual to see 2x difference in transfer speed
>> so you always want the important stuff as low as possible.
>
> On the flip side, seek time is so much larger than the time spent
> actually reading that minimizing the seeks will improve total throughput
> more. Sure, maybe you spend 0.05ms reading instead of 0.1ms - but if
> the seek took 0.75ms rather than 0.5ms you're still in the hole.
Agree that seek proximity is important, but seeking at the low end
for N blocks is also faster than seeking the same N blocks at the
slow high end of the disk.
So my point is you want to pack the data together when you can
at the low address end of the disk to maximize performance.
And we should include some free space in the fast zone because
much of our performance involves short-lived writes.
If you are filling and accessing all of the disk, then maybe
"pack from the middle" will average out better, but we hope
most filesystems have a small hot subset. If you are often
accessing outside the hot zone a lot then you probably will
get end-to-end seek penalties anyway if you are defragging
to an "old, free, hot, free, old" layout.
jim
next prev parent reply other threads:[~2010-03-08 20:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-07 20:32 [PATCH] ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode Christian Borntraeger
2010-03-07 23:27 ` defrag deployment status (was Re: [PATCH] ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode) Jeff Garzik
2010-03-08 5:43 ` Eric Sandeen
2010-03-08 7:53 ` Christian Borntraeger
2010-03-08 15:33 ` David Newall
2010-03-08 16:00 ` Christian Borntraeger
2010-03-08 16:22 ` jim owens
2010-03-08 16:31 ` Greg Freemyer
2010-03-08 17:11 ` jim owens
2010-03-09 13:23 ` jim owens
2010-03-08 19:38 ` Valdis.Kletnieks
2010-03-08 20:48 ` jim owens [this message]
2010-03-09 16:19 ` David Newall
2010-03-08 5:47 ` [PATCH] ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode Eric Sandeen
2010-03-08 8:42 ` Akira Fujita
2010-03-12 7:01 ` [PATCH resend] " Christian Borntraeger
2010-04-02 21:48 ` [PATCH] " tytso
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=4B9562A1.2020205@gmail.com \
--to=owens6336@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=a-fujita@rs.jp.nec.com \
--cc=borntraeger@de.ibm.com \
--cc=davidn@davidnewall.com \
--cc=jeff@garzik.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).