Ce qui veut dire qu'ensuite les blocs du système de fichier (les clusters sous windows) sont allignés avec les cellules physiques du SSD (cad qu'un cluster de 4Ko rentre exactement dans une cellule de 4Ko, ça déborde pas de 512o avant, ni après) et donc qu'on n'a pas d'overhead et qu'on limite l'usure des cellules dans une moindre mesure.
(sauf avec les fs en FAT16 qui sont mal foutus et qui décallent tout à cause de leur structure, à moins d'utiliser des outils de formatage avancé, utile par exemple pour des cartes CF sur les appareils reflex pro qui demandent de grosses perf pour les photos de grande résolution en rafale par exemple, mais bon en photo pro on utilise du FAT32 et comme par défaut il y a 32 secteurs réservés ça colle avec les cellules physique des cartes, même si ça ne rentre pas parfaitement dans la fenêtre d'écriture de 128Ko ça reste acceptable)
Pas de pb interne au fs avec NTFS, pas de pb avec les fs linux courrants (ext 2/3/4, xfs, reiserfs, jfs...), à priori pas de pb avec les pool ZFS
Les cellules d'un SSD font toujours 4Ko, les disques récents (les "advanced format" ) ont aussi des secteurs physiques de 4Ko (même si l'OS voit des secteurs de 512 dans les 2 cas, c'est juste pour des raisons de compatibilité ça)
A partir de vista l'installeur de win laisse toujours le premier Mo du support libre (cad les 2048 premiers secteurs : du 0 (mbr) au 2047, la première partition commençant au secteur 2048), là on est sur d'être alligné (y compris pour les raids dont le chunk size peut aller jusqu'à 1Mo)
Mais à l'époque où j'ai commencé à faire du raid et des alignements manuel, les OS ne géraient pas ce cas de figure, l'allignement c'était à coup d'outils linux et de calculette
La logique avec tous les supports 4Ko reste exactement la même qu'avec un raid.
Message édité par T3K le 31-12-2013 à 05:13:09