Performances minables RAID5 logiciel DEBIAN Server - Logiciels - Linux et OS Alternatifs
Marsh Posté le 29-04-2010 à 19:22:50
je commencerai par tester en local sur le serveur ...
Citation : dd if=/dev/md0 of=/dev/null bs=4096 count=1000000 |
Ca va lire 4Go sur ta pile raid (ou moins si tu n'as pas tant de donner) et les envoyer à la poubelle (ça ne supprime rien de ta pile, c'est comme si ça copiait dans le vide si tu veux)
puis :
Citation : dd if=/dev/zero of=/point/de/montage/de/ton/raid/test.bidon bs=4096 count=1000000 |
ça va écrire un fichier test.bidon de 4Go
avec dd tu verras les vitesses de lecture/écriture et le temps d'exécution
si déjà là c'est pourri => optimisation du FS
sinon => optimisation de Samba
Marsh Posté le 29-04-2010 à 19:24:56
Les paramètres par défaut du raid5 sous Linux favorisent très nettement la sécurité des données, au détriment des performances.
Pour améliorer les performances en écriture raid5, il faut augmenter la valeur de "stripe cache"
Ce réglage est situé dans le pseudo fichier "stripe_cache_size".
Tu peux afficher la valeur courante:
# cat /sys/block/md0/md/stripe_cache_size |
(généralement elle est très basse par défaut)
Tu peux changer la valeur comme suit (ex: 8192)
# echo 8192 > /sys/block/md0/md/stripe_cache_size |
A toi de tatonner pour trouver la valeur optimale (8192 semble pas mal si tu manques d'inspiration).
Pour les performances en lecture (hdparm -Tt), tu peux en théorie obtenir les performances de 2 disques, donc environ 200Mo/s dans ton cas.
Tu peux ajuster la valeur du "read ahead cache" avec la commande blockdev.
Afficher la valeur courante:
# blockdev --getra /dev/md0 |
Tu peux changer la valeur (il vaut mieux mettre une puissance de 2):
# blockdev --setra 16384 /dev/md0 |
Pareil qu'en écriture, à toi de tester la valeur qui donne les meilleures performances, 16384 étant un bon choix par défaut.
Pour améliorer très largement la performance de vérification/reconstruction du raid5 après un crash, tu peux ajouter une "bitmap" à ton raid (si tu l'as pas déja fait au moment de la création). Cela pénalise très peu les performances et fait gagner un temps fou en cas de crash de la machine:
# mdadm --grow -b /dev/md0 |
La bitmap permet de ne reconstruire que les données qui étaient en cours de modification sur le raid5, plutot que de reconstruire l'intégralité !
Avec ces 3 réglages, tes performances devraient décoller !
Concernant d'éventuelles optimisations du filesystem: inutile de te fatiguer, dans le cas du raid soft, Linux se débrouille tout seul pour effectuer les réglages optimaux lors du formattage, il n'y a donc rien à améliorer de ce coté.
Marsh Posté le 01-05-2010 à 19:34:41
Bonjour à vous deux !
Dans un première temps je vous remercie pour vos réponses (quasi simultanées) :) et l'intérêt que vous avez portez à mon message. Je ne m'attendais pas à des réponses aussi construites et explicites.
Je vais répondre étape par étape,
Réponse à Fighting_falcon :
Citation : SERVEUR:/home/flust# dd if=/dev/md0 of=/dev/null bs=4096 count=1000000 |
On remarque que la vitesse de mon RAID et médiocre, j'ai donc de suite suivit les conseils de [Albator] :
Réponse a Albator :
Citation : SERVEUR:/home/flust# cat /sys/block/md0/md/stripe_cache_size |
Après modifs de Albator :
Citation : SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000 |
On remarque une légère amélioration, mais lorsque j'ai réaliser un transfert de fichier avec les paramètres de mémoire cache à 8192 en écriture et 16384 en lecture supercopier m'affichait environ 10Mo/s supplémentaire lors d'un transfert de Windows a Linux sur mon raid 5, c'est une petite victoire mais qui fait plaisir, car l'amélioration de la vitesse de transfert est belle est bien réalisable !!!
J'ai également remarqué, Albator, que les paramètres de cache que je modifiais se réinitialisent lors du redémarrage du serveur, peux-tu me donner l'astuce pour les ajouter par défaut ?
J'ai posté mon problème sur d'autre forum, une personne ma intrigué en me parlant de la taille des bloc systeme (voir massage ci-dessous) auriez vous des conseils à me donner de ce coté ?
Citation : Les perf raid5 avec mdadm dépendandent beaucoup de la taille par défaut des blocs du système de fichier et du réglage du chunk-size sur ton array. |
Merci encore !
Marsh Posté le 01-05-2010 à 19:54:44
Le réglage que je t'ai filé n'a pour ainsi dire rien changé: ton problème est ailleurs. Ton raid, tu l'as crée avec quels paramètres ?
Donne voir le résultat de
# cat /proc/mdstat |
J'espère que t'as pas eu la mauvaise idée de réduire la taille des chunk (comme on peut le lire sur des mauvais forums/tutoriaux), la valeur de 64 Ko étant vraiment le minimum à utiliser. Car ça expliquerait des performances médiocres en écriture.
Pour la 3ème commande que je t'ai filé, la bitmap, je me suis trompé dans la syntaxe, la vraie commande est:
# mdadm -G /dev/md0 -b internal |
Mais ça n'impacte pas vraiment les performances.
Pour que tes réglages soient appliqués au redémarrage, à toi d'ajouter les commandes dans un script de démarrage (variable selon ta distribution).
Quand aux mecs qui t'embrouillent avec des histoires de bloc système sans plus de précision, ne te laisse pas avoir: sur la plupart des forums et des tutoriaux qu'on trouve sur le net, dès qu'on aborde le sujet du tuning de performances en raid, on se fait barratiner genre "les performances en raid5 dépendent de facteurs aussi nombreux que complexes". En gros le mec n'y connait rien et donne des pistes au hasard.
Si tu as la possibilité de refaire ton raid, je te suggère de faire un essai en raid-0 pour voir si tu obtiens un meilleur résultat (histoire de voir si ton pb vient du raid5 seulement, ou du raid tout court).
Exemple chez moi avec 3 disques de 1 To en raid0:
$ dd if=/dev/zero of=/mnt/storage/raid/test.bidon bs=4096 count=1000000 |
Ca te donne un ordre de grandeur de ce que tu devrais avoir chez toi.
Marsh Posté le 01-05-2010 à 20:05:58
Tu vas être surpris l'ami !
Citation : SERVEURhome/flust# cat /proc/mdstat |
Le chuck est bien à "64K" mais ce n'est rien, mon raid peut-être modifier ou supprimer, il ne contient aucune donnée importante ou non sauvegardées.
- Puis-je changer cette valeur ?
- Sans détruire le raid ?
- Sans formater les données ?
Pour info j'ai créer mon RAID avec ce tuto :
http://www.actualinux.net/2009/12/ [...] us-debian/
Marsh Posté le 01-05-2010 à 20:18:52
mlevain a écrit : Puis-je changer cette valeur ? |
oui (paramètre sur la ligne de commande mdadm)
mlevain a écrit : Sans détruire le raid ? |
J'ai peur que non, si je ne dis pas de connerie, il faut recréer ton raid, ce qui revient à détruire l'ancien
mlevain a écrit : Sans formater les données ? |
bah si recréation du raid, du coup perte des données ...
edit : ah j'oubliais,
mlevain a écrit : Dans un première temps je vous remercie pour vos réponses (quasi simultanées) et l'intérêt que vous avez portez à mon message. Je ne m'attendais pas à des réponses aussi construites et explicites. |
Mais de rien, et merci pour ton merci
edit 2 : autre chose, je viens de lire le tuto sur ton lien, tu as suivi sa procédure à la lettre ? parce que si oui, je te recommande (si tu en es à refaire ton raid) de faire des partitions "Linux raid autodetect" (type fd) au lieu des partoches "Linux" classiques (type 83) ...
Marsh Posté le 01-05-2010 à 20:19:57
OK, le tutorial est correct.
Non tu ne peux pas changer le chunk size ou changer le niveau de raid sans tout péter ... Il faut stopper la grappe et la recréer à chaque fois.
Arrêter la grappe:
# mdadm -S /dev/md0 |
Tu peux essayer les 2 combinaisons suivantes pour voir:
- raid 0 avec chunk à 64K
# mdadm -C /dev/md0 --level=raid0 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 |
- raid 5 avec chunk à 128K
# mdadm -C /dev/md0 --level=raid5 --chunk=128 -b internal --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 |
Puis formatter et tester à nouveau le "dd" en écriture ...
Pour le raid5, il faut évidemment attendre que la synchro initiale soit terminée (évidemment sinon ça plombe les performances) et activer les réglages que je t'ai donnés précédemment (pas utiles en raid0 normalement),
Marsh Posté le 01-05-2010 à 20:35:27
Tu penses que je peux refaire mon raid avec la valeur Chunk à 128k et cela résoudrai mon problème ? Je lance la synchro :-) je commence à maitriser les ligne de commandes !
Citation : SERVEURhome/flust# cat /proc/mdstat |
Citation : SERVEURhome/flust# cat /proc/mdstat |
Je donne des nouvelle dès demain,
Bonne soirée
Marsh Posté le 01-05-2010 à 20:49:44
Rien que la vitesse de synchro 94847K/sec indique que tu parviens à écrire à une telle vitesse ... c'est déja pas mal
Marsh Posté le 02-05-2010 à 11:58:12
[Albator] a écrit : Rien que la vitesse de synchro 94847K/sec indique que tu parviens à écrire à une telle vitesse ... c'est déja pas mal |
mouais, enfin généralement mdadm s'emballe au début d'une synchro et se calme ensuite ...
mlevain >
sinon, puisque tu as recréé ton raid, tu as modifié tes partitions sd[b-d]1 en type "0xfd" ou pas ?
Marsh Posté le 02-05-2010 à 13:08:24
Salut !
Bon voila, on avance tout doucement mais on avance !
J'ai donc hier détruit mon RAID puis reconstruit avec un CHUNK à 128
voici les resultats :
Citation : SERVEURhome/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000 |
Est-il possible de modifier le chunk et de l'augmenter et de combien ?
Merci
Marsh Posté le 02-05-2010 à 14:00:46
Ca reste super lent au vu de la config ... (le chunk à 64 Ko ne devrait poser aucun pb à un core2duo ...)
Tu peux augmenter sa taille par puissance de 2 jusqu'à autant que tu veux à priori, mais au delà de 512 Ko ça devient vraiment gros (je suis déja monté à 2 Mo sur un PC avec un vieux CPU cela dit).
Essaye d'abord différentes valeurs de stripe_cache_size (petites commes 384, 512, 768, 1024... puis grosses comme 16384, 32768, ne va pas au delà) pour voir si ça améliore les perfs.
Regarde sur cet article:
http://peterkieser.com/2009/11/29/ [...] -transfer/
On voit qu'il y a un rapport ~4 en écriture entre le stripe cache à 256 et 8192 !
Sinon, essaye de reformatter en forçant les optimisations du filesystem (options -b et -E à rajouter sur ta commande de formattage), par exemple pour ton raid5 128Ko:
# mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 /dev/md0 |
Marsh Posté le 02-05-2010 à 15:32:26
Effectivement c'est lent ... j'ai donc réaliser plusieurs tests que voici, la meilleur configue reste donc, comme l'indique ton lien, 8192 en écriture et 16384 en leccture, la lecture ne posant de toute facon pas de problème depuis le début :
Citation : SERVEUR:/home/flust# echo 384 > /sys/block/md0/md/stripe_cache_size |
Je tente donc un formatage comme proposé avec la commande
Citation : # mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 /dev/md0 |
Le formatage ce fait déjà plus vite qu'avec les stripe_cache_size par défaut
Je te donne les résultats dans quelques instants ...
Merci encore pour ton aide précieuse et efficace !
Edit : Lorsqu'on aura résolu le problème, je posterai un tutoriel pour les gens rencontrons les mêmes soucis, et je sais qu'il y en a plus d'un !
Marsh Posté le 02-05-2010 à 16:43:13
Bon nous y arrivons, j'ai donc formater mon RAID en EXT4 avec la commande que tu m'as donné et voici les résultats du test :
Citation : SERVEURhome/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000 |
Encore des améliorations :-) mais pas de débridage complet du bousin :-S
Marsh Posté le 02-05-2010 à 16:53:27
A mon avis t'es arrivé au bout des optimisations possibles ...
Essaye un raid0 , ou bien essaye une autre distro (genre ubuntu ou mandriva live cd), refais le test, et tu verras peut être une différence ... pask'avec une machine comme la tienne, tu ne devrais avoir aucun pb de perf même sans aucun optimisation ...
Marsh Posté le 02-05-2010 à 17:43:45
Je refais les manipulations avec un Chunk à 512 ko et je te tiens au courant dès demain, au pire je changerai d'OS pour tester également, j'ai le temps
++
Marsh Posté le 03-05-2010 à 08:51:02
Me revoilà de bon matin ! Une fois la reconstruction et le formatage terminée, voici les résultats surprenant :
Citation : SERVEURhome/flust# cat /proc/mdstat |
malheureusement, en démarrant mon serveur ce matin, je n'avais plus les même résultats (ci-dessous), je tente encore un formatage en ext3 et je vais faire comme tu me l'indique, changer de distribution et m'orienter vers Ubuntu dès ce soir.
Citation : |
EDIT :
Suite à un formatage en Ext3 les résultats sont encore plus décevant :
Citation : SERVEURhome/flust# blockdev --setra 16384 /dev/md0 |
Dès ce soir je tente Ubuntu ... je vous tiens au courant et je garde espoir !
Marsh Posté le 03-05-2010 à 18:28:21
mlevain a écrit :
|
mlevain a écrit :
|
Marsh Posté le 03-05-2010 à 21:54:16
Rassure toi je n'y comprends rien non plus, j'ai télécharger le DVD de Ubuntu pour changer de Debian, lors de l'installation il ne détecte plus mon disque sur lequel était Debian ... je retélécharge l'image... ca comment bien :-) je vous tien au courant dès que mon raid 5 sous Ubuntu sera sur pied
Marsh Posté le 18-05-2010 à 15:37:07
Salut,
J'ai la même config :
- Pentium dual core E5200 (2.5Ghz)
- 4 Go DDR2 6400
- Carte mère Gygabite GA-G31M-ES2L
- 1x 80Go (pour DEBIAN)
- 3x 1 To Samsung 7200Tr/min
Je tourne en debian lenny + xen et je suis tout juste en train de syncro mon raid
Code :
|
Marsh Posté le 18-05-2010 à 15:52:54
Salut !
Pendant la synchronisation j'ai les meme performances, c'est une fois le RAID monté et partagé avec windows que je rencontre des problèmes de vitesse d'écriture et de lecture.
Je suis actuellement entrain de refaire mon raid sous Ubuntu, après avoir testé Mandriva 2010 et débian, je rédigerai les différentes étapes que j'ai suivis très prochainement, pour le moment sur ubuntu ca donne ca :
Citation : root@SERVEUR:~# dd if=/dev/zero of=/home/flust/RAID/test.bidon bs=4096 count=1000000 |
Ce qui est nettement plus intéressant que mes précèdent essais,
++
Marsh Posté le 18-05-2010 à 18:56:44
Code :
|
Raid 5 (géré par un dom0 paravirtualisé avec 128Mo de mémoire) formaté en xfs.
Combien tu fait sur un disque simple ? je tournais à plus de 100Mo/s de mon seven vers mon partage samba (utilisation max du réseau), maintenant je suis entre 70 et 80Mo/s...
Je viens de constater que le raid5 logiciel bouffe énormément de CPU sur ma config (donc sur la tienne aussi...).
Marsh Posté le 19-05-2010 à 08:30:09
Mes disques ont de bonnes performances, mais ca reste des 5400tr/min
Ce sont les modèle 1.5To WD 64mo de cache, lors de la reconstruction du raid ils affichent 95Mo/s donc c'est effectivement la vitesse qu'il peuvent atteindre. dès que mon nouveau raid est près je transmettrai les testes via le gestionnaire de disque de Ubuntu,
++
Marsh Posté le 19-05-2010 à 09:55:32
De mon coté, je vais tester le raid sur mon dom0 afin d'écarter tout problème de perf lié à la virtualisation.
Marsh Posté le 20-05-2010 à 13:34:09
Pour information voici les performance de mon RAID 5 :
Citation : root@SERVEUR:~# dd if=/dev/zero of=/home/flust/RAID/test.bidon bs=4096 count=1000000 |
++
Marsh Posté le 05-02-2011 à 01:53:00
mlevain a écrit : Salut !
|
Etant exactement dans le même cas et encore débutant au niveau Raid linux, est-ce que la fameuse rédaction des étapes promises sont disponibles quelque part?
Sur un une plateforme amd avec 3 WD 1.5To (5400rpm) en raid5, LVM et partition XFS en faisant attention (je crois) à faire correspondre les chunks sizes et le nombre de stripes, j'ai des vitesses de l'ordre de 115MB/s en lecture mais seulement 26MB/s en écriture, ce qui me semble tout de même un peu ridicule!
Les deux cores ne sont même pas maxed out, alors je vois pas vraiment où est le problème.
Merci encore pour toutes ces belles informations en tout cas!
edit:
bon en fait en changeant de carte mère et donc de proc (opteron 1.8ghz => core2duo a 3ghz, bus IDE sur pciEx au lieu de pci, etc) les perfs sont beaucoup plus normales, 160MB/s en écriture avec 8192 en stripe_cache_size. Je suppose que c'était un problème de bus sur la carte précédente.
Qu'est-ce que j'apprends en ce moment ...
Marsh Posté le 15-02-2011 à 15:08:34
Salut !
Effectivement je l'avais promise et je ne l'ai pas fait ... j'en suis désolé car aujourd'hui je ne m'en souviens plus vraiment et je n'ai pas trop le temps de me replongé dans les config de mon ancien RAID... et oui, aujourd'hui je tourne sous SYNOLOGY DS-1511+ ... une vrai bête en terme de performances mais à un prix exorbitant je l'avoue ! Ceci dit mon RAID sous Linux tourne encore, mais arrivé au 3/4 de remplissage ce dernier me posait vraiment de gros problème en lecture tout comme en écriture, pendant une copie par exemple je passais de 55Mb/s à 2 ou 3Mb/s !!! Du coup mon transfert de fichier prenait un temps fou ! Enfin bref, de l'histoire ancienne désormais pour moi :-)
C'était une bonne expérience lorsque mes moyens étaient limités,
Bonne continuation
Marsh Posté le 10-06-2012 à 10:28:18
Je déterre un peu le sujet, mais je tenais à remercier tout le monde pour ce poste qui m'a bien aidé.
J'ai une config en Atom D525 avec 1Go de RAM et 4 DD de 2To. Impossible de dépasser les 50Mo en lecture/écriture sur un RAID 5. J'ai changé les chunk size et rien n'y fait.
Bref, je suis parti sur un RAID 1 (2 x 2To) et les deux autres disques ne sont pas en RAID.
Pour info, je suis sous Debian x64. J'ai essayé la dernière version de FreeNAS (8.0.4-RELEASE-p2-x86) avec un RAID en ZFS... Ce n'était pas mieux.
Alors, peut-être que l'Atom n'est pas assez solide pour faire du RAID 5 logiciel (j'en doute, puisque le proc n'est jamais à donf). Par contre, je rejoins l'idée de zeflash, concernant la "qualité" des contrôleurs.
Sinon, petit info : Un Intel Atom D525 (ZOTAC MOT NM10-DTX F ATOM D525 WIFI DDR2 mini-DTX NM10) n'arrive pas à dépasser les 70Mo/sec en transfert réseau. Avec une AMD Fusion, j'arrive à plafonner le Gigabite soit 110 Mo/sec (bon OK normalement, c'est 120Mo/sec )
Marsh Posté le 12-06-2012 à 11:33:29
Reste aussi à tester avec une Debian plus récente (Wheezy), qui aura un noyau plus récent au passage (3.2), avec un lot d'amélioration non négligeable pour le file system, ainsi qu'éventuellement de meilleurs drivers réseau.
Marsh Posté le 12-06-2012 à 15:54:53
Ben, FreeNAS repose sur une BSD et le résultat n'était pas "probant"... Franchement, je ne comprends pas ce qu'il cloche.
Dans mon cas, chaque disque était dans les 100Mo/s. tu fais un RAID et hop, 50Mo/s (encore... ca descend avec le temps)...
Le processeur ne tourne pas à fond, la RAM est correcte...
Soit c'est logiciel, comme tu le disais dans ton message, soit les chipset SATA sont vraiment des merdes !
Marsh Posté le 12-06-2012 à 22:04:32
À tester avec un autre controleur SATA sinon, le chip merdique n'étant pas à exclure en effet.
Marsh Posté le 29-04-2010 à 18:24:24
Bonjour à toutes et à tous,
Je n'ai pas pour habitude de poster mes soucis... car généralement, je trouves des solutions sur les forums comme celui-ci !!! Mais la, je suis à court d'idées... je vais tenter de faire court,
Ma config :
- Core deux duo 5200 (2.5Ghz)
- 2 Go DDR2 6400
- Carte mère Gygabite GA-G31M-ES2L
- 1x 80Go (pour DEBIAN)
- 3x 1.5 To WD 5400Tr/min 64Mo cash
J'installe DEBIAN Je monte mon RAID 5 logiciel sans problème avec mdadm, je déplace sur mon RAID 2.6To de données a partir de windows 7 (bécanne en I7 GTX295 etc ca ne vien pas de là...) et d'un réseau GIGABIT doté de câble compatibles et supercopier m'annonce 24h !!! vitesse moyenne de copie : 25Mo/s la déception en image ICI
Avec la même configuration et Windows serveur 2008, un RAID 5 (seul différence : les disques formatés en NTFS) la vitesse de copie était de 80Mo/s en moyenne :-D
Vous vous demanderez pourquoi je ne suis pas resté tout simplement sous Windows ... et bien car ce dernière ne permet pas d'étendre un RAID 5 logiciel sans le casser et perdre les données, alors que GNU et Linux oui.
Que puis-je faire pour retrouver ces performance sous DEBIAN ?
Je tenterai bien de formater mon raid 5 en NTFS mais est-ce possible, comment faire, et est-ce que cela changera quelque chose ?
D'avance merci pour l'intérêt que vous porterez à mon appel a l'aide ...
Voici quelques info utiles tirées de DEBIAN :
SERVEURhome/flust# hdparm -Tt /dev/sdb
/dev/sdb:
Timing cached reads: 2492 MB in 2.00 seconds = 1245.70 MB/sec
Timing buffered disk reads: 296 MB in 3.00 seconds = 98.63 MB/sec
SERVEURhome/flust# hdparm -Tt /dev/sdc
/dev/sdc:
Timing cached reads: 2452 MB in 2.00 seconds = 1225.57 MB/sec
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.72 MB/sec
SERVEURhome/flust# hdparm -Tt /dev/sdd
/dev/sdd:
Timing cached reads: 2476 MB in 2.00 seconds = 1237.51 MB/sec
Timing buffered disk reads: 282 MB in 3.01 seconds = 93.60 MB/sec
RAID 5 :
SERVEURhome/flust# hdparm -Tt /dev/md0
/dev/md0:
Timing cached reads: 2492 MB in 2.00 seconds = 1245.50 MB/sec
Timing buffered disk reads: 472 MB in 3.01 seconds = 156.88 MB/sec
SERVEURhome/flust# hdparm -i /dev/sdb
/dev/sdb:
Model=WDC WD15EARS-00Z5B1 , FwRev=80.00A80, SerialNo= WD-WMAVU2167815
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
SERVEURhome/flust# hdparm -i /dev/sdc
/dev/sdc:
Model=WDC WD15EARS-00Z5B1 , FwRev=80.00A80, SerialNo= WD-WMAVU2630647
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
SERVEURhome/flust# hdparm -i /dev/sdd
/dev/sdd:
Model=WDC WD15EARS-00Z5B1 , FwRev=80.00A80, SerialNo= WD-WMAVU1324156
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
Message édité par mlevain le 29-04-2010 à 18:35:28