Reprise du message précédent :

C'est alors naze, btrfs a plein d'options sympa...

non, ce n'est pas naze, la plupart des gens utiliseront les options de base.

ben oui, chuis d'accord avec Mjules, le test est 1°) hyper fair-play 2°) réaliste par rapport aux usages
D'autant que btrfs detectant automatiquement les ssd il manquerait plus que les dévs mettent pas les bonnes options en ce cas
 
Ce qui m'étonne dans le développement de btrfs c'est que, dans le cas d'ext4, les perfs étaient excellentes par rapport à ext3 au cours de développement puis l'écart s'est un peu réduit au fur au mesure qu'ext4 était "sécurisé". Dans le cas de btrfs on part de plus bas qu'ext4 au cours du développement : pourrons t-ils remonter ?

Je pense qu'il est difficile de comparer de cette façon, ext4 était construit à partir de ext3 qu'il a nettement amélioré. Btrfs est basé sur un paradigme "nouveau" qui n'avait pas d'implémentation encore sous Linux.

La plupart des gens n'utilisent pas btrfs.
Je pense que les gens qui utilisent ce systeme (ou reiser4 a l'epoque) recherchent un brin les options de montage...

 
Il est évident que les gens normaux n'utilisent pas un système de fichiers expérimental. En revanche, si un jour il est stable et présente un intérêt concret face à l'ext4, des distribs l'intégreront comme FS par défaut et les gens l'utiliseront (avec les options par défaut).
Pour l'heure, c'est juste un jouet pour geeks en mal de nouveauté.

On est d'accord /fin

Bonjour et merci à l'initiateur du topic ainsi qu'aux différents participants.
 
Je n'ai pas encore tout lu (je ne fais que commencer), toutefois j'aurais une question :

 
Sur la page Wikipédia consacrée à l'amplification d'écriture, le garbage collection est définit comme suit :

En illustration on voit un diagramme divisé en 3 étapes, montrant respectivement :
 

• un bloc X constitué de 16 pages dont 4 pages de données A, B, C, D + un bloc Y vide.
• le même bloc X après que l'on ait écrit 4 nouvelles pages E, F, G, H ainsi que 4 pages A', B', C', D' versions modifiées des pages A, B, C, D. Ces dernières ne sont pas effacées mais les données qu'elles contiennent ne sont plus valides. X est donc plein, plus aucune page ne peut être écrite + le bloc Y toujours vide.
• le bloc Y dans lequel seules les pages valides du bloc X ont été écrites, soit A', B', C', D' et E, F, G, H, ainsi que le bloc X totalement effacé. Y, contrairement à X dans l'étape précédente, contient encore 4 pages libres (puisque les données non valides A, B, C, D n'ont pas été copiées).

Certes tout ce processus (celui décrit dans la 3e étape pour être précis) induit probablement une réorganisation de la table d'allocation mais son but premier n'est pas celui-ci mais plutôt de libérer de l'espace mémoire (en l'occurrence des pages stockant des données qui ne sont plus valides car elles ont été modifiées dans le système de fichiers), non ?
 
Le lien externe sur lequel s'appuie ce passage est ce pdf dans lequel on peut lire entre autre :

Là encore, pour définir le garbage collection l'accent n'est pas mis sur une réorganisation de la table d'allocation, qui a sans doute lieu, mais sur la libération d'espace mémoire.
 
De plus ils ne parlent pas d'améliorer les performances d'écritures séquentielles sur une zone précédemment écrite de manière aléatoire, ils disent qu'à un moment, après avoir écrit une quantité de données équivalente à la taille du SSD, un processus qu'ils qualifient de "consolidation" a lieu (le garbage collection) qui va libérer de l'espace comme décrit dans le précédent diagramme afin de faire de la place pour plus de données.
 
D'où mes questions, est-ce une erreur de Wikipédia et de sa source ? Ai-je mal interprété ces paragraphes ? Ou s'agit-il plus simplement de 2 définitions complémentaires ?
 
Merci d'avance pour vos éclaircissements.

Bonjour,
 
Un nouveau venu dans le monde du SSD, j'ai reçu le mien aujourd'hui pour redonner un peu de vitalité à mon portable et j'ai quelques questions car je n'en suis pas encore familier
 
Mon disque dur actuel contient en dual boot Win7 et une Ubuntu 11.10 chiffrée¹ (seulement le /home semble-t-il ?)
 
Ma première question est la suivante : que me conseillez-vous pour migrer facilement (sans procéder à une réinstallation des OS) les données de mon disque dur actuel vers mon ssd ?
 
Bien entendu la capacité de mon hdd est plus grande que mon ssd sinon ça ne serait pas drôle   : mon hdd actuel est un Hitachi HTS54503 de 320 Go de mon portable Acer 1830T, le nouveau ssd est un Intel 320 "PostVille refresh" de 160 Go.
J'ai de quoi copier/cloner/sauvegarder au besoin les données sur un autre hdd pour assurer la migration.
 
Voici les infos dont je dispose :
 
parted print all :

 
df -h :

 
cat /etc/fstab:  
 

 
Merci pour votre aide
 
 
(¹ ce qui apparemment ne fait pas bon ménage avec le TRIM du ssd : http://asalor.blogspot.com/2011/08 [...] lems.html)

Hop, recyclage de mon Kingston V 40Go dans un asrock ion330.
En cours en ssh (et oui machine allumée, j'ai pas peur )...

Et la ré-écriture sur le ssd (depuis un autre pc):

Seul requis, avoir des partitions créées sur le ssd, quelque soit leur taille.

Eh m**de, en jetant un oeil aux données smartctl, je m’aperçois que le compteur "Non4k_Aligned_Access" crève le plafond. Autrement dit, mes partitions ne sont pas alignées. Comme quoi, faut pas se fier aux nouvelles-versions-qui-alignent-automatiquement  

j'ai le même problème ; pour le moment je n'ai rien fait parce qu'il faut que je transfère tout.
Tu pourras me dire quelle méthode tu as suivi pour faire ton alignement ?

Je ne vois pas ce compteur, comment faites-vous pour l'avoir ?

 
smartctl -a /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.1.8-yuuki-r1] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
 
=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron RealSSD C300/C400
Device Model:     M4-CT064M4SSD2
Serial Number:    00000000xxxxxxxxxxx
LU WWN Device Id: 5 00a075 1916546v
Firmware Version: 0009
User Capacity:    64,023,257,088 bytes [64.0 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 6
Local Time is:    Sat Jan  7 12:30:28 2012 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
 
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
 
General SMART Values:
Offline data collection status:  (0x80) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever  
                                        been run.
Total time to complete Offline  
data collection:                (  295) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine  
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (   4) minutes.
Conveyance self-test routine
recommended polling time:        (   3) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.
 
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   050    Pre-fail  Always       -       0
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   100   100   001    Old_age   Always       -       2807
 12 Power_Cycle_Count       0x0032   100   100   001    Old_age   Always       -       227
170 Grown_Failing_Block_Ct  0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   001    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   001    Old_age   Always       -       0
173 Wear_Levelling_Count    0x0033   100   100   010    Pre-fail  Always       -       5
174 Unexpect_Power_Loss_Ct  0x0032   100   100   001    Old_age   Always       -       0
181 Non4k_Aligned_Access    0x0022   100   100   001    Old_age   Always       -       390 166 223
183 SATA_Iface_Downshift    0x0032   100   100   001    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   050    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   001    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   001    Old_age   Always       -       0
189 Factory_Bad_Block_Ct    0x000e   100   100   001    Old_age   Always       -       52
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       0
195 Hardware_ECC_Recovered  0x003a   100   100   001    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   001    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   001    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   001    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   001    Old_age   Always       -       0
202 Perc_Rated_Life_Used    0x0018   100   100   001    Old_age   Offline      -       0
206 Write_Error_Rate        0x000e   100   100   001    Old_age   Always       -       0
 
SMART Error Log Version: 1
No Errors Logged
 
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      2800         -
# 2  Extended offline    Completed without error       00%      2800         -
# 3  Short offline       Completed without error       00%      2798         -
 
SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

 
 
Pour l'instant, je ne l'ai pas fait puisque je viens de le remarquer et que, comme toi, faut que je fasse un backup.
 
Dans mon cas, j'ai un crucial M4 de 64Go en partitionnement de type MBR donc:
 
- secteurs 0 réservé pour la MBR
- secteurs de 512B
- page size de 4KiB
- erase block de 512KiB1024KiB
 
=> je cherche le premier multiple de 1024576 (erase block en bytes) qui soit également un multiple de 4096 (page size en bytes) => pas trop dur: 1024576 (bytes).
=> je divise ce multiple par la taille de secteur (512 Bytes) : 2048.
 
Je commence donc ma 1ère partition au secteur 2048. Mes autres partitions devront également commencer sur un multiple de 4096 et 1024576. Et je formate le tout en ext4 avec blocks de 4K
 
Pour la pratique:
* un live usb ubuntu (de la même archi que l'installation) et reboot dessus
* backup de mes partitions avant destruction:
 
sda1 et 2 sont sur le SSD, sdb1 est un disque de stockage
 
sudo su
mkdir -p /mnt/part1 /mnt/part2 /mnt/backup
mount /dev/sda1 /mnt/part1
mount /dev/sda2 /mnt/part2
mount /dev/sdb1 /mnt/backup
mkdir /mnt/backup/system /mnt/backup/home
cp -a /mnt/part1/* /mnt/backup/system
cp -a /mnt/part2/* /mnt/backup/home
umount /mnt/part1 /mnt/part2
 
* destruction/création de 2 partitions:
 
gparted -a optimal /dev/sda
unit s
print all
rm 1
rm 2
=> partition de 14Gio pour le système
mkpart primary 2048 29362175
set 1 boot on
-> seconde partition pour home avec l'espace restant (de la fin de la partition précédente +1 jusqu'au dernier bloc du ssd affiché par print all)
mkpart primary 29362176 <dernier_bloc>
quit
 
* création du filesystem (dans mon cas ext4) avec une taille de 4K et un stride de 256 correspondant à mes blocs phy de 1Mio (bien que d'après le man, ça ne sert que pour le RAID)
 
mkfs.ext4 -b 4096 -E stride 256 /dev/sda1
mkfs.ext4 -b 4096 -E stride 256 /dev/sda2
 
* recopiage du backup vers les partitions toutes neuves
 
mount /dev/sda1 /mnt/part1
mount /dev/sda2 /mnt/part2
cp -a /mnt/backup/system/* /mnt/part1
cp -a /mnt/backup/home/* /mnt/part2
 
* réinstallation de grub dans la MBR
grub-install --no-floppy --root-directory=/mnt/part1 /dev/sda
 
*  récupération des nouvelles uuid et édition de fstab
 
ls -al /dev/disk/by-uuid
-> remplacement des anciennes uuid dans fstab à l'aide d'un éditeur (on édite le bon fichier fstab, pas celui du live USB - dans mon cas /mnt/part1/etc/fstab)
 
* on chroot pour mettre grub à jour
chroot /mnt/part1
update-grub
 
* on démonte nos précieuses partitions avant le reboot final:
umount /mnt/backup /mnt/part1 /mnt/part2
reboot
 
EDIT: entre la théorie et la pratique, il y a toujours un truc louche qui flotte dans le potage En fait, la taille de blocs physiques est de 1Mio au lieu des 512Kio attendus. Donc j'ai modifié les chiffres en conséquence et remis la procédure (de tête, gaffe au typos). Bref, 2h pour faire un truc qui aurait dû prendre 30min.

pareil, je n'ai pas cette entrée...

Ca dépend des SSD et il faut également que l'utilitaire smart soit à jour. En gros, il doit connaître le modèle du SSD pour nommer correctement les compteurs.
Perso, j'ai dû compiler la dernière version de smartmontools pour qu'il reconnaisse mon M4.

 
Ça doit être pour ça que j'ai pas non plus cette ligne.
 
(version svn de smartmontools)

je n'ai pas plus d'informations pour ma part - Corsair F60.

En dehors des trucs courants qu'on trouve chez tout le monde (temps de fonctionnement, nombre de démarrages, nombre de secteurs réalloués,...) la présence, l'organisation et les labels des compteurs varient d'un modèle à l'autre.

Pour info, pour les possesseurs de Crucial M4:
http://www.hardware.fr/news/12062/ [...] eures.html

En même temps, un bug qui vautre windows ne doit pas inquiéter grand monde par ici. Accessoirement, le correctif sera dispo dans quelques jours et, si un windosien affecté passait par ici, il peut toujours désactiver smart dans son bios dans l’intervalle.

Je ne pense pas que ca ne vautre que windows justement vu que ca semble provenir du SMART.

Je ne pense pas qu'une valeur erronée dans le SMART puisse faire planter le kernel...
Au pire il y aura un message d'alerte dans les logs et encore.

Nous le saurons bientôt  

J'ai cherché également à quoi pouvait servir cette option dans le cadre de la création d'un système de fichiers aligné sur un ssd et je n'ai trouvé qu'une mention au RAID ici en plus du man de mke2fs :
 

donc a priori cette option est totalement inutile si tu ne fais pas de RAID.
D'ailleurs sur la documentation d'Arch consacrée au ssd, et qui pourtant aborde le problème de l'alignement, il n'en est pas fait mention une seule fois.
 

 
Je ne pense pas :
 

Je n'ai pas non plus la ligne en question, pourtant j'ai installé la dernière release 5.42 de smartmontools à partir des dépôts backports de Debian et j'ai mis à jour la base de données drivedb.h :

 
Je ne comprenais pas cette histoire d'alignement, je me suis donc documenté sur le sujet essentiellement (même si pas totalement) à partir de cette page.
Je précise qu'il s'agit de l'alignement dans le cadre des nouveaux disques durs dont la taille des secteurs est de 4 Kio.
Il y a peut-être beaucoup d'erreurs dans ce que je vais écrire, si c'est le cas je m'en excuse par avance, mais faute de mieux c'est comme ça que je m'explique la chose pour le moment :
 
D'abord il y a 3 termes qui reviennent quand on parle d'alignement et pour lesquels j'avais du mal à trouver une définition précise (en particulier pour "bloc" ) :
 
secteur : la plus petite unité de stockage sur un disque dur que le contrôleur/firmware (fw) peut lire/écrire.
bloc :

• pour un système de fichiers (fs) tels que ext2/3/4, la plus petite unité de stockage.
• pour un utilitaire unix, une unité arbitraire généralement 512 octets / 1 Kio.
• pour un ssd, unité de base pour l'effacement des données correspondant à un certain nombre de pages. (le contrôleur du ssd lit/écrit par page mais efface par bloc)

cluster : pour un fs Windows tel que FAT, la plus petite unité de stockage (depuis DOS 4.0 on parle d'unité d'allocation même si le terme cluster reste très utilisé).
 
Les disques durs sont divisés en unités appelées secteurs, dont la taille est habituellement de 512 octets. En plus des données qu'il est censé stocker chacun de ces secteurs utilisent entre autre une partie de son espace pour permettre au fw du dd de corriger d'éventuelles erreurs via des algorithmes de code de correction d'erreur (ECC).
La taille des dd augmentant, l'espace alloué à la correction des erreurs est de plus en plus importante (plus de secteurs = plus d'espace ECC), de plus la densité des données augmentant les erreurs de bas niveau augmentent elles-aussi et mettent à rude épreuve la capacité du fw à les corriger toutes.
Pour ces 2 raisons les constructeurs produisent désormais de nouveaux dd dont la taille des secteurs est de 4 Kio, ce qui permet de maximiser l'espace disponible pour l'utilisateur (secteurs plus gros = moins de secteurs = moins d'espace ECC) et de soulager le fw en utilisant des algorithmes de corrections d'erreurs plus puissants qui le sollicitent moins.
 
Toutefois il reste un problème : la compatibilité avec les logiciels (BIOS, bootloaders, noyaux d'OS, fs, utilitaires).
En attendant que toutes ces briques logicielles soient mises à jour et compatibles avec des secteurs de 4 Kio, les constructeurs ont mis au point des fw qui présentent à ces dernières (émulent) des secteurs de 512 octets.
Les secteurs physiques lus/écrits par le fw font bien 4 Kio mais les logiciels eux ne voient que des secteurs logiques (émulés par le fw) de 512 octets. Cette caractéristique est appelé Advanced Format (Format Avancé).
 
Pour connaître la taille des secteurs logiques et physiques il suffit de lire les résultats des commandes suivantes :

... en remplaçant sdx par la dénomination correcte du dd (sda, sdb, sdc etc).
 
Malheureusement, le résultat de la 2e commande est parfois (souvent ?) faux. Je possède par exemple un dd Seagate (référence ST2000DL003) qui utilise la technologie de Format Avancé et donc des secteurs physiques de 4 Kio. Pourtant les commandes présentées ci-dessus me retournent une valeur de 512 octets pour les secteurs logiques (juste) et physiques (faux).
D'ailleurs quand je lance GParted dessus et que j'affiche les informations à son sujet (Affichage > Informations sur le périphérique) la taille des secteurs annoncée est encore de 512 octets. En cherchant rapidement sur Google j'ai lu qu'il se pourrait que le fw "mente" pour une histoire de compatibilité avec d'anciens OS comme Windows XP...
 
Un autre problème se pose, celui de l'alignement des partitions et des fs.
Supposons que la taille des blocs des fs ne dépasse pas 4 Kio ce qui est souvent le cas.
Si un fs n'est pas aligné, cela signifie que chaque bloc de ce fs est à cheval sur 2 secteurs physiques. Lorsque le fw devra lire un tel bloc cela n'aura le plus souvent qu'une faible incidence, par contre cela peut fortement dégrader les performances lorsqu'il devra écrire dessus car pour un bloc écrit il devra lire 2 secteurs (au lieu d'un), modifier des portions de ces 2 secteurs (au lieu d'un) et écrire 2 secteurs (au lieu d'un).
Toutefois l'ampleur de cette dégradation est extrêmement variable selon les fs en témoignent les graphes de la page citée plus haut.
 
Aligner un fs consiste donc à faire en sorte qu'aucun bloc ne soit à cheval sur 2 secteurs physiques.
Pour ce faire il suffit de donner aux partitions des tailles multiples de 4 Kio, et de faire commencer la 1e partition sur un secteur tel que l'espace le précédant soit lui-aussi un multiple de 4 Kio typiquement le secteur 2048 qui est choisi par défaut avec certains utilitaires tel que GParted.
En effet le 1er secteur (MBR) ayant l'adresse LBA 0, le secteur logique 2048 débute après 1 Mio ((2047+1) x 512 octets), qui est un multiple de 4 Kio, donc le 1er bloc de la 1e partition est bien aligné tout comme les autres blocs des fs des différentes partitions si on a donné aux partitions des tailles multiples de 4 Kio.
 
En conclusion : avec GParted il devrait suffire d'aligner les partitions sur le Mio et vérifier qu'il a bien fait commencé la 1e partition sur le secteur n° 2048, ce qu'il fait de toute façon automatiquement depuis longtemps. (et ne pas laisser d'espace non-alloué entre les partitions à moins qu'ils n'aient des tailles multiples de 4 Kio)
 
Maintenant concernant les ssd que signifie aligner les partitions et les fs ?
Je suppose qu'il s'agit d'aligner les blocs des fs avec les pages et les blocs du ssd. Autrement dit il faut faire en sorte qu'aucun bloc d'un fs ne soit à cheval sur 2 pages ou sur 2 blocs du ssd.
Si les blocs des fs sont à cheval sur 2 pages, lorsque l'OS voudra en écrire un le fw devra accéder à 2 pages au lieu d'une.
Si des blocs des fs sont à cheval sur 2 blocs du ssd, lorsque l'OS voudra écrire un bloc d'un fs, non seulement le fw devra accéder à 2 pages au lieu d'une mais si en plus elles ne sont pas vides tout le processus consistant à copier le contenu d'un bloc du ssd en mémoire cache, à l'effacer, à modifier la page qui change, et à recopier le bloc sur le ssd (processus qui est nécessaire pour modifier une page puisque le fw doit effacer une page avant de la modifier et qu'il ne peut effacer que par bloc de ssd) sera multiplié par 2 ce qui dégradera les performances.
 
Or les pages d'un ssd font généralement 4 Kio, de plus 1 Mio est un multiple de toutes les tailles de blocs de ssd (généralement 512 Kio , 1 Mio).
Donc la conclusion précédente devrait rester valable même pour un ssd, à savoir pour aligner les partitions et les fs d'un ssd il suffit, avec GParted, de créer des partitions dont la taille est alignée sur le Mio et vérifier que le 1er secteur de la 1e partition est le 2048.
Conclusion que l'on peut d'ailleurs retrouver sur cette page.

@lagori : je ne sais pas pour toi, mais chez moi:
 

 
Du coup, j'aurais tendance à m'en méfier, même ça fonctionne pour certains

J'avoue que je suis comme toi, je m'en méfie. Pour être sûr je vais lire directement sur le site du constructeur les caractéristiques du produit.
Ça pourrait dépendre du fw, certains déclarant la vraie valeur d'autres non, pour quelle raison je n'en sais rien.  

FIOPS: A New Linux I/O Scheduler For Flash/SSDs
http://www.phoronix.com/scan.php?p [...] px=MTAzOTU

Bonjour,
 
voilà j'installe une ubuntu 11.10 sur un OCZ solid series (1er du nom avec l'usb sur le ssd avec le super controleur   )
 
il faisait parti d'un raid 0 et à l'instal il me propose 60GB d'espace libre sur un ssd de 32    
 
impossible (enfin je ne sais pas la manip existe) de la supprimer, après avoir tenté divers choix automatiques
 
et après diverses manip j'ai tjrs le message ~"aucun système de fichier n'a été choisi comme racine etc
 
d'avance merci
 

Bonjour,
 
Je compte me monter un pc et mettre arch en os sur un SSD que j'ai déjà (C300 128Go). Je compte aussi y mettre un 7 plus tard.
Je pensais donc partitionner en conséquence genre 20Go pour /, 256Mo pour le swap () et 5Go pour /Home (les données seront sur un HDD) puis la partition windows.
Mais si je procède de la sorte, le trim va se faire que sur les 20Go de / et donc « user » uniquement un secteur du disque. C'est ça ? Est-ce que je ne devrais pas prendre un disque de 40Go pour mettre arch ?

Pas du tout. Les SSD gèrent l'usure des cellules independemment des partitions logiques définies par l'utilisateur.

Je suis en train de suivre les conseils pour le partitionnement.
On verra bien

Comment le savoir pour mon Corsair F60 ?

Bah google ou alors tu fouilles dans les tests HFR. Si ton modèle a été testé dans un comparatif, il est possible que tu y trouves ce genre de détails.
 
Par contre, me demande plus les détails. J'ai écrit ça quand c'était tout frais dans ma tête, depuis j'ai tout oublié (l'art de perdre des heures sur un truc oublié le lendemain).

Introuvable - sérieusement j'ai cherché avant de demander ici

Je viens de trouver ça :
 
To align the partition of a single drive with a single NAND flash controller, you need to set it to the following.
 
1 NAND flash block (512KB)
 
For a single drive with dual NAND flash controllers, you would double the sectors.
 
2 NAND flash blocks (1024KB)
 
maintenant il va falloir chercher si mon SSD est un simple controleur ou double...

Tu peux tabler sur 1Mio. Comme il est de conception plus ancienne que mon m4, au pire, il utilise des blocks de 512Kio et tu gaspilles quelques Kio mais tu seras quand même aligné.