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.
On Thu, Dec 12, 2019 at 11:30 PM Chris Murphy <lists(a)colorremedies.com> wrote:
> On Thu, Dec 12, 2019 at 2:07 PM Damian Ivanov <damianatorrpm(a)gmail.com> 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
> > 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
> > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: