Calamares and discard option in fstab.

Hello,

The iso of the Lysia version of Manjaro contains a version of calamares, adding the discard option, in the / etc / fstab file of users with an SSD.
The discard option is DEPRECATED.
Please read Arch's wiki on this subject
https://wiki.archlinux.fr/SSD
And debian to
https://wiki.debian.org/SSDOptimization
As at RedHat.
The risk is that the user wishing to use the trim, and thinking that Manjaro no longer uses this deprecated option, activates the systemd timer dedicated to this function.
Indeed, the return of the order systemctl status fstrim.timer.
will give the information of a disabled and inactive .timer.
The user wishing to use the trim will activate the .timer sudo systemctl enable --now fstrim.timer
the user will end up with the discard option and the additional function offered by active systemd.
I think this is a risk for possible data loss and a risk for the durability of the hardware.
Can the automatic addition of the discard option be finally deleted?
Cordially,
A Monkey In Winter.

Moderation Note: Fixed a typo and moved to #manjaro-development

2 Likes

From reading the articles, plus the english Arch wiki, it's less about the discard option being deprecated -- it is not -- and more about not being recommended :

Warning: Before SATA 3.1 all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying #Periodic TRIM less often is better alternative. Similar issue holds also for a number of devices, see ata_device_blacklist in Linux source code, for which queued TRIM command execution was blacklisted due to serious data corruption.

The point seems valid though.

"TRIM command execution was blacklisted due to serious data corruption."

I think everything is said in this sentence. :slight_smile:

And I think that the user, knowing that a systemd timer exists, will see in priority if this one is activated, rather than to see in the file fstab, which is "the old method" deprecated, for problems data corruption and possible problems with dm-crypt and other encryption capabilities.
https://wiki.debian.org/SSDOptimization
(please note that some wiki pages are quite old).

You should note this depends on the filesystem you use f2fs never has a discard option from calamares, other file systems may also not have it?

Hello,

I have not tried it, but anyway this option is no longer recommendable.
Fedora 32 activates the .timer by default.
Discard is obsolete and no distribution activates it at installation.
A Monkey In Winter

Adding discard option was decided to be added across all distros using Calamares install framework. You can view the standard upstream configuration here. If it is an issue for you, you can recommend to change that upstream and explain why. We are open to discuss that option. We use discard for 6 years now.

1 Like

@A_Monkey_In_Winter seems you mentioned this two years ago also:

Hello,

Thanks for your reply.

Yes indeed, two years ago, and no evolution.

" We use discard for 6 years now." The problem is there, things evolved during this period.
All major Linux distribution publishers report that this option can have a negative effect on data integrity.
ArchLinux goes in this direction too.
Systemd manages it, and manages it well (Fedora, OpenSUSE, Ubuntu ...). Why keep this option which no longer makes sense today, I wonder.
Moreover, if the user wants to know if the trim is activated, he cannot know it with a systemctl command. Go snooping in the fstab doesn't make sense.
In any case, thank you again for your response.
A Monkey In Winter

What would be the recommended settings then? Enable the systemd service and add noatime and noadirtime as options instead of discard? Can you link me to the articles of Fedora, OpenSUSE and Ubuntu on how they changed it. We had a internal discussion with Calamares developers, and we always open for better default settings. If discard is a bad thing, we can remove it ...

i would suggest enable fstrim.timer
service and remove all discard from fstab.

you can enable fstrim.timer for new installation

or with manjaro-system

Thank you in any case for your accessibility.
noatime is not necessary, the default option of the linux kernel is relatime.
it is more conciliatory, and avoids inode problems with certain messaging software.
The kernel has evolved enormously on this subject, and the default options seem to me the wisest and most compatible.
Links
https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-32-Released
For ubuntu and opensuse, on an installation, a simple systemctl status fstrim.timer will have as feedback that it is activated and started.
Unfortunately at this time of day I cannot provide you with more links.
but I would do it by following this thread.
with the discard option, the pressure on the file system is too heavy, and can really be a problem during heavy operations on it.

Is that correct? It is not recommended. But deprecated?

No it is not all said. Your quote is not complete:

Warning: Before SATA 3.1 all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying #Periodic TRIM less often is better alternative. Similar issue holds also for a number of devices, see ata_device_blacklist in Linux source code, for which queued TRIM command execution was blacklisted due to serious data corruption.

So, the blacklisting only happened for "a number of devices".

Can you please share share this, please? I could not find anything when using google.

Is this true for kernel 4.14 as well?

Hello,
I think there is a problem of understanding.
You are reading an old article, with indeed a list of microcode which can be problematic.
However, the discard option remains the discard option, and therefore permanently trim your file system, regardless of the SSD used.
It is therefore a constraint, which has to be overcome by systemd with its weekly timer.
A Monkey In Winter

Hello

relatime was introduced in the 2.6.20 kernel.
Since 2007 ^^
https://kernelnewbies.org/Linux_2_6_20

A Monkey In Winter

Please see the links given at the beginning of the post.

3 Likes

You mean the link to debian and arch you provided? I read them. But there is no mentioning of negative affects on data integrity. Only the deina page is mentioning something at the very beginning. But that is the same warning that is included in the arch wiki.

Other than that I do not find evidence that "All major Linux distribution publishers report that this option can have a negative effect on data integrity." as you put it.

Dont get me wrong: Iam using fstrim.timer myself and I believe that this should be the default. But I just want to follow up on your strong claim.

Forum kindly sponsored by