linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).