When configuring ext 4 file systems with diskdrake there is no checkbox to select the 'discard' option which is essential with SSD drives. Ideally diskdrake should set the discard option automatically if an SSD is detected. drakconf-12.33-2.mga3
Source RPM: (none) => drakconf-12.33-2.mga3Whiteboard: (none) => 3beta2
Well this is debated stuff.. discard will actally slow down your everyday ssd usage, compared to regular use of fstrim... se for example: https://patrick-nagel.net/blog/archives/337
CC: (none) => tmb
That may well be true although I have a recollection that discard on recent kernels is improved, but my concern is for the Mageia user who is not an expert in file system design who uses diskdrake to set up their SSD. With neither fstrim nor discard the performance of their SSD will inevitably degrade as the blocks become used up and the ssd has to erase before write. If diskdrake had a discard option checkbox, then the text alongside it could advise the user that fstrim in a cron job performs better. Maybe there should be a link to the wiki page?
Many thanks for reporting this Derek. I have been having problems with my SSD and this bug report finally encouraged me to do some research. Discard was enabled but not working, and I was seeing various errors in syslog. I removed all the data (my roots for 3 systems), updated the drive's firmware, security zeroed it, re-partitioned it (aligned, as it was before) and finally restored the systems. Now discard works and bug 7046 that I have suffered with for months has vanished! I just made a little test script to check that discard works: http://mtf.no-ip.co.uk/pub/linux/barjac/soft/chkdiscard Thanks again, and yes, the option to enable it in diskdrake would be good, as would an option to create aligned partitions.
CC: (none) => zen25000
> Thanks again, and yes, the option to enable it in diskdrake would be good, as > would an option to create aligned partitions. diskdrake has already been fixed to correctly align the partitions A fix for Bug 1215 has been committed, but the bug report remains open. I tried it out recently and it aligned my partitions on 1MB boundaries.(In reply to comment #3)
Component: Installer => RPM PackagesCC: (none) => thierry.vignaudSeverity: normal => enhancementSource RPM: drakconf-12.33-2.mga3 => drakxtoolsPriority: Normal => Low
Whiteboard: 3beta2 => (none)Assignee: bugsquad => mageiatoolsSummary: diskdrake does not have a 'discard' option for ext4 file systems => diskdrake does not have a 'discard' option for ext4 file systems on SSD
I'm new to the SSD world, but looking at our documentation on the wiki and forum, it looks like the installer should be the first thing to recognize and handle SSDs correctly, by adding the discard option in fstab on the swap partition(s) and enabling fstrim.timer. Diskdrake should probably pick up on this too if you start adding partitions to a new secondary drive that happens to be an SSD.
Summary: diskdrake does not have a 'discard' option for ext4 file systems on SSD => diskdrake/installer does not have a 'discard' option or enable fstrim.timer for SSDsCC: (none) => mageiaComponent: RPM Packages => Installer
Everything I've read on this says that continuous trim (the discard option) is not recommended. From https://wiki.archlinux.org/index.php/Solid_state_drive: "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. In such case, depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM." and "Note: Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default, Debian does not recommend using continuous TRIM and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible." Fedora have enabled the fstrim.timer by default in Fedora 32 (https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer) and I think we should do the same. This just requires a simple change in the mageia-release package. The only debatable point is whether we should enable it on upgrade.
(In reply to Martin Whitaker from comment #6) > Everything I've read on this says that continuous trim (the discard option) > is not recommended. That's also what the Mageia docs I referenced said, hence only "discard" on the swap partition and not the others, and fstrim.timer enabled to take care of the filesystem ones. I agree we shouldn't do "discard" for ext4/filesystem partitions as Comment 0 suggested. Does it hurt anything to enable fstrim.timer on machines with no SSDs? If we don't enable it everywhere, we should both in the installer, as well as diskdrake and harddrake (the thing that runs at boot and detects hw changes) if an SSD is added.
> That's also what the Mageia docs I referenced said, hence only "discard" on > the swap partition and not the others, and fstrim.timer enabled to take care > of the filesystem ones. I agree we shouldn't do "discard" for > ext4/filesystem partitions as Comment 0 suggested. I've not found any strong arguments for or against enabling it on the swap partition, so I'd be inclined to leave well alone. > Does it hurt anything to enable fstrim.timer on machines with no SSDs? Fedora think not - see link above. Ubuntu and openSUSE enable it by default too.
OK enabling fstrim.timer by default seems simple enough. That would be in the util-linux package. Swap does not have a filesystem, so fstrim will not work on it, hence it needs the discard option.