Hi there,
I am in the way to migrate from Fedora to OpenSuse Leap 42.3 for my home desktop
So far I have a Samsung SSD 830 120GB and I’ll install the new Leap 42.3 on a Samsung SSD 850 250GB
On Fedora I have /etc/fstab
Note “discard”.
AFAIK discard should activate a “wipe” just after a file deletion.
I switched on my desktop and worked around 2 hours. Then I did in a terminal
su -c 'fstrim --verbose --all'
Password:
/home: 65.7 GiB (70535979008 bytes) trimmed
/: 5.3 GiB (5728993280 bytes) trimmed
su -c 'fstrim --verbose --all'
Password:
/home: 0 B (0 bytes) trimmed
/: 0 B (0 bytes) trimmed
I understand I am running Fedora however, have you the same issue in Leap 42.3 ?
If you have a similar config, could you try fstrim?
fstrim trims all the data that is unallocated in the filesystem (well, not really all the data, only the data blocks that are not allocated, I don’t think the unused parts of the inode table or the parts of not-completely used blocks are trimmed), regardless of whether discard is in used or not. fstrim cannot know which of those unallocated blocks have been “trimmed” or not already in the past, but it (actually the kernel, all the fstrim work is done in the FITRIM ioctl) does however keep track of which block group
have been trimmed and will not trim them again if there hasn’t been any unallocation in that block group since then, unless you’re requesting a FITRIM with a smaller minimum extent length (from checking the ext4 code, it may be different for other file systems) which explains why you get 0 on the next run.> Note that it doesn’t harm to trim a block that has already been trimmed. That’s just telling the SSD again that it can do whatever it wants with it (like erase it so it can be ready to use again for something else).
In df output, the “available” value doesn’t take into account the space that is “reserved” for root, you’ll notice that 206 - 76 is 130G, not 118G. 12G (about 5%) are reserved. See tunefs -m to change how much is reserved.
Ok, yes the kernel must track what has been trimmed since boot. If I reboot and do another fstrim, I get roughly the same output.
So sorry to disturb you, I’ll keep discard in fstab
My opinion is that these third party tips websites should not be used at all. There is no need to tweak the defaults. Next to that, these sites (almost) never provide support when things don’t work out the way one expects.
On openSUSE one sees this:
# systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Fri 2017-12-15 03:49:04 CET; 10h ago
Trigger: Mon 2017-12-18 00:00:00 CET; 2 days left
Docs: man:fstrim
dec 15 03:49:04 knurpht-HP systemd[1]: Started Discard unused blocks once a week.
FWIW: I’ve been using SSD’s for almost as long as they exist, and always left fstab settings / fstrim settings at defaults, never had any issues.
erlangen:~ # cat /etc/fstab
UUID=8b190950-c141-4351-9198-7a9592b4fb34 / ext4 noatime,acl 1 1
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08 /home ext4 noatime,acl 1 2
UUID=f5177cae-4082-44ed-9471-b99030f06866 /home-HDD ext4 noatime,acl 0 0
UUID=dbc33c75-0fbb-4619-add6-d204ecf63a43 /Leap-42.3 ext4 ro,noatime,acl 0 0
UUID=aa065695-b637-4d5d-bb2a-4ad459c9556a swap swap defaults 0 0
erlangen:~ # systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sat 2017-12-16 00:00:00 CET 9h left Fri 2017-12-15 05:15:11 CET 9h ago logrotate.timer logrotate.service
Sat 2017-12-16 00:56:09 CET 10h left Thu 2017-12-14 16:02:31 CET 22h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2017-12-18 00:00:00 CET 2 days left Mon 2017-12-11 05:19:46 CET 4 days ago fstrim.timer fstrim.service
3 timers listed.
Pass --all to see loaded but inactive timers, too.
erlangen:~ #
As of 11.4, fstrim is part of the linux-util package and is the recommended choice for invoking trim for most users.
…
The kernels in openSUSE 11.2 and above support realtime discard. ie. As files are deleted the underlying data blocks are discarded. These kernels support realtime discard for ext4 and xfs.
To use the kernel realtime discard feature, you must mount with the “mount -o discard” option.
To be noted, contrary to SSD, “discard” should not be applied to NVMe SSD,
From the 2 above links, I understand I should use “discard”. Are these wiki out of date?
Thanks karlmistelberger
I understand you use fstrim.service instead of discard. Is it installed directly by the system or did you install it after? Could you teach me how?
What are the purpose of the 2 other tasks? Are they SSD optimisation? How to install?
List the timers as shown above. Check status as follows:
erlangen:~ # systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Thu 2017-12-14 15:48:01 CET; 24h ago
Trigger: Mon 2017-12-18 00:00:00 CET; 2 days left
Docs: man:fstrim
Dec 14 15:48:01 erlangen systemd[1]: Started Discard unused blocks once a week.
erlangen:~ #
You may test fstrim:
erlangen:~ # systemctl start fstrim.service
erlangen:~ # journalctl -u fstrim.service
-- Logs begin at Tue 2017-01-31 14:09:48 CET, end at Fri 2017-12-15 16:42:52 CET. --
Dec 15 16:40:55 erlangen systemd[1]: Starting Discard unused blocks...
Dec 15 16:42:52 erlangen fstrim[22310]: /home: 249.5 GiB (267868966912 bytes) trimmed
Dec 15 16:42:52 erlangen fstrim[22310]: /: 16.9 GiB (18081558528 bytes) trimmed
Dec 15 16:42:52 erlangen systemd[1]: Started Discard unused blocks.
erlangen:~ #
You may want to enable log rotation and temp file cleaning as these tend to grow with time.
These entries indeed seem to need updating. AFAICS Karl uses the defaults, What I don’t understand ( we’ve seen more threads on this subject ) is that users don’t trust the defaults the distro comes with, and start adding options and configs that are already there. There simply is no need for SSD optimisation, what’s necessary is already there.
With the NVMe I noticed some degradation during 16 months of operation:
SMART/Health Information (NVMe Log 0x02, NSID 0x1)
Critical Warning: 0x00
Temperature: 34 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 8,135,611 [4.16 TB]
Data Units Written: 8,326,092 [4.26 TB]
Host Read Commands: 83,249,444
Host Write Commands: 136,595,520
Controller Busy Time: 919
Power Cycles: 545
Power On Hours: 4,504
Unsafe Shutdowns: 35
Media and Data Integrity Errors: 0
Error Information Log Entries: 283
Upgrading the firmware restored buffered disk reads (hdparm -tT) to its original value.
IMO the Arch Linux Wiki reference is good, in fact all the Arch Linux Wiki articles seem to be maintained and updated well.
IMO there are pros and cons of manual (or periodic) TRIM commands (eg by cron) vs “continuous” are simple…
If you want background maintenance regardless of disk activity, then implement “discard” in your fstab.
On the other hand, if you are disturbed by background disk activity in the middle of work, then activate TRIM in a way that works for you, on bootup, manual command or cron.
So, there probably isn’t a solution that fits everybody but everybody can make a decision that best fits their habits or requirements.
Whatever decision you make, the objective is to clear those memory traps so that they are available when you need them, the worst situation is if those traps have to be cleared on demand making you wait.
Quiet Penguins and not skilled as I am can trust the defaults the distro come with but as you said some entries need to be updated, so it’s why I had to start this thread. Luckily you are here and I thank you all for that!
BTW, I think the wiki should have 2 parts for general config; one for home computer and the other for server/pro usage. For example: AFAIK, acl is an admin utility. I’ll never use it at home in my personal only user box and this option is on as default. I’d guess I can remove it without any problem. In the other hand, maybe it doesn’t add any load.
@Karl,
For my personal box usage, all partitions ext4 fs, I was thinking to move some /var dir to tmpfs RAM (I have 8GB RAM)
Monitor I/O with ‘iotop -aoP’. Run it for one day if shorter runs are inconclusive. Older versions of Firefox and some KMail accounts caused heavy writes to SSD. /var never has been a problem.
Enable default timers and check proper operation.
To my experience always use defaults. Never make changes that might be useful. Use other recommendations only if needed and if strong evidence for the claims made is available. Keep track of the changes made.