Een externe USB SSD schijf: trimmen?

[vanadium]

Ik heb mijn eerste externe USB SSD harde schijf(je), een Samsung T5. Nu weten we dat Ubuntu standaard ingesteld is om wekelijks een interne harde SSD schijf te trimmen, maar hoe gaat dat in zijn werk met USB SSD schijven? Wordt deze ook automatisch getrimd? Of is dat niet nodig?

[Ronaldus]

Echt fantastische schijfjes; ik heb er twee van.  Eentje volledig versleuteld met VeraCrypt (exFAT) en eentje met Ext4 versleuteld. (Een gebruik ik in W10 én Ubuntu, de ander alleen met Ubuntu.)

Zie: https://www.tomshardware.com/reviews/samsung-t5-portable-ssd,5163-3.html
Trim zou volgens opgave alleen werken met NTFS?

In die link:
Previous versions of the Samsung Portable SSD did not support TRIM. The new T5 products accept the command from the host through the UASP protocol. The feature doesn’t work with the native exFAT file system that provides compatibility with Android and other devices. You will need to format the Portable SSD T5 with the NTFS file system for TRIM to work.

Af fabriek is die echter met exFAT geformatteerd.

Als het zou werken, zou 'sudo fstrim -av' toch moeten werken? Hij geeft dan echter niet op dat hij iets met de T5 heeft gedaan. Van enig snelheidsverlies heb ik echter ook nog nooit iets gemerkt. Schijf was snel en blijft snel.

Zo ziet die er van binnen uit: https://www.digit.in/reviews/storage/samsung-t5-ssd-review-125197.html

[vanadium]

Bedankt voor de intessante link! Voor mij was het schijfje inderdaad verrassend compact, en het kleine, in verhouding tamelijk zware bakje geeft een oersolide indruk.

Het lijkt me inderdaad dat er bij linux handwerk nodig is om het schijfje te kunnen trimmen. Ik heb hier een mooi artikel gevonden, dat aangeeft hoe je een "udev" regel kan aanmaken, die ervoor zorgt dat de schijf bij het aankoppelen automatisch als een "trimbare" schijf wordt beschouwd. Daarna kan je dan - handmatig - het fstrim commando gebruiken. Dit werkt inderdaad enkel met specifieke bestandssystemen, ntfs, maar ook met het linux bestandssysteem ext4.

[bart85]

Ik denk bestandssysteem op ext4 moet worden geformatteerd voor gebruik van de functie.
Met onderstaande kun je controleren wat er is getrimd en op welke datum:

Code: [Selecteer]

sudo systemctl status fstrim.service

[bart85]

Onderstaande vind ik op https://wiki.archlinux.org/index.php/Solid_state_drive
Het is een handleiding over SSD tuning in Arch Linux. Vergelijkbaar probleem.

Code: [Selecteer]

Several USB-to-SATA bridge chips (like VL715, VL716 etc.) and also USB-to-PCIe bridge chips (like the JMicron JMS583 used in external NVMe enclosures like IB-1817M-C31) support TRIM-like commands that can be sent through the USB Attached SCSI driver (named "uas" under Linux).

But the kernel may not automatically detect this capability, and therefore might not use it. Assuming your block device in question is /dev/sdX, you can find out whether that is the case by using the command

 sg_readcap -l /dev/sdX

If in its output you find a line stating "Logical block provisioning: lbpme=0" then you know that the kernel assumes the device does not support "Logical Block Provisioning Management" because the (LBPME) bit is not set.

[vanadium]

Lijkt me dusver dat Linux standaard daar niets voor voorziet. De argeloze gebruiker ziet de performantie gaandeweg achteruitgaan, en merkt dat toch niet meteen. De verwittigde gebruiker doet wat ingrepen en voert periodiek een handmatige fstrim uit.

[bart85]

In de documentatie staat dat het mogelijk is, maar de kernel het niet altijd automatisch detecteert.

To verify TRIM support, run:

$ lsblk --discard

And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.

Alternatively, install hdparm package and run:

# hdparm -I /dev/sda | grep TRIM

        *    Data Set Management TRIM supported (limit 1 block)

Dit is de controle voor support van trim op de USB SSD schijf. Werkt dat niet dan uit mijn vorige post de opdracht uitvoeren. Na die opdracht volgt nog een paar handelingen.

[vanadium]

Bedankt. Dat bevestigt wat ik hier al had aangegeven. Linux gaat daar blijkbaar niet automatisch mee om. Er is een manuele ingreep nodig om aan te geven dat de USB SSD schijf trimbaar is, en dan moet er manueel, of via een manueel opgezet automatisch proces, getrimd worden (zoals het trouwens ook is voor controle van het bestandssyysteem).

[Ronaldus]

In de link van Vanadium:

2. Create a udev rule

sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules

Enter this rule in the text editor:

ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0583", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Hoe krijg je eigenlijk deze actie weer ongedaan???
Gewoon weer 'sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules' en dan die regel weer verwijderen???

[bart85]

Ja.

Als je die regel gebruikt moet hem wel aanpassen met merk en type van het device wat je gebruikt. Dat is op te vragen met lsusb voor een USB device.

[Ronaldus]

Dank. (Dat had/heb ik ook gedaan.)

Als ik lsblk --discard invoer dan krijg ik de bijgevoegde output. Dat impliceert volgens mij dat TRIM ondersteund wordt?

Hoe voer ik die dan eenmalig (op afroep) uit? Met sudo fs trim -av pakt hij kennelijk alleen de 'sda'. (Waar momenteel niet veel te 'trimmen' valt.):

/boot/efi: 503,2 MiB (527630336 bytes) trimmed on /dev/sda1
/boot: 0 B (0 bytes) trimmed on /dev/sda2
/: 1,8 GiB (1956421632 bytes) trimmed on /dev/mapper/vgxubuntu-root

Kan je in '50-usb-ssd-trim.rule' meerdere regels toevoegen (meerdere SSD's in bezit)?

[bart85]

Het gaat om DISC-GRAN en DISC-MAX. Voor beide kolommen een waarde ongelijk aan 0 geeft ondersteuning voor trimmen op het device.

sudo fstrim /media/NAME-OF-MY-SSD

Je kunt bovenstaande proberen, maar waarschijnlijk krijg je een foutmelding. De kernelement het niet standaard ondersteund.

Your SSD reports to hdparm to support TRIM (hdparm -I = Request identification info directly from the drive).

TRIM however, is controlled by the drive controller.

It is quite likely that the USB3 harddiskcontroller of the external HDD closure doesn't support TRIM (most external controllers don't).

In that case you won't get any TRIM capabilities even if your SSD does support it.

Dit lees ik op een site.

[JorisC]

Een gewone HDD wat een mechanische schijf is kan getrimd worden . Een SSD is digitaal en trim je best niet om de levensduur niet te verkorten .

[Ronaldus]

Een gewone schijf trim je niet. Is ook niet nodig. Vrijgekomen ruimte kan direct na het weggooien van bestanden weer beschreven worden.

Een SSD moet juist wel getrimd worden, zodat de 'lege' cellen (waar eerder wat anders opstond) weer overschreven kan worden met andere data. (Lege cellen zijn eigenlijk alleen als leeg gemarkeerd.)

Dat kan vooraf gebeuren, zodat je op het moment als je weer wat wil schrijven de cel niet eerst leeg gemaakt hoeft te worden. De SSD blijft zo zijn snelheid behouden.
Kan ook pas gebeuren als je wat op de SSD wilt schrijven. Voor de schrijfactie uit moet dan eerst nog de cel geleegd worden, waarna de schrijfactie pas plaats kan vinden. Dat werkt vertragend. Een schijf die niet getrimd wordt, wordt gedurende de tijd dan ook steeds ietsje trager en dat is voor een SSD eigenlijk jammer.

Het probleem is dat het trimmen eigenlijk in beginsel bedoeld is voor interne schijven, maar je het ook zou willen hebben op een externe SSD. Op leesacties heeft het trimmen trouwens geen effect: die blijven snel.

https://www.digitalcitizen.life/simple-questions-what-trim-ssds-why-it-useful/

(NB.: Voorlopig zelf het bestandje '50-usb-ssd-trim.rules' maar even weer verwijderd, aangezien er hier kennelijk in ieder geval toch niets mee gebeurd. Ik laat voorlopig de externe schijven voorlopig wel 'ongetrimd'.)

[vanadium]

Gewoon weer 'sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules' en dan die regel weer verwijderen???

Dat bestandje is nieuw aangemaakt en bevat enkel je regel: ongedaan maken doe je dus door dat bestand weer te verwijderen.

Code: [Selecteer]

sudo rm /etc/udev/rules.d/50-usb-ssd-trim.rules

Je kan daar inderdaad meerdere SSD schijven toevoegen.

Inderdaad, dat het bij jou niet gaat, kan liggen aan de SSD. Je kan eens de partitie expliciet vermelden:

Code: [Selecteer]

sudo fstrim <koppelpunt van je SSD>
maar met de optie -a had hij hem inderdaad moeten meenemen.