From: Jamie Lokier <jamie@shareable.org>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Andreas Dilger <adilger@sun.com>,
linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0 of 3] [RFC] I/O Hints
Date: Mon, 9 Jun 2008 11:47:58 +0100 [thread overview]
Message-ID: <20080609104758.GB25541@shareable.org> (raw)
In-Reply-To: <yq14p86mrvw.fsf@sermon.lab.mkp.net>
Martin K. Petersen wrote:
> Jamie> Where it is due to specific values being not exactly right -
> Jamie> like the subdevice offset (or modulo-offset) in MD because it
> Jamie> doesn't represent all subdevices - it would be good for the
> Jamie> info to have flags saying which _specific_ values are not
> Jamie> exactly right.
>
> You get that traversing the sysfs tree.
Ok. So I should always traverse the sysfs tree, and only use the leaf
values, combining them at MD nodes as I see fit, and ignoring the
values you provide at MD nodes?
Is there enough information in sysfs for me to combine the values?
I.e. offsets of all child disks, etc.?
What about future compound disk types that my app doesn't know about?
Use your values, I guess.
> Jamie> So that programs can choose their heuristics appropriately.
> Jamie> After all, users will use suboptimal layouts, and still want
> Jamie> the best performance it can do.
>
> I'd like to keep a clear distinction between normal applications and
> programs like mkfs. I'm targeting the latter.
>
> Given that filesystems can lay out files at will, I/O characteristics
> for normal applications is really FIEMAP territory.
I'm thinking of database type applications directly on block devices.
They need similar performance guides as filesystems.
You're right that most apps are FIEMAP territory.
Vice versa: Filesystems on LVM may be FIEMAP territory, if there are
many non-contiguous LVM strips, spanning multiple devices, LVM
snapshots, etc.
-- Jamie
next prev parent reply other threads:[~2008-06-09 10:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 5:22 [PATCH 0 of 3] [RFC] I/O Hints Martin K. Petersen
2008-06-05 5:22 ` [PATCH 1 of 3] block: Export I/O hints for block devices and partitions Martin K. Petersen
2008-06-05 14:42 ` James Bottomley
2008-06-06 1:18 ` Martin K. Petersen
2008-06-06 14:21 ` Jamie Lokier
2008-06-05 5:22 ` [PATCH 2 of 3] md: Export preferred I/O sizes and physical alignment Martin K. Petersen
2008-06-05 5:22 ` [PATCH 3 of 3] sd: Export preferred I/O sizes Martin K. Petersen
2008-06-05 11:25 ` Boaz Harrosh
2008-06-05 6:27 ` [PATCH 0 of 3] [RFC] I/O Hints Andreas Dilger
2008-06-05 10:32 ` Jamie Lokier
2008-06-05 12:35 ` Matthew Wilcox
2008-06-05 17:02 ` Dan Williams
2008-06-06 1:03 ` Martin K. Petersen
2008-06-06 14:02 ` Jamie Lokier
2008-06-06 16:48 ` Martin K. Petersen
2008-06-09 10:47 ` Jamie Lokier [this message]
2008-06-10 2:17 ` Martin K. Petersen
2008-06-05 10:40 ` Jamie Lokier
2008-06-05 19:19 ` Andreas Dilger
2008-06-06 12:55 ` Jamie Lokier
2008-06-06 1:16 ` Martin K. Petersen
2008-06-06 4:51 ` Dave Chinner
2008-06-06 16:53 ` Martin K. Petersen
2008-06-07 20:54 ` Dave Chinner
2008-06-09 15:05 ` Martin K. Petersen
2008-06-06 12:52 ` Jamie Lokier
2008-06-06 14:26 ` Jamie Lokier
2008-06-06 16:56 ` Martin K. Petersen
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=20080609104758.GB25541@shareable.org \
--to=jamie@shareable.org \
--cc=adilger@sun.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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).