Am Fri, 5 May 2017 21:02:31 +0200 schrieb Vojtech Pavlik <vojtech@xxxxxxxx>: > On Fri, May 05, 2017 at 08:23:17PM +0200, Kai Krakow wrote: > > > 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? > > Originally, rotational=1 is just a flag coming from the > IDE/SCSI/SATA/etc. layers to the OS telling it whether the device is > spinning or not. Without any specific implications as to the behavior > of the device. > > It is writable for a reason - not even all flash based devices report > the flag correctly at the hardware level. > > Linux uses the flag on the block device (queue) to tell whether seeks > are very expensive compared to linear reads and whether it makes sense > to spend large amounts CPU cycles and memory on reordering. > > Btrfs is one user that tries to change the allocation policy and thus > the likelihood of fragmentation and/or long seeks based on whether the > device reports 'rotational'. > > However, it actually has three modes at the fs level: 'nossd', > 'ssd' and 'ssd_spread', with the last being faster on cheaper SSDs. > There are large differences even between individual SSD profiles. > Again, for a good reason, btrfs has these as mount options that > override any 'rotational' hint. > > All in all, if you want all the performance available, you need to see > what works best for your workload. > > The same applies to i/o schedulers. They're much less dependent on the > underlying device than the workload put on them. > > This is not the first time the question comes up. I tried to look up information about it previously but didn't came up with useful results. > > Was it arbitrarily chosen? Is rotational=0 just a default that > > bcache didn't bother to explicitly set? > > A bcache device performance profile is neither one of a rotational > device, nor one of a SSD. > > Sequential reads may be bypassed or not. If not, some parts of it may > be cached, in which case there will be seeks on the backing device > even when there should be none on a real rotational device. > > Random reads may be fast if they're hitting cached locations. > > Random and sequential writes will be always cached if writeback is > enabled and so there is no point in spending CPU cycles on optimizing > writes. > > How much the bcache device will behave like the backing device and how > much like the caching device does depend mainly on the workload and > the size of its working set compared to the size of the cache. > > I do not believe that the choice of rotational=0 was arbitrary or a > default. It's simply that bcache changes the access pattern to both > the caching and backing device so much that it no longer resembles a > rotational device's performance profile in any case. > > > 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. ;-) Okay, that answers my questions. Thanks. :-) But that only tells me that a "default" cannot be really chosen. Both make sense. I wonder if Linux chose to call the flag "non_rotational", would it also default to 0 in bcache? I think nobody would know. ;-) For me it looks like sticking that to rotational=1 gives overall better long-time performance and btrfs filesystem layout. Anyone who stumbles across this should judge on his own based on Vojtech's good answer. -- 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
