From: Kai Krakow <hurikhan77@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: Reasoning of exposing queue/rotational=0
Date: Fri, 5 May 2017 20:23:17 +0200 [thread overview]
Message-ID: <20170505202317.68bdbc20@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 20170505174438.GA22811@suse.com
Am Fri, 5 May 2017 19:44:39 +0200
schrieb Vojtech Pavlik <vojtech@suse.com>:
> On Sat, May 06, 2017 at 12:11:13AM +0800, Coly Li wrote:
> > On 2017/5/5 上午5:24, Kai Krakow wrote:
> > > Hello!
> > >
> > > What's the reasoning for exposing bcache devices as being
> > > non-rotational? Currently, it fools btrfs into using ssd
> > > allocation scheme on the underlying harddisks which isn't really
> > > what I expected to get. So I used a udev rule to change this:
> > >
> > > ACTION=="add|change", KERNEL=="bcache*",
> > > ATTR{queue/rotational}="1"
> > >
> > > Wouldn't it make more sense to set this to the same value as the
> > > underlying backing device by default?
> > >
> > > Because in reality, the bcache is still what the backing device
> > > is: A rotational medium. A cache doesn't make this non-rotational.
> > >
> > > Thoughts?
> >
> > It depends on hit ration. If a non-rotational device used as cache,
> > and hit ration is high enough, the cached device just responses as
> > non-rotational device.
> >
> > But yes, I feel your opinion makes sense, in the btrfs case. How
> > about a policy like this:
> >
> >
> > cache-device-rotational backing-device-rotational
> > export-rotational Y
> > Y Y Y
> > N N N
> > Y N N
> > N N
> >
> > That is, a bcache device is exposed as non-rotational device only
> > when all devices of cache devices and backing devices are all
> > rotational.
>
> I don't think that makes much sense either - the cache device will not
> be used in the pattern that the exposed bcache device is, so any
> choice of access patterns by a higher level based on
> rotational/non-rotational will be messed up anyway.
>
> I think the current behavior (rotational=0) is correct in most cases.
Well, I don't want to do bikeshedding... But both didn't answer my
original question of what's the reasoning. Did anyone put thoughts into
this? Was it arbitrarily chosen? Is rotational=0 just a default that
bcache didn't bother to explicitly set?
Answering the last two questions with "yes" would suggest that it should
be rethought...
Answering the first with "yes" means I'd like to know more. ;-)
--
Regards,
Kai
Replies to list-only preferred.
next prev parent reply other threads:[~2017-05-05 18:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 21:24 Reasoning of exposing queue/rotational=0 Kai Krakow
2017-05-05 16:11 ` Coly Li
2017-05-05 17:44 ` Vojtech Pavlik
2017-05-05 18:23 ` Kai Krakow [this message]
2017-05-05 19:02 ` Vojtech Pavlik
2017-05-05 19:14 ` Kai Krakow
2017-05-09 18:11 ` Eric Wheeler
2017-05-10 20:18 ` Kai Krakow
2017-05-05 19:01 ` Kai Krakow
2017-05-05 18:04 ` Kai Krakow
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=20170505202317.68bdbc20@jupiter.sol.kaishome.de \
--to=hurikhan77@gmail.com \
--cc=linux-bcache@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