On Fri, Nov 15, 2024 at 02:17:49PM -0500, Andrea Bolognani wrote:
On Sat, Nov 16, 2024 at 02:28:24AM +0800, d tbsky wrote:
> Andrea Bolognani <abologna(a)redhat.com>
> > I'd also be surprised if this only affected Windows. Wouldn't Linux
> > guests likely see a similar change in how the device is presented?
>
> I don't understand all the impact under windows. but defrag is the
> obvious part. by default windows will do disk optimization weekly.
> trim was fast when I was using windows 2019 with virtio-blk drivers at
> that time. and you could manually do traditional defrag to the device
> although it will also do unnecessary trim after defrag. But recent
> windows server 2019/2022 with recent virtio-blk driver, trim was very
> slow and a bigger disk like 1TB thin-device will just show "memory not
> enough" when defrag(but NTFS really need defrag). I don't know
This sounds like a virtio driver issue.
> what/when changed the behavior. I found
"discard_granularity" seems
> the saver for both cases.
>
> when I use linux I don't care since it won't do trim automatically. I
> need to mount with options or do fstrim for the device. and there is
> no need to defrag the hard-disk. Since there is no automatic part, I
> don't know if this is useful or not to distinguish hdd/sdd/thin-device
> under linux?
At least on Fedora, trim should be performed periodically by default.
https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
Probably this doesn't hit the same awful performance issues as
Windows, but it might still not make sense to do it at all if the
underlying storage is not flash-based.
Which would make sense if there are different drivers.
Just a thought though.
Or maybe it does! I'm far from an expert when it comes to storage
:)
--
Andrea Bolognani / Red Hat / Virtualization