From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kai Krakow Subject: Re: Reasoning of exposing queue/rotational=0 Date: Fri, 5 May 2017 20:23:17 +0200 Message-ID: <20170505202317.68bdbc20@jupiter.sol.kaishome.de> References: <20170504232457.13c269c0@jupiter.sol.kaishome.de> <20170505174438.GA22811@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Return-path: Received: from [195.159.176.226] ([195.159.176.226]:55575 "EHLO blaine.gmane.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751736AbdEESXk (ORCPT ); Fri, 5 May 2017 14:23:40 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d6ht2-0003ha-0A for linux-bcache@vger.kernel.org; Fri, 05 May 2017 20:23:28 +0200 Sender: linux-bcache-owner@vger.kernel.org List-Id: linux-bcache@vger.kernel.org To: linux-bcache@vger.kernel.org Am Fri, 5 May 2017 19:44:39 +0200 schrieb Vojtech Pavlik : > 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.