Hello Chris, Thanks for the response. What a data loss or data corruption is has to be carefully defined (whole partition or file based etc). As an indirect result of fstrim not being enabled I have experienced data loss: The performance was so degraded that I had tried setting commit=120 on all partitions and after pulling the plug since a simple copy operation may still result in kernel oops - I have only seen that one with the MuQss scheduler which I tried once - after completely freezing 2 minutes of changes may be lost. (Yes so slow copying files result in kernel oops - or permanently frozen system, at the maximum I left the computer for hours it was still doing intensively something so that the heat was rising and the system under heavy load, mentioning hardware weariness, still talking a simple short copy operation here, which now takes less than five minutes - with journalctl's last boot words being that the libinput could't process events of the razer mouse). So as an indirect result of fstrim not being enabled I have experienced data loss. There also can be a distinction between defaults in RHEL and Fedora. Though I don't think that enterprise SSD or VM's are affected by fstrim causing data issues. Regards, Damian On Thu, Dec 12, 2019 at 11:30 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, Dec 12, 2019 at 2:07 PM Damian Ivanov <damianatorrpm@xxxxxxxxx> wrote: > > > > Hello, > > > > I wanted to share this with you and if you point me in the right > > direction under what section > > to add something like this in the wiki I will do so! > > > > After running my system a while it continued to slow down and at some point > > it was so extreme that a simple copy operation would render the mouse unmovable. > > Note that this is an i7, 8G Ram, SSD etc. > > > > Changing to BFQ schedule, tune BFQ parameters, disabling swapping, > > compiling the kernel with the Muqss scheduler, nothing did help. It is > > not a hardware issue! > > > > It seems by default fstrim is disabled from systemd and by default > > nothing formats it with discard option. > > > > Running fstrim / && fstrim /home && systemctl enable fstrim.service > > changed the performance a dozen fold. > > This is a balancing act, because there are devices that perform better > with an occasional fstrim, and other devices that misbehave. Most > devices don't benefit from it, but then an even large pool of devices > aren't hurt either. > > For the near term, there are enough devices that lack support for > queued trim that discard mount option by default is probably not a > good idea. In case of a non-queued trim supporting drive, it basically > stalls in workloads where there are a lot of file system changes. > Newer drives support queued trim. > > And still other drives have firmware bugs where trim results in data > corruption or loss. Which is a better default? Exposing a significant > minority of users to slowing devices, or exposing a small group to > data loss? But these days most of those devices have been identified, > and either have firmware fixes, removed from production use, or have > been blacklisted in the kernel for trim (i.e. trim is not passed down > to those devices). > > It's reasonable to consider enabling fstrim.service by default. This > would cause trim to be issued once per week. But I think it should be > proposed as a system wide change so that it gets the necessary > visibility. Ubuntu does enable it by default for a few releases now; I > don't know for sure if openSUSE enables it by default. > > > -- > Chris Murphy > _______________________________________________ > desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
