From: Theodore Tso <tytso@mit.edu>
To: Andi Kleen <andi@firstfloor.org>
Cc: Chris Mason <chris.mason@oracle.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Btrfs v0.16 released
Date: Fri, 8 Aug 2008 21:43:48 -0400 [thread overview]
Message-ID: <20080809014348.GC9967@mit.edu> (raw)
In-Reply-To: <20080809012322.GF9038@one.firstfloor.org>
On Sat, Aug 09, 2008 at 03:23:22AM +0200, Andi Kleen wrote:
> > In theory, if the elevator was smart enough, it could actually help
> > read seekiness; there are two copies of the metadata, and it shouldn't
>
> That assumes the elevator actually knows what is nearby? I thought
> that wasn't that easy with modern disks with multiple spindles
> and invisible remapping, not even talking about RAID
> arrays looking like disks.
RAID is the big problem, yeah. In general, though, we are already
making an assumption in the elevator code and in filesystem code that
block numbers which are numerically closer together are "close" from
the perspective of disks. There has been talk about trying to make
filesystems smarter about allocating blocks by giving them visibility
to the RAID parameters; in theory the elevator algorithm could also be
made smarter as well using the same information. I'm really not sure
if the complexity is worth it, though....
- Ted
next prev parent reply other threads:[~2008-08-09 1:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-05 19:01 Btrfs v0.16 released Chris Mason
2008-08-07 9:08 ` Peter Zijlstra
2008-08-07 10:34 ` Chris Mason
2008-08-07 14:58 ` Chris Friesen
2008-08-07 15:07 ` tvrtko.ursulin
2008-08-07 9:14 ` Peter Zijlstra
2008-08-07 10:39 ` Chris Mason
[not found] ` <3da3b5b40808070703x4cf49471q6acc00351ba019d7@mail.gmail.com>
2008-08-07 14:06 ` Chris Mason
2008-08-07 18:02 ` Andi Kleen
2008-08-08 18:48 ` Chris Mason
2008-08-08 21:56 ` Andi Kleen
2008-08-09 1:19 ` Theodore Tso
2008-08-09 1:23 ` Andi Kleen
[not found] ` <20080809012322.GF9038@one.firstfloor.org>
2008-08-09 1:43 ` Theodore Tso [this message]
2008-08-14 21:00 ` Chris Mason
2008-08-14 21:17 ` Andi Kleen
2008-08-15 1:25 ` Chris Mason
2008-08-15 1:39 ` Andi Kleen
2008-08-15 13:00 ` Chris Mason
2008-08-16 19:26 ` Szabolcs Szakacsits
2008-08-18 13:52 ` Chris Mason
2008-08-18 17:37 ` Szabolcs Szakacsits
2008-08-14 23:44 ` Theodore Tso
2008-08-15 1:10 ` Chris Mason
2008-08-15 12:46 ` Chris Mason
2008-08-15 13:45 ` Theodore Tso
2008-08-15 17:52 ` Chris Mason
2008-08-15 19:59 ` Theodore Tso
2008-08-15 20:37 ` Chris Mason
2008-08-16 18:10 ` Chris Mason
2008-08-16 19:27 ` Theodore Tso
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=20080809014348.GC9967@mit.edu \
--to=tytso@mit.edu \
--cc=andi@firstfloor.org \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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).