Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Discard vs fstrim : reliability

  1. #1
    Join Date
    Jun 2016
    Location
    Ireland
    Posts
    246

    Default Discard vs fstrim : reliability

    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
    Code:
    UUID=f3eb9bf2-ffd2-48e1-bd47-4388184d4303    /    ext4    defaults,errors=remount-ro,discard,noatime,commit=10        1 1
    UUID=0A3E-974F          /boot/efi    vfat     umask=0077,shortname=winnt    0 0
    UUID=7599302a-37c3-4e9e-9b29-415e2ceae2e4    /home    ext4    defaults,discard,noatime,commit=10,data=writeback        1 2
    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
    Code:
    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?

    This is a known issue last year:
    https://serverfault.com/questions/82...discard-doesnt

    Thanks for your help

  2. #2
    Join Date
    Jun 2016
    Location
    Ireland
    Posts
    246

    Default Re: Discard vs fstrim : reliability

    I found an answer to my question.
    https://unix.stackexchange.com/quest...ed-with/109817
    1. 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).
    2. 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

  3. #3
    Join Date
    Jun 2016
    Location
    Ireland
    Posts
    246

    Default Re: Discard vs fstrim : reliability

    I am not so sure I'll keep discard as I read this:
    https://sites.google.com/site/easyli...sd-in-opensuse
    Automatic TRIM: by boot.local, by cron or by discard
    Preferred method: by boot.local

    Not advised: by discard
    So what is your opinion?
    If boot.local is your preferred, is the explained method in the link good or have you another way to do it?

  4. #4
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    20,925
    Blog Entries
    14

    Default Re: Discard vs fstrim : reliability

    Quote Originally Posted by MrNice View Post
    I am not so sure I'll keep discard as I read this:
    https://sites.google.com/site/easyli...sd-in-opensuse

    So what is your opinion?
    If boot.local is your preferred, is the explained method in the link good or have you another way to do it?
    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:
    Code:
    # 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.
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  5. #5
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,271

    Default Re: Discard vs fstrim : reliability

    Quote Originally Posted by MrNice View Post
    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
    Code:
    UUID=f3eb9bf2-ffd2-48e1-bd47-4388184d4303    /    ext4    defaults,errors=remount-ro,discard,noatime,commit=10        1 1
    UUID=0A3E-974F          /boot/efi    vfat     umask=0077,shortname=winnt    0 0
    UUID=7599302a-37c3-4e9e-9b29-415e2ceae2e4    /home    ext4    defaults,discard,noatime,commit=10,data=writeback        1 2
    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
    Code:
    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?

    This is a known issue last year:
    https://serverfault.com/questions/82...discard-doesnt

    Thanks for your help
    I am using since ever:

    Code:
    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:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  6. #6
    Join Date
    Jun 2016
    Location
    Ireland
    Posts
    246

    Default Re: Discard vs fstrim : reliability

    Thanks Knurpht,
    I'd guess the 2 following links are official.
    https://en.opensuse.org/SDB:SSD_disc...iscard_support
    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.
    https://en.opensuse.org/SDB:SSD_performance#TRIM
    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?

    Thanks

  7. #7
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,271

    Default Re: Discard vs fstrim : reliability

    Quote Originally Posted by MrNice View Post
    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:

    Code:
    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:

    Code:
    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.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  8. #8
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    20,925
    Blog Entries
    14

    Default Re: Discard vs fstrim : reliability

    Quote Originally Posted by MrNice View Post
    Thanks Knurpht,
    I'd guess the 2 following links are official.
    https://en.opensuse.org/SDB:SSD_disc...iscard_support


    https://en.opensuse.org/SDB:SSD_performance#TRIM


    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?

    Thanks
    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.
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  9. #9
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,271

    Default Re: Discard vs fstrim : reliability

    Quote Originally Posted by Knurpht View Post
    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.
    See https://wiki.archlinux.org/index.php...ontinuous_TRIM

    With the NVMe I noticed some degradation during 16 months of operation:

    Code:
    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.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  10. #10
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Discard vs fstrim : reliability

    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.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •