Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26

Thread: migrating to an SSD

  1. #21
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,191

    Default Re: migrating to an SSD

    Has anyone noticed how many technical links there are to the Arch linux distro? I wonder why? I noticed MINT has topped out distrowatch, and OS is well above Arch... but that's just page hits, I think.

  2. #22
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: migrating to an SSD

    On 2015-08-30 19:36, PattiMichelle wrote:
    >
    > Hi Robin - I'm messing around with GRUB2-EFI (the bootloader on the disk


    Huh. I'm not very confident with grub2, and not at all with grub2-efi.
    I'm not the one to help with that one :-}

    --
    Cheers / Saludos,

    Carlos E. R.

    (from 13.1 x86_64 "Bottle" (Minas Tirith))

  3. #23
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,191

    Default Re: migrating to an SSD

    I just saw this... (https://en.wikipedia.org/wiki/TRIM#Shortcomings) This was dated 2015, so it looks like "Trim," and especially "Queued Trim," is not the way to go??


    • The non-queued nature of the command requires the driver to first wait for all outstanding commands to be finished, issue the trim command, then resume normal commands. Trim can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection cycle.[citation needed] This penalty can be minimized in solutions that periodically do a batched trim, rather than trimming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal.This Trim shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.[64][65]
    • Queued Trim commands have been linked to serious data corruption in several devices, most notably Micron's M500,[66] Crucial's M500,[66] and Samsung 8** series.[67] The data corruption has been confirmed for the Linux operating system on these devices as of July 1, 2015.[68]

  4. #24
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    31,278
    Blog Entries
    15

    Default Re: migrating to an SSD

    Quote Originally Posted by PattiMichelle View Post
    I just saw this... (https://en.wikipedia.org/wiki/TRIM#Shortcomings) This was dated 2015, so it looks like "Trim," and especially "Queued Trim," is not the way to go??


    • The non-queued nature of the command requires the driver to first wait for all outstanding commands to be finished, issue the trim command, then resume normal commands. Trim can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection cycle.[citation needed] This penalty can be minimized in solutions that periodically do a batched trim, rather than trimming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal.This Trim shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.[64][65]
    • Queued Trim commands have been linked to serious data corruption in several devices, most notably Micron's M500,[66] Crucial's M500,[66] and Samsung 8** series.[67] The data corruption has been confirmed for the Linux operating system on these devices as of July 1, 2015.[68]
    Hi
    FWIW, I have a Crucial M500 series (CT120M500SSD1) with MU05 firmware, this runs on SLES 12. The queued TRIM support is disabled, all is good with the defaults, just like on my Tumbleweed, SLED and Leap systems but have OCZ SSD's only. The only thing I do for tweaking is with the swappiness and setting the elevator to noop. If running an SSD and rotating you can do tweaking of the scheduler.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

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

    Default Re: migrating to an SSD

    Quote Originally Posted by PattiMichelle View Post
    I just saw this... (https://en.wikipedia.org/wiki/TRIM#Shortcomings) This was dated 2015, so it looks like "Trim," and especially "Queued Trim," is not the way to go??


    • The non-queued nature of the command requires the driver to first wait for all outstanding commands to be finished, issue the trim command, then resume normal commands. Trim can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection cycle.[citation needed] This penalty can be minimized in solutions that periodically do a batched trim, rather than trimming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal.This Trim shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.[64][65]
    • Queued Trim commands have been linked to serious data corruption in several devices, most notably Micron's M500,[66] Crucial's M500,[66] and Samsung 8** series.[67] The data corruption has been confirmed for the Linux operating system on these devices as of July 1, 2015.[68]
    For most people the above is irrelevant.

    Based on my read of the referenced link...
    - Today I don't know of any Linux implementation of a "queued TRIM command." if its existence still bothers you, you can disable it.
    - The most common implementation is the used of the "discard" command in the fstab. In the above reference, "discard" is one of the earliest methods to implement a TRIM command but is different than the newer ATA_TRIM command. The discard operation behaves as a batched task, not as queued.
    - Even if queued TRIM were somehow invoked, the scenario described could happen only if the machine was <extremely> busy, ie a Server serving a large number of simultaneous clients. Typical single User systems and servers which serve small networks experience plenty of no-demand interludes of idling... almost certainly more than enough time to allow any queued TRIM commands to execute without issue. Scheduling can make a big difference, but I've never observed a discard operation to take more than about 10 seconds, and that was very unusual.

    Of course, any evaluation of the potential impact and any risks associated with queued TRIM is affected by how much disk capacity is used, scheduling and workloads so it's impossible to state with total certainty that a problem couldn't happen.

    TSU

  6. #26
    Join Date
    Jun 2008
    Location
    Prescott, AZ
    Posts
    1,191

    Default Re: migrating to an SSD

    Thanks, Malcom - I think most of the improvement would just come from the lack of seek-time. But I guess "write amplification" can mess that up (unsure). I didn't even know about "elevator" - thanks for the tip! (I use VMs a lot.)

    Quote Originally Posted by malcolmlewis View Post
    Hi
    FWIW, I have a Crucial M500 series (CT120M500SSD1) with MU05 firmware, this runs on SLES 12. The queued TRIM support is disabled, all is good with the defaults, just like on my Tumbleweed, SLED and Leap systems but have OCZ SSD's only. The only thing I do for tweaking is with the swappiness and setting the elevator to noop. If running an SSD and rotating you can do tweaking of the scheduler.

Page 3 of 3 FirstFirst 123

Posting Permissions

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