Reprise du message précédent :

A la rigueur, sachant que parted s'en sort nickel, ce n'est pas un problème. Tu voyais un intérêt particulier à passer par cfdisk ?

Augmenter son nombre de posts sur hfr ?

oui, pouvoir faire ce partitionnement directement pendant l'install de ma slackware (oui je sais je suis fainéant)
 

OK, OK, c'était juste par curiosité

Bonjour à tous
 
Comme j'ai pas -encore- de SSD, j'ai fait quelques essais sur une clé USB de 4 Go.
Le but est de faire 2 partitions, une d'environ 250 Mo pour installer une SystemRescueCD (pour formater le sSD plus tard ;-) ), le reste en FAT32 (bin ouais, les collègues sont pas sous Linux...).
Je laisse donc les 256 premiers secteurs, je fais la 1ère d'un multiple de 256s, et la deuxième avec le reste :

 
soit en "unit compact" :
 

 
Jusque là, ça va.
Mais si je lance cfdisk (pour "vérifier" qu'il voit bien la même chose) :

 
Comme solution, j'ai réduit la 2ème partition d'environ 15800 secteurs (soit 1 cyl).
Ou alors j'ai créé la 2ème partition dans cfdisk qui lui me réduit de 177 secteurs.
Une explication ? (c'est juste histoire de se rassurer, je sais aussi que cfdisk réclame parfois des trucs par rapport à de vieux systèmes de fichiers)
 
Ah, et en passant, la formule :
Taille de la partition en secteurs = taille de la partition en Mo * 1024 * 1024 / 512
soit Mo * 2048 (non ?)
ça colle pas avec la première ligne. Mais je suis surement pas bien réveillé...  

Merci pour ces quelques optimisations ssd pour Linux. Très pratique pour mon Vertex 60 Go sous Ubuntu 9.04

Petite question à propos de la prise en compte du TRIM, est-ce que le kernel lance ces ordres quand les SSD sont en raid ?

Le kernel balance peut être les ordres, mais contrôleur RAID ne sait pas les interpréter, donc les SSD ne les recoivent pas dans tous les cas.

Réinstallation de Arch sur mon Aspire One (j'ai tout pété mon FS une conjonction de Ext4 et d'une connerie de ma part     ), j'en profite pour suivre les conseils de la première page, on va voir ce que ça donne    
Et cette fois, Ext2, plus d'Ext4 sur ce SSD pour moi, j'ai donné.
Et pas d'Ext3 parce que je veux grapiller le moindre pourcentage de perfs possible sur cette bouse.

Par curiosité, t'as fait quoi exactement pour planter ton FS ?

Il a essayé de m'imiter

franchement, félicitations pour les 1ers posts, ils sont nickel  
j'viens de craquer sur le Crucial M225 en 64 Go, donc j'vais pouvoir tester tout ça bientôt

Merci
 
Je suis en train de me renseigner auprès de Marc concernant le TRIM sous Linux. En effet, dans son test du Vertex, il semblait dire que le TRIM était supporté nativement sous Linux, puis on a eu l'info que ce support ne serait effectif qu'avec le noyau 2.6.30, info que j'ai relayée et considérée comme validée. Or dans la news d'hier ou avant hier concernant la MAJ des Vertex qui doit arriver dans quelques jours et qui apporte le support du Garbage Collector, Marc semble remettre en cause le support du TRIM par Linux et MacOS car ces deux OS n'ont pas de wiper.
Or, j'en était resté à la précédente info, à savoir qu'ayant un support natif du TRIM, Linux n'avait pas besoin de wiper. Du coup je n'y comprend plus grand chose...

Voici une autre information intéressante pour le partitionnement.
 
Comme on l'a vu précédemment, la méthode actuelle avec Parted est limitée si on veut diposer d'un grand nombre de partitions. En effet, avec une table de partition "classique" (msdos), il y a des limitations avec les partitions primaires et étendues.
 
Une solution que j'ai vue sur ce topic consiste à créer une seule partition étendue qui occupe tout le disque, et à n'utiliser que des lecteurs logiques dans cette partition. C'est astucieux car ça évite le mélange de partitions primaires et étendues.
 
Toutefois, il existe une solution plus simple et plus naturelle: il suffit d'utiliser une table de partitions de type GPT. Avec cette table de partitions "modernes", il n'y a plus de limitation du nombre et de la taille des partitions. Il n'y a pas non plus de notion de "primaire / étendue".
 
Avec parted, on peut créer une table de partitions GPT (attention cela efface toutes les données du disque):

 
Ensuite, on crée les partitions normalement. A la place du "type" de partition (primary), on spécifie un libellé pour la partition. Je reprends l'exemple page 1 et je l'étends::

 
On peut ainsi créér autant de partitions que voulu tout en gardant l'alignement.
 
A ce jour, je n'ai constaté aucun dysfonctionnement lié à l'utilisation d'une table de partitions GPT. GRUB sait très bien booter dessus. Même Windows XP 32 Bits SP3 reconnait les partitions (mais ça m'étionnerait qu'il sache booter dessus).
 
Sinon, je re-confirme que placer le flag "boot" (cf page 1) est inutile pour Linux. C'est utilisé uniquement par le MBR de DOS/Windows.

J'ai mis à jour le second post qui traite du partitionnement. Si tu veux bien faire une relecture rapide, histoire qu'il n'y ait pas n'importe quoi dedans, mais bon pour le plus gros c'est du copier/coller.
Merci pour cette méthode en tout cas Faudra que je test à l'occaz. Lors de mon prochain changement de SSD (donc pas tout de suite)

Donc avec cette méthode, on arrête de se prendre la tête avec les /dev/sdx ?
Ou faut-il encore jouer avec de temps en temps ?

ou  

?

Je suis en train de lire ce qui concerne GPT sur Wikipedia.
 
Pour ceux que ça intéresse, GPT est un pré requis de l'EFI (qu'on ne trouve pour l'instant que sur les Mac-Intel). La compatibilité ascendante avec le BIOS est garantie par le maintient du MBR dans GPT comme premier secteur. La conservation du MBR permet également au softs de gestion du MBR de fonctionner avec une table GPT. Donc il faudrait faire des tests, mais il est possible que même Windows boot dessus. A voir...

Ben en même temps, avec les UUID, on se prend plus la tête avec les sdxx depuis un moment...

FreeBSD 8.0 utilise GPT d'ailleurs

 
Non, les labels dans la table des partitions ne sont pas liés au nommage des devices par Linux.
 
Si tu veux te simplifier la vie, utilise les UUID de tes filesystem, ou mieux les Label de filesystem..
 
La commande tune2fs permet d'ajouter un label à un filesystem existant.

 
Tu peux ensuite la monter comme suit:

 
Et dans le fstab (exemple::

Intéressant

Le UUID est-il conservé en cas de formatage/changement de distrib ?

 
Non, l'UUID (et le label) font partie du filesystem.
Si tu formattes, un nouvel UUID est regénéré automatiquement (et le label est supprimé, sauf si tu en spécifies un explicitement).
 
Tu peux toutefois forcer l'UUID et le Label pendant le formattage, pour réutiliser à chaque fois le même:

 
La syntaxe est la même pour modifier label et UUID sur une partition déja formattée:

 
Et enfin, pour afficher les infos du filesystem:

Tiens, une question me vient. En fait, j'hésitais presque à tester le montage des partitions avec GPT sur mon Vertex, mais du coup je risque de salir encore plus et tant que je n'ai pas confirmation de l'efficience du TRIM sous Linux, je préfère éviter. Donc, je me demandais : sous Windows, il existe des utilitaires, mais à quoi peut-on faire appel sous Linux pour formater proprement son SSD et le ramener à l'état vierge/usine ? Une solution libre sur CD bootable serait nickelle par exemple.

 
Je ne sais plus exactement, mais je crois que c'était un hard shutdown suite à plantage quasi-complet du système, ya pas mal de fichiers qui ont morflé. (après une mise à jour je crois)
Mais bon, je n'accuse pas vraiment Ext4, y'a conjonction de pleins de trucs dont ce SSD tout pourri.

Je vous lis depuis un tit moment je me demandais : l'Ext4 n'est pas le plus approprié pour les SSD ?

Les dernières versions de hdparm peuvent faire office de wiper en théorie, en lui passant à la main les adresses à TRIMer. Je crois que l'auteur de hdparm a également sorti un script shell qui fonctionne sur ext* pour faire ça automatiquement (bon après, j'ai un SSD qui supporte pas le TRIM, et la version de hdparm dans Debian unstable est trop ancienne ).

Tu aurais un peu plus d'info là dessus ? Ca peut être intéressant, comme pour avoir le wiper OCZ sous Linux (pour ceux qui ont un Vertex ou clone). En plus, avec Cron, il y a moyen de se faire un truc qui TRIM tout seul et tout ça, ça peut le faire... Bref, intéressé.

Bon, alors le trim supporté par le kernouille ? efficace ? vérifié ?

http://www.ocztechnologyforum.com/ [...] hp?t=60882 par exemple (et les options d'hdparm pour lui passer les adresses à TRIMer sont : --please-destroy-my-drive --trim-sector-ranges-stdin <adresses>. J'aime bien le '--please-destroy-my-drive' perso   )

Quelqu'un a trouvé son script sur SourceForge ? Je n'arrive pas à mettre la main dessus.

Normalement c'est http://sourceforge.net/projects/hd [...] z/download
 
Sinon, pour le support TRIM dans le noyau, il semblerait qu'il y soit, mais pas efficace, cf. la LKML : http://marc.info/?l=linux-kernel&m [...] 831546&w=2 (genre la commande est envoyée séparément pour chaque extent au lieu de grouper...)

Par contre, pas possible de tester pour le moment, hdparm 9.25 est requis, et même dans testing sous Arch, cette version n'est pas dispo. Je ne veux compromettre mon gestionnaire de paquets, donc pas de tests pour le moment. Je regarderai éventuellement dans Yourt, mais je ne peux pas pour le moment.

EDIT : rien dasn AUR, donc je passe la main à quelqu'un qui pourrait tester, en attendant que la 9.25 arrive au moins dans testing.

Je vous lis depuis un tit moment je me demandais : l'Ext4 n'est pas le plus approprié pour les SSD ?

J'ai essayé rapidement le wiper, juste pour voir, mais vu que je n'ai pas le support du TRIM, c'est un peu inutile. Voilà toujours ce que ça donne :

Ouais, inutile    
 
Et vu que j'ai ma partition en ext3, il m'a fallu la remonter en lecture seule pour tester le wiper (seuls ext4 et xfs supportent ça en lecture/écriture…).
 

 
Je pense que ça dépend vraiment du SSD : sur une bouse (infâme ) à base de JMF602, je pense que c'est préférable de prendre XFS ; vu qu'il exploite le cache à fond (bon forcément, ça prend de la RAM), ça pourrait masquer un peu le "ah, je fais 4 écritures de 4K et puis j'ai plus de cache je freeze" (j'ai pas fait de benchmark hein, c'est peut-être une grosse connerie). Pour les bons SSD, je pense pas que ça ait beaucoup d'influence…
 
Après, je crois que l'un des développeurs principaux de ext4 a un SSD Intel V1 (il a fait pas mal de billets sur son blog à ce sujet), donc c'est bon signe.

Euh... sans vouloir être désagréable parce que l'intention est louable, quel intérêt d'avoir tester le wiper sur un SSD sans TRIM en ext3 ? J'ai bien remarqué que tu disais que tu savais que ça n'a que peu d'intérêt, mais c'est même que ça n'en a pas du tout, sauf à voir si le wiper fourni la bonne liste d'adresse à hdparm. Et encore, sur un disque qui ne supporte pas TRIM, je ne suis même pas sur que cette liste soit pertinente du coup.

JMicron, ou la litanie de l'informatique... Déjà leur contrôleur IDE/RAID avaient fichu une belle pagaille pour le prise en charge de périphériques IDE, notamment lorsqu'ils étaient couplés, à l'époque, à du nForce 4 en chipset. Cette boite a-t-elle fait quelque chose de bon ? Bref...
Le revers de la médaille à travailler avec le cache à fond, comme XFS, c'est qu'en cas de crash ou de coupure de courant, les conséquences peuvent être importantes, ce qui était en cache étant définitivement perdu...

 
J'ai bien dit que ça servait à rien, le wiper ne s'exécute pas de toute façon, c'était juste pour tester, pour la beauté du geste    (et pour voir qu'il se marre à parser la sortie de /sbin/dumpe2fs /dev/sda1 pour trouver les adresses à passer ).
 

C'est pas pire que les "recommandations habituelles" pour ext{3,4} à base de nobh,data=writeback, ou encore d'augmenter le délai de commit.

ça y est, je tourne sur mon SSD Crucial

sinon Kortex, c'est quoi qu'ils utilisent sous arch pour choisir les demons avec la syntaxe que t'as marqué dans les premiers posts ?

 
! : devant un démon qu'on ne veut pas lancer (comme si on le commentait, en fait)
@ : devant un démon qu'on veut lancer en background, on n'attend pas qu'il ait fini de se lancer avant de passer au suivant. (ça accélère le boot mais certains démons doivent être lancés dans un ordre précis, c'est pour ça qu'on ne le met pas partout)

ok, mais c'est dans quel fichier qu'on met ça ?
c'est quel système qui gère l'init quoi ?

/etc/rc.conf, à la BSD quoi

ok
j'ai pas ça sous kubuntu