From: Lennart Poettering <lennart@poettering.net>
To: Ric Wheeler <rwheeler@redhat.com>
Cc: Josef Bacik <josef@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
linux-btrfs@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: [PATCH] Btrfs: add a disk info ioctl to get the disks attached to a filesystem
Date: Wed, 29 Sep 2010 13:59:04 +0200 [thread overview]
Message-ID: <20100929115903.GA13882@tango.0pointer.de> (raw)
In-Reply-To: <4CA2E9CD.5090700@redhat.com>
On Wed, 29.09.10 16:25, Ric Wheeler (rwheeler@redhat.com) wrote:
> >This in fact is how all current readahead implementations work, be it
> >the fedora, the suse or ubuntu's readahead or Arjan's sreadahead. What's
> >new is that in the systemd case we try to test for ssd/rotating
> >properly, instead of just hardcoding a check for
> >/sys/class/block/sda/queue/rotational.
> >
>
> A couple of questions pop into mind - is systemd the right place to
> automatically tune readahead? If this is a generic feature for the
> type of device, it sounds like something that we should be doing
> somewhere else in the stack (not relying on tuning from user space).
Note that this is not the kind of readahead that is controllable via
/sys/class/block/sda/queue/read_ahead_kb, this is about detecting "hot"
files at boot, and then preloading them on the next boot. i.e. the
problem Jens once proposed fcache for.
> Second question is why is checking in /sys a big deal, would you
> prefer an interface like we did for alignment in libblkid?
Well, currently there's no way to discover the underlying block devices
if you have a btrfs mount point. This is what Josef's patch added for
us.
Lennart
--
Lennart Poettering - Red Hat, Inc.
next prev parent reply other threads:[~2010-09-29 11:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 20:53 [PATCH] Btrfs: add a disk info ioctl to get the disks attached to a filesystem Josef Bacik
2010-09-28 22:28 ` Goffredo Baroncelli
2010-09-29 0:24 ` Josef Bacik
2010-09-28 23:25 ` Christoph Hellwig
2010-09-29 0:08 ` Josef Bacik
2010-09-29 0:19 ` Lennart Poettering
2010-09-29 7:25 ` Ric Wheeler
2010-09-29 8:04 ` Kay Sievers
2010-09-29 23:43 ` Christoph Hellwig
2010-09-30 0:32 ` Josef Bacik
2010-09-30 7:43 ` Kay Sievers
2010-09-30 12:38 ` Josef Bacik
2010-09-30 13:47 ` Andi Kleen
2010-09-30 19:48 ` Josef Bacik
2010-09-30 19:59 ` Kay Sievers
2010-09-30 20:37 ` Lennart Poettering
2010-09-29 11:59 ` Lennart Poettering [this message]
2010-09-29 12:08 ` Ric Wheeler
2010-09-29 12:19 ` Kay Sievers
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=20100929115903.GA13882@tango.0pointer.de \
--to=lennart@poettering.net \
--cc=hch@infradead.org \
--cc=josef@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=rwheeler@redhat.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).