Am Fri, 5 May 2017 19:44:39 +0200
schrieb Vojtech Pavlik <vojtech@xxxxxxxx>:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
