SSD TRIM : discard n'est pas pris en compte

Support Debian
#2

Ça va me rendre chèvre… Le discard apparaît enfin dans les drapeaux !

$ mount [...] /dev/disk/by-uuid/23f9f7a6-4b84-11e1-9585-00248c13477c on / type ext4 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=writeback,discard)

J’ai simplement remis ma config comme à l’origine :017 (cette config ne marchait pas il y a quelques heures, je ne sais pas quelle est la différence car il y en a forcément une) :

$ cat /etc/default/grub [...] GRUB_CMDLINE_LINUX_DEFAULT="quiet"

# tune2fs -l /dev/sda1 | grep 'Default mount' Default mount options: journal_data_writeback
Le fstab n’a pas changé d’un iota :

[code]$ cat /etc/fstab
[…]

/dev/sda1

UUID=23f9f7a6-4b84-11e1-9585-00248c13477c / ext4 defaults,noatime,discard,user_xattr,acl,barrier=1,data=writeback,errors=remount-ro 0 1[/code]

Le TRIM automatique ne fonctionne toujours pas, que ce soit en démarrage normal ou recovery (mais il fonctionne toujours à partir d’un LiveCD).
Par contre la commande fstrim / fonctionne en mode recovery mais pas en démarrage normal. :angry-banghead:

J’en perds mon latin, c’est signe qu’il faut aller dormir. :013

Edit : Pour fstrim j’ai compris le truc ! Il ne semble marcher qu’une fois par cycle de reboot. Et comme je passais du recovery au démarrage normal à l’aide d’un simple “exit”… :108
Là je viens de tester (inspiration soudaine), en faisant un reboot directement en mode normal le fstrim fonctionne… Une fois.
Ça ne résout pas le problème du TRIM automatique mais je peux au moins récupérer mes blocs à chaque démarrage de la machine, c’est toujours mieux que rien. Je vais laisser tourner la machine et voir s’il se relance demain matin, ou s’il faut encore rebooter pour réinitialiser je ne sais quoi.

#3

Après avoir visité une bonne moitié de l’internet, j’ai enfin fini par trouver la cause (et la solution). Le TRIM automatique MARCHE ! :041 :dance:

J’ai remarqué qu’une différence entre ma machine et le LiveCD était que sur le Live, le disque était monté en data=ordered au lieu de data=writeback (et ce malgré la présence du drapeau journal_data_writeback dans les options par défaut du filesystem, y’a encore des trucs qui me dépassent là).

Pour une raison expliquée dans cette discussion : thread.gmane.org/gmane.comp.file … ext4/18431
… il s’avère que le mode de journal writeback empêche le TRIM automatique de fonctionner correctement : seules les metadata sont TRIMées mais pas les données elles-mêmes (selon Eric Sandeen, développeur RedHat pour divers filesystems, c’est un bug dans l’ext4… et il date quand même d’avril 2010). Il faut repasser en ordered. Ça m’apprendra à toucher à des trucs exotiques.

Ma config actuelle :

[code]$ cat /etc/fstab
[…]

/dev/sda1

UUID=23f9f7a6-4b84-11e1-9585-00248c13477c / ext4 defaults,noatime,discard,user_xattr,acl,barrier=1,data=ordered,errors=remount-ro 0 1[/code]

$ mount [...] /dev/disk/by-uuid/23f9f7a6-4b84-11e1-9585-00248c13477c on / type ext4 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered,discard)

# tune2fs -l /dev/sda1 | grep 'Default mount' Default mount options: journal_data_ordered

Vérifions :

[code]# dd if=/dev/urandom of=tempfile bs=512 count=2 ; sync ; hdparm --fibmap tempfile
2+0 enregistrements lus
2+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,00066616 s, 1,5 MB/s

tempfile:
filesystem blocksize 4096, begins at LBA 4096; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 347728 347735 8

hdparm --read-sector 347728 /dev/sda ; rm tempfile ; sync ; hdparm --read-sector 347728 /dev/sda

/dev/sda:
reading sector 347728: succeeded
6b8c 5070 b453 d929 faf4 7ed7 92ac 5847
[…]

/dev/sda:
reading sector 347728: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
[…][/code]

Je ne sais toujours pas pourquoi le discard ne voulait pas apparaître dans les drapeaux de montage, j’avais dû faire un truc de travers que j’ai probablement corrigé sans m’en rendre compte (vu l’heure qu’il était hier soir ça ne m’étonne pas plus que ça). :108
Quant au fstrim, malgré avoir laissé la bécane tourner cette nuit il ne voulait pas refonctionner ce matin avant que je reboot. Je vais attendre plus longtemps entre deux invocations, voir s’il se réinitialise tout seul, mais j’ai bien l’impression que la piste du “une seule fois entre deux reboots” est la bonne. Je vous tiendrai au courant si je constate le contraire.

#4

Très intéressant en tout cas, merci pour ces recherches.

#5

oui je suis tres interesser par t on acharnements et tes recherche car, j ai aussi un ssd que j utilise en ext4 donc je suis egalement dans le meme cas que toi :023

#6

Acharné ? Moi ? :whistle: :smiley:
Content en tous cas que mes pérégrinations puissent servir à quelqu’un. :wink:

Et pour ceux qui se poseraient la question, du haut de ma journée d’utilisation je ne peux que conseiller l’usage de SSD (a minima pour le système), les gains de vitesse sont proprement époustouflants. Je vais attendre un peu voir ce que ça donne, mais il y a de fortes chances que je remette ça au moins pour mon netbook.

#7

je vien de voir que le noyau mini pour une bonne utilisation d un ssd est le 2.6.36 ? :005
c est raper pour moi pour le moment je reste avec le 2.6.32 :013
et au niveau de la batterie du portable le gains en autonomie est de 5h au lieu de 2h30 :041

#8

Tu peux très bien passer sur le noyau des backports tout en restant en Squeeze, pas de souci.
Le TRIM est quand même important pour diminuer le phénomène de “write amplification” qui réduit pas mal la durée de vie du disque, ça vaut le coup de changer de kernel (et accessoirement ça améliore les performances, mais sur un SSD je suis pas certain que ça soit très visible, en tous cas quand on est habitué à un disque plateau :mrgreen:).

#9

c est pas faut,
mais, je vais me battre avec la carte video ATI :006
c est pourquoi je suis revenu sur ce noyau en attendant wheezy

oui sa ce voie sur frugalware stable, l ordi demare en 2 s, avec squeeze 5 s :023
sur sid je ne sais plus.

c est pourquoi je m interesse a tes recherche :023

#10

Bah si t’as réussi à l’installer sur un noyau 2.6.32 y’a pas de raison que ça marche pas sur un plus récent.
Au pire si t’as peur de casser quelque chose, fais une image CloneZilla de ton disque avant, mais je trouve ça dommage de réduire volontairement la durée de vie de ton disque (surtout au prix où ils sont) juste pour éviter d’avoir à réinstaller un pilote.
Enfin c’est toi qui vois hein, mais apparemment le TRIM fait une grosse différence sur la durée de vie.

C’est pas comparable, les conditions ne sont pas du tout identiques (ou alors on compare avec ma Debian qui démarre en 20 secondes avec TRIM ; comme la tienne ne met que 5 secondes j’en conclus, sans tenir compte des services en plus ou en moins, que c’est plus performant sans TRIM… tu vois ce que je veux dire ? :wink:). En plus le démarrage de l’ordi n’écrit pas tant que ça sur le disque, c’est quasiment que de la lecture donc c’est loin d’être le meilleur test pour mesurer l’impact du TRIM.
Un meilleur test serait de chronométrer dans les mêmes conditions (sur ta frugalware donc) en changeant juste un seul paramètre (le support du TRIM), mais sur des tests d’écriture aléatoire de 4KB (c’est surtout là-dessus que joue le TRIM : les petits fichiers).

#11

oui ca marche sans probleme j usqu a ce que je touche au fichier preference et la c est le drame :005

tu a beaucoup de service en activiter pour demarrer l ordi ? :017
je pensse pas que TRIM ralentisse autant le demarrage.

oui bien vue, je n ai pas fait de test de ce coter ci: :mrgreen:
et toi a tu fais le test ? :115

#12

tu a beaucoup de service en activiter pour demarrer l ordi ? :017
je pensse pas que TRIM ralentisse autant le demarrage.[/quote]
Justement c’est là où je voulais en venir : le TRIM n’influence absolument pas la lecture, le démarrage n’est quasiment que de la lecture, donc le TRIM n’influence quasiment pas le démarrage. :wink:
En conséquence de quoi la différence constatée entre tes deux distros ne vient pas du TRIM, mais des distros elles-mêmes. :wink:

Quant aux services que j’ai sur ma bécane… Déjà regarde ma signature, tu verras que c’est pas tout à fait LXDE. :mrgreen:
Rajoute à ça un Apache, un MySQL, quelques applis KDE qui se lancent au démarrage de la session, et le compte est bon. De plus, je suis en connexion automatique donc je compte le temps entre la fin du Grub et quand mon bureau est prêt à être utilisé (signal sonore de KDE), pas l’écran de connexion puisque j’en ai pas. :wink:

oui bien vue, je n ai pas fait de test de ce coter ci: :mrgreen:
et toi a tu fais le test ? :115[/quote]
Non, je fais confiance à ceux qui l’ont déjà fait, j’ai suffisamment de trucs à faire à côté. Je constate que mon PC est énormément plus rapide avec un SSD aussi bien en lecture qu’en écriture, ça me suffit amplement. :stuck_out_tongue:

#13

oui je l’ai bien compris dans ce sens la :023

c’est vrai et j’ai pas regarder ci le TRIM etait en fonction je supose que oui :laughing:

desoler je n’avais pas regarder :unamused:

oupss c’est pas tres securiser en auto :018

oui alors les quelque secondes que tu a actuelement sur un ssd, ce transformerais vite en quelque minutes sur un disque conventionnel :023
le TRIM ne servant qu a proteger le ssd de l’ecriture, je comprend tous a fais t’on atachement a vouloir le voir fonctionner corectement. :023
et je te suis dans ta logique. :006
mais une questions me vient a l’espris, quand vont ils corriger ce bug sur l ext4 :115

#14

oupss c’est pas tres securiser en auto :018 [/quote]
Si quelqu’un a un accès physique à ma machine, je suis foutu de toutes façons (sauf à chiffrer tous les disques, un jour peut-être je me déciderai à le faire… mais du coup je sais pas comment le TRIM se comporte avec une couche dm_crypt/LVM entre le filesystem et le disque). Je préfère protéger mes données importantes au coup par coup (GPG, pareil faudrait probablement que je passe à ecryptfs ça serait plus pratique d’utilisation :mrgreen:).
Par contre mon netbook que je trimballe partout est correctement sécurisé, lui (dm_crypt, mots de passe partout). :wink:

1’20" exactement pour le boot.

Vu qu’il date de 2010, je dirais que c’est pas une priorité pour eux… :frowning:
Dommage, car du data_writeback c’est très bien sur la partition / où il y a finalement assez peu d’écritures : sur un disque plateau ça accélère beaucoup les rares écritures (seules les metadata sont journalisées, en cas de catastrophe il y a quelques pertes de données pour les écritures qui étaient en cours mais le FS reste intègre, je trouve que c’est un bon compromis) et sur un SSD ça augmente d’autant la durée de vie.

#15

bon bein il ne reste plus qu a attendre le nouveau type de fichier systeme qui sera optimiser pour les SSD.
Je n ai pas essayer BTRFS voir ce que ca donne en a tu fais l essai ? :118
et ci oui avec TRIM ce que ca change ou pas. :038

#16

Aux dernières nouvelles BTRFS = encore buggé, pas prêt du tout pour de la prod (ni pour de l’utilisation desktop, à moins de faire des sauvegardes très régulières). Va falloir patienter. :wink:

#17

bon bein je vais attendre que tous les problemes soie regler :12

#18

Bonjour à tous !

Tu es sur de toi syam ?
Même sur la dernière debian squeeze avec maj avec le dernier kernel ?

Ca m’ennuie ça !
Je suis en plein construction d’un NAS avec 6 Dur de 2 tera en Raid5
et j’étais partit pour du btrfs…

Du coup ca va se finir en ext4 cette histoire, à moins d’une autre suggestion ?

tcho

#19

[quote=“Giants”]Tu es sur de toi syam ?
Même sur la dernière debian squeeze avec maj avec le dernier kernel ?[/quote]

phoronix.com/scan.php?page=n … &px=OTc2OA

En résumé : Btrfs ne deviendra le filesystem par défaut que sur Fedora 17 (kernel 3.3), et pas avant la 12.10 d’Ubuntu. Si ces deux distros “bleeding edge” ont autant repoussé l’utilisation de Btrfs malgré ses avantages indéniables c’est qu’il y a une bonne raison. En tout cas ça n’est pas vraiment raisonnable de l’utiliser sur une Squeeze avec son kernel 2.6.32 qui date d’il y a presque 2 ans 1/2.

#20

Merchi m’sieur !

Suivant cette article, qui date
wiki.linuxwall.info/doku.php/fr: … cc6954ecca

J’ai préféré le XFS au ext4 (pour l’instant)

Ce qui donnes au final niveau perf (avec des dur de 2Tera en sata III mais connecté sur interface Sata2) 7200tr/mn

en XFS donc
Timing cached reads: 12400 MB in 2.00 seconds = 6204.27 MB/sec
Timing buffered disk reads: 502 MB in 3.01 seconds = 166.94 MB/sec

/dev/sde1:
Timing cached reads: 12460 MB in 2.00 seconds = 6234.60 MB/sec
Timing buffered disk reads: 572 MB in 3.00 seconds = 190.65 MB/sec

/dev/sdd1:
Timing cached reads: 12550 MB in 2.00 seconds = 6279.17 MB/sec
Timing buffered disk reads: 460 MB in 3.00 seconds = 153.22 MB/sec

/dev/sdc1:
Timing cached reads: 12574 MB in 2.00 seconds = 6291.23 MB/sec
Timing buffered disk reads: 422 MB in 3.01 seconds = 140.25 MB/sec

/dev/sdb1:
Timing cached reads: 12484 MB in 2.00 seconds = 6246.05 MB/sec
Timing buffered disk reads: 420 MB in 3.01 seconds = 139.74 MB/sec

/dev/sda1:
Timing cached reads: 12486 MB in 2.00 seconds = 6247.77 MB/sec
Timing buffered disk reads: 468 MB in 3.00 seconds = 155.96 MB/sec

/dev/md0:
Timing cached reads: 12690 MB in 2.00 seconds = 6350.12 MB/sec
Timing buffered disk reads: 1118 MB in 3.00 seconds = 372.61 MB/sec

dd if=/dev/zero of=bigfile count=512K bs=64K

524288+0 enregistrements lus
524288+0 enregistrements écrits
34359738368 octets (34 GB) copiés, 155,686 s, 221 MB/s

et en ext4 ca nous donnes

/dev/md0:
Timing cached reads: 12302 MB in 2.00 seconds = 6155.27 MB/sec
Timing buffered disk reads: 604 MB in 3.00 seconds = 201.21 MB/sec

524288+0 enregistrements lus
524288+0 enregistrements écrits
34359738368 octets (34 GB) copiés, 162,945 s, 211 MB/s

Alors comme ça, brut de force, il semblerait que le xfs soit un chouille plus rapide
Mais au niveau sécurité des données, récupération si corruption, je suis pas sur
Qu’il soit aussi bien que ext4

Bref…
D’après vous, ca faut le coup de rester en XFS ou je passe en ext4
En 2012, je pense que le ext4 est stable et performant, maintenant plus que le xfs… alors la

Le but etant pour un NAS avec potentielement des gros fichiers (16 Giga max)
Tous avis est le bien venus.
Je suis assez novice sur le sujet :slightly_smiling:

#21

Je pense que tu devrais rester sur du standard (ext4) qui ne pose aucun problème. :smiley: