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. > 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. ;-) -- Vojtech Pavlik Director SuSE Labs -- 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
