Whatever they're doing is probably fine, for very liberal values of "fine" (i.e. it's not actually fine and is probably harming system-wide performance and UX in more subtle ways, even on SSDs) for SSD-equipped systems, but made it practically unusable on an HDD.
It's really odd, because the first couple releases of Windows 10 were fast enough on HDDs, but post 1703 is when I started to really notice it.
> We know when the underlying storage is solid state - there's a "non-rotational" field in the block device config that tells us the storage doesn't need physical seek optimisation. We should make use of that.
In other words, the changes under consideration should only apply when they know they're using solid state storage. Is there information elsewhere which contradicts that?
Indeed, it seems very surprising that XFS might consider removing optimizations for slower drives. It's a very popular file system in the enterprise, and anyone still storing large amounts of data is very likely to still be using rotational drives because of the massive cost difference.
Back in 2020, after one update, windows 10 was taking about 5min to boot on a thinkpad, if not more. Had to install a SSD, changed everything.
Pretty curious to hear what kernel developer or filesystem developers have to say about this, because it doesn't really make sense to me.
I can understand why something would stop working, but not to just become slow. In what world does a system change result in worse performance in certain cases?
Maybe deep inside, w10 stopped using any optimization that allowed it to be fast on HDD, considering SSD should be the norm, but I fail to understand if this is choice that implies a difficult compromise, or if it's just laziness and negligence.
Any linux dev could chime in?