Avis SSD vs CarteSD

Support Debian
#1

Bonjour,

J’ai un PC multimedia relié à ma TV (un ZBOX ID41 de chez Zotac) qui a l’avantage du faible encombrement mais le gros inconvénient de ne pas être très évolutif, je suis dans l’impossibilité de lui mettre deux périphériques en SATA en interne.
Hors j’aurais aimé migrer sur du SSD pour gagner en rapidité (ne serait-ce que pour le démarrage).

Actuellement je suis limité en vitesse pas mon HDD: Toshiba MK5056GSY (7200 RPM) connécté en SATAII

[quote]Performance

Seek Time
11 ms (average) / 19 ms (max)
Drive Transfer Rate
300 MBps (external)
Spindle Speed
7200 rpm
Track-to-Track Seek Time
1 ms

>>source[/quote]

Je vois deux solutions mais peut-être en voyez vous plus:
[Solution 1] Est-ce que je gagnerai en rapidité si j’installai ma debian sur une carte mémoire ?
J’ai un port qui permet d’insérer: Memory Stick PRO, Multimedia Card, SD (Secure Digital), SDHC (Secure Digital High Capacity), xD-Picture Card, si oui laquelle choisir ?

[Solution 2]J’ai aussi un port eSATA en externe, d’aprés mes recherches c’est aussi rapide que le SATA donc j’ai aussi la possibilité de mettre un SSD en interne puis de mettre le HDD actuel dans un boitier externe. Cette solution ne m’intérresse que si le port permet d’alimenter le boitier externe.

La solution 1 a ma préférence car ça m’évite d’avoir un boitier externe en plus à caser derrière la TV mais je lirais attentivement vos remarques. J’ai surtout besoin de vos avis sur le débit de l’une et l’autre des solutions. Je n’arrive pas à comparer les performances (Les perfs du SSD pour la solution2)

#2

Tu peux éventuellement passé le système Debian sur une carte SD mais attention au débit en écriture qui sont misérable comparé à un SSD correct.

Par contre là ou tu serais tranquille c’est avec un NAS correct et passer ton système sur du SSD car je ne sais pas trop ce que vaux dans le temps un système sur une carte SD avec de l’écriture régulière dessus (àmoins encore une fois de déporter tous ce qui est log et tmp ailleurs.

#3

L’interface eSATA ne fournit pas d’alimentation, c’est son gros inconvénient par rapport à l’USB ou au Firewire. Il existe des ports combinés eSATA+USB qui peuvent fournir une alimentation par l’USB, mais encore faut-il disposer du câble qui va bien et que le disque eSATA se contente de ce que peut fournir un port USB (5V 0,5A).

Comme déjà dit, une carte SD n’offre pas les mêmes performances qu’un SSD, et pas seulement en écriture. Ils n’ont pas le même usage. Même parmi les cartes SD, il existe différents “niveaux” (je ne me rappelle pas le terme exact) avec des débits plus ou moins élevés. Je peux témoigner qu’un système Debian installé sur une carte SD de base a un rapidité abysmale. Je pense qu’un SSD en USB 2.0 serait bien meilleur.

#4

Bonjour,

Merci pour vos retours, j’installe sur un SSD :slight_smile:

A priori le port eSATA n’est pas alimenté, je vais donc utiliser un port USB3 pour le HDD, je verrais à l’usage si le débit en lecture est suffisant.

Sur mon PC de bureau (qui a un petit SSD aussi) j’ai en effet mis ces point de montage sur un HDD (je n’y connais pas grand chose en usure de SSD mais j’ai en effet à plusieurs reprise noté cet avertissement)
Mais dans ce cas, j’avoue que je ne suis pas tés confiant à l’idée de monter ces partitions sur un HDD connecté en USB3, à tort d’après vous ?

#5

Il fallait dire que la machine avait un port USB 3 ! Contrairement à l’USB 2, le débit de l’USB 3 SuperSpeed est suffisant pour ne pas brider n’importe quel disque dur.

Concernant l’usure prématurée des SSD, ce qu’on disait est de moins en moins vrai avec les modèles récents. Je pense que déporter /tmp, les logs ou le swap hors du SSD ne se justifie pas car ils ne sont pas si sollicités en écriture et effectivement je pense aussi que les mettre sur un disque externe USB est une mauvaise idée. /tmp peut être mis en mémoire (tmpfs), ce sera encore plus rapide.

#6

Je me corrige décidément j’ai de gros doigts, il fallait lire carte SD et non carte SSD, comme expliqué par Pascal même avec des classe 10 (recommandé au minimum pour des raspberry ou autre devboard) les débits flotte pour atteindre le waouh 30 à40 Mo/s pour les meilleurs sur ces cartes.
A côté de ça des module eMMC avec du presque 170Mo/s sont nettement plus intéressant pour mettre un système léger.
Dans le cas d’un port USB3 fonce sur du SSD, pourquoi pas en msata afin de réussir à l’intégrer de façon pas trop dégueu sur la box ?

#7

J’ai profité des journées de mauvais temps pendant mes vacances pour mettre ça en place.

C’est top, ça tourne du feu de dieu.

Le seul bémol: j’ai paramétré tout ça (debian testing) avec mon ancien disque dans un boitier usb3 (pour récupérer les fichiers de conf etc…) j’accédai bien à toutes les partitions.
J’ai ensuite fait une seule partition ext4 sur ce disque (viré les autres partitions et agrandie la seule que j’utilisai).
Ensuite j’ai fait pas mal de MAJ dont une changeant le noyau.

Depuis impossible de lire le disque sur un port USB3 … pas de problème en USB2

J’ai vu que je n’était pas le seul en cherchant une solution sur le net, j’ai essayé les divers bidouilles trouvées mais sans succès, j’ai laissé tombé en croisant les doigts pour que la prochaine version du noyau corrige mon problème

#8

Si tu cherches un device en mode bloc qui n’apparaît plus ou pas sous le même nom, tu peux tenter d’analyser le retour des commandes suivantes :

lsscsi

sudo blkid -o list

ls -l /sys/dev/block

S’il s’agit d’avoir un stockage rapide, un SSD branché en eSATA est de loin le plus rapide que tu puisses faire. Les SSD prévus pour se brancher en SATA sont dans leur majorité prévus pour s’approcher des 600 Mio (mégaoctets ) par seconde que le SATA3 autorise.

S’il s’agit d’économiser la durée de vie d’un SSD, c’est sujet relativement complexe sur lequel on pourrait passer des heures. Néanmoins, pour résumer, sauf si on écrit pas sur le SSD parce-qu’il est monté en lecture seule ou utilisation d’un ramdisk qui se synchronise à l’arrêt du système :

  • Le SSD doit supporter les commandes TRIM (pour le SATA) ou DISCARD (pour le SCSI). Il n’y a pas d’autre solution vis à vis de la mémoire type NAND.

  • L’interface sur laquelle le SSD est raccordé doit permettre l’utilisation de TRIM ou DISCARD. L’USB ne sait pas le faire sauf utilisation de l’ATA Pass Through ou de UASP en remplacement de BOT - trim ATA pass through, UASP ETC.

  • Le SSD doit implémenter du “wear leveling” ou le système de fichiers utilisé sur le SSD doit être de type Copy On Write (COW).
    Les SSD dits “industriels” intègrent généralement du wear leveling mais pas les SSD “grand public” et les SSD industriels coûtent au minimum 3x le prix du “grand public”.
    Sur un Linux récent, on peut utiliser btrfs qui est un système de fichiers COW et qui possèdes des optimisations pour utilisation sur un SSD.

  • Un système de fichiers de type COW sur un SSD ne doit pas être rempli au-delà de 85% (valeur que je sors de mon chapeau magique). Sans cela les (ré)écritures se feront toujours sur un nombre restreint de blocs qui verront donc leur durée de vie diminuer dramatiquement.

–
AnonymousCoward

#9

Pour les options du fs, en plus de discard, pense à noatime et nodiratime qui réduisent les écritures et ainsi préservent ton ssd. Normalement noatime implique nodiratime mais je mets les 2 quand même. Attention ces 3 paramètres ne sont pas pris en compte par tous les fs, ext4 oui et 2/3 autres seulement de mémoire