bonjour
 
je viens de monter un NAS perso sous une Debian 6 x64 kernel 2.6.32.5
2 disques de 750Go en RAID1 pour les divers téléchargements
4 disques de 2To (samsung)en RAID5+Spare pour le stockage des données.
 
les disques samsung ont des secteurs de 4k j'ai donc du utilisé fdisk comme ceci:
 

 
 
et répéter la commande pour les 4 disques:
 
maintenant quand je liste les partitions:
 

 
 
j'obtiens ceci:
 

 
 
mais je trouve quelque chose d’étrange, j'ai 4 disques identiques, et quand je partitionne avec fdisk, il me sort des head et cylinders différents, vous trouvez ça normal?
je suis d'accord, sur sdc et sdd car tout est similaire, mais sde et sdf... WTF???
 
en utilisant un système de fichier ext4 avec les options par défaut un
 

 
 
me donne ceci:
 

 
pensez-vous que les débits sont bon?
 
et dernier point je souhaite mettre en veille les disques durs quand il ne sont pas utilisés
 
pour cela j'ai du faire ceci:
 

 
 
pour désactiver la gestion automatique de l'alimentation
 
puis:
 

 
 
pour fixer la mise en veille au bout de 10 minutes
 
cette méthode a très bien fonctionné pour ma grappe RAID1
mais ne fonctionne pas pour la grappe RAID5, je ne sais pas ce qui empêche la mise en veille des 4 disques, je pense avoir une piste qui mène vers minidlna, car il me semble que par défaut, il scanne les dossiers toutes les 15 minutes.
 
d'avance, merci pour votre aide.
 
A bientôt

Salut,
 
déjà, tes partitions ne sont pas alignées en 4K, en effet si tu étais alligné en 4k le premier secteur de chacune de tes partoche (avec le flag 0xFD) serait le secteur logique 8 et non le secteur logique 1 (la mbr étant le secteur logique 0).
 
Au niveau des découpages des secteurs physiques de 4K en secteurs logiques de 512, ton secteur physique 0 se compose des 8 premiers secteurs logiques, cad de 0 à 7, ensuite le secteur physique 1 se compose des secteurs logiques 8 à 15, et ainsi de suite...
 
Ensuite, pour retrouver la géométrie physique de tes disques, tu peux faire un hdparm -v , là tu pourra constater.
 
après, moi je te conseillerais, avec les raid mdadm, de faire la structure mbr sur le 1er disque, puis ensuite de la recopier sur les autres disques avec dd.
exemple :  
 

 
 
après tu fait un partprobe pour remettre à jour la liste de partoches dans /dev, puis tu peux ensuite créer le raid soft, même si les disques ont une geometrie physique différente, il garderont la même geometrie logique. Attention avec dd, ne te plantes surtout pas de destination (of=).
 
bref, le plus simple pour faire un align 4k : tu fais un fdisk -u -S8 /dev/sdc, le premier secteur par défaut sera le 8, après une fois la mbr crée sur le disque tu la recopie avec dd sur tous les autres disques du raid
 
Pour la mise en veille des disques qui ne se fait pas, ça doit venir de la gestion de l'ext4 par le kernel, vu qu'il fait des opé de lecture sur le journal toutes les 5s (impossible à changer), même à travers un raid mdadm ça empêche la mise en veille des disques.
 
Dernier point : le disque de spare c'est pas trop utile avec 4 disques, et ça consome trop d'espace proportionnellement à la taille de l'array, ça commence à être utile à partir de 6 ou 7 disques. Si c'est pour 4 disques, autant partir sur du raid6 directement, même capa, en cas de perte d'un disque tu retombe au niveau d'intégrité du raid5, bon par contre les perf' seront un peu en dessous.
 
 
dernier point vicieux ultra important : sur certaines mobo, les numérotations de port SATA peuvent être inversées, surtout sur les mobo avec 6 ports SATA, souvent l'inversion se fait entre les ports 2 et 3, que ce soit en mode IDE ou AHCI, ce qui donne la disposition suivante des disques vu par ton kernel:
 
SATA1: sda
SATA2: sdc
SATA3: sdb
SATA4: sdd
SATA5: sde
SATA6: sdf
 
le mieux est de revérifier les numéro de séries de tes disques, sur l'étiquette, et avec un hdparm -i , et de vérifier les positions physiques des disques, un raid 5 ne sert à rien si tu n'est pas en mesure de repérer facilement un disque physiquement en panne  

bonjour.
 
quelle mine d'information!!!
 
je n'ai pas bien compris l'histoire de "dd"
 
je résume:
 
mes 4 disques de 2To sont, sda, sdb, sdc, sdd,je dois créer une partition comme ceci:
 

 
puis faire ceci?
 

 
ensuite, je ne connais pas partprobe, comment s'en sert t'on?
 
pour l'histoire de mise en veille, c'est quand meme etrange, mes 2 grappes raid sont en ext4, la grappe raid1 se coupe bien au bout de 10 minutes mais pas la grappe raid5
 
et merci beaucoup pour la petite manip' pour reconnaittre les disques, je ne savais pas trop comment m'y prendre
 
 
 

voilà pour dd, c'est tout à fait ça
une methode plus élégante, pratique quand on a une tonne de disques :
 

 
   
 
partprobe c'est juste une commande à taper sans options, qui permet de recharger les nouvelles mbr sans avoir à s'enmerder à rebooter, c'est tout.
 
Pour la veille, alors là je sèche par contre, les disques qui doivent passer en veille c'est plus trop mon segment  
 
Pour encore améliorer ton raid5 tu peux :
 
1/ ajouter un bitmap interne (éviter de devoir faire une resync du raid5 en cas de panne électrique/kernel panic/plantage divers), en gros c'est une journalisation du raid (fonctionne pour tous les niveaux redondants), il suffit d'ajouter --bitmap=internal lors d'un --create (donc à la création) ou de l'ajouter ultérieurement avec un --grow

Pour supprimer le bitmap : --bitmap=none (utile dans les manip' grow qui nécessitent d'ajouter un disque dans le raid ou encore de changer la taille des disques)
On ne dirait pas comme ça, mais sur une grappe raid de cette taille c'est un gros gain de temps en cas de pépin : pas besoin d'une nuit à attendre avec la resync derrière qui plombe complètement les perf', là même si tu plante ta machine, ça repart immédiatement. C'est rare de foutre par terre une machine linux, mais si ça doit arriver et que tu as un raid de 4*2To à resync, tu risque de trouver le temps long    
 
2/Utiliser un autre layout, par défaut, c'est du left-symmetric, à force de tester j'ai fini par déterminer que dans la grande majorité des cas, le right-assymetric est un poil moins performant en lecture mais aussi plus performant en écriture, hors sur un raid5 ou 6 soft c'est vraiment l'écriture le gros point noir, donc c'est toujours ça de prit. Les gains sont de l'ordre de 10 à 15Mo/s, mais sur un raid5 soft en écriture c'est plutot énorme.
 
donc là pas de secret, il faut ajouter un --layout=ra quand tu fait ton --create
ça se vérifie soit en faisant un mdadm -E /dev/sda1 (par exemple) où le layout est donné
ou si tu fais un cat /proc/mdstat, tu as une indic de layout (un nombre allant de 0 à 3)
0: left-asymmetric (--layout=la)
1: right-asymmetric (--layout=ra)
2: left-symmetric (par défaut si on n'indique rien au cours du create, le --layout=ls est implicite)
3: right-symmetric (--layout=rs)
 
 
exemple qui résume tout, niveau syntaxe :

tu as l'air de vraiment maitriser le sujet!
 
je vois dans ta derniere commande que le chunk est- a 128, c'est le meilleur a ton avis?
 
sur le raid que j'ai actuelement, il est a 512k
 
aussi, que penses tu du superblock persistant? utile/futile?
 
j'avoue que je suis perdu dans toutes ces options ^^
 
edit: je viens de faire le fdisk -u -S8 /dev/sda et ca me sors ceci:
 

 
est ce bon??

Alors, je vais te répondre dans l'ordre, à toutes ces question que je me suis posé il y a quelques années en fait ^^
 
 
Le chunk size, c'est très variable, ça dépend du type d'utilisation que tu veux faire de ton raid, pour du stockage il vaut mieux avec un chunk size assez important (128/256/512 voire 1Mo), pour un OS ou de la virtualisation, il vaut mieux baisser le chunk size (là ce sera plus avec du raid hardware déjà), quand tu as une carte raid à 600€ tu peux te permettre par exemple des strip de 16Ko    
on va dire que sans ça, "petit" ça va être de l'ordre de 32/64, en dessous il faut un co-processeur dédié, donc du raid hardware.
 
Le superblock persistant : en fait il l'est par défaut sur les version récentes de md, de toutes façons il est obligatoire pour quelque chose de solide, faire sans signifie de passer par un fichier de conf pour assembler le raid au démarrage (en fait utilisation obligatoire de /etc/mdadm.conf), bref, garde par défaut, c'est déjà nickel comme ça
 
Là sur ton fdisk actuel : non ça ne va toujours pas, tu as 1 à la colone start, il faudrait 8 pour être en alignement 4K, en gros l'idée quand tu fais un fdisk -u -S8 /dev/sdX c'est de refaire la partoche aussi dans la foulée, actuellement ta geometrie a changé (tu vois bien les 8 secteurs par pistes), en gros l'idée de base ça va être de faire en sorte que un piste logique = 8 secteurs logiques = 1 secteur physique, comme ça pas d'erreur possible. Les programmes de partitionnement comme fdisk ou parted manipulent des secteurs logiques, donc il faut en tenir compte.
En fait actuellement ta partoche Linux raid commence juste après la mbr, et dans l'idéal il devrait y avoir 7 secteurs libres entre la mbr et le premier secteur de cette partoche.
 
en fait tu devrais avoir ceci :
 

 
 
Je te conseille de toujours regarder avec un fdisk -lu /dev/sdX, plus précis (-u : units - précise d'afficher avec l'unité de base en secteurs et non en cylindres logiques, beaucoup plus précis, obligatoire pour faire un alignement), c'est aussi visible avec un parted /dev/sdX unit s print free

bien bien bien

je viens donc de supprimer la partition de sda puis la recréer avec:

puis option: n
                p
                1
                t
                fd

ce qui me donne ceci:

donc maintenant cela semble correspondre a ce que tu décris ci-dessus!

je pense donc partir pour un chunk de 512, ça me semble être pas mal pour une grappe qui stock des films des photos et de la musique

voilà, tout est nickel maintenant, pour de gros fichiers qui ne subissent pas d'écritures internes concurentes en permanence, le mieux c'est 256 ou 512 pour le chunk size.

j'ai bien lancé ta commande, mais j'ai l'impression que sdd a un probleme!
 

 
qu'en dis tu?

ouaip c'est super bizare
 
ok, il faudrait essayer de suprimer les superblocks persistants md et réessayer.
Auttre truc: je constate que ta grappe est passé en read-only
 
essayes ceci :
 

 
 
si jamais le problème persiste encore, alors c'est que la grappe est créée automatiquement en ro (là je ne vois pas pourquoi), à ce moment là il faudra jetter un coup d'oeil sur les options de read-only. A la limite, il faudra aussi regarder dans /etc/mdadm.conf

j'ai fais ce que tu m'as dis, mais rien de mieux...

                                                           
                   
ca viens peut etre du fait que j'ai fait plein de bidouuilles avec mdadm?
la config n'est peut etre pas tres propre...

le mdadm.conf:

je ne sais pas sur quelle distro tu es, mais normalement avec des superblock persistants, ce fichier n'est pas nécessaire (c'est pour ça que je tourne sans d'ailleurs... ça évite les soucils de conf)
 
A priori je vois que tu es sur debian, ça fait très longtemps que j'ai pas touché à debian (genre plus de 3 ans)

je suis bien sous debian en effet!
le fichier a eté crée tout seul a l'install de mdadm je pense
 
edit: je viens de reinstaler completement ma debian (j'avais fait plein de test, donc install pas propre)
et j'ai toujours le meme resultat apres avoir refait les manip
 

 
je ne comprend pas, on dirait qu'un disque est en spare....

up???

J'ai l'impression que le fichier de conf pose pb
déjà, md1 (j'imagine que tu as installé le système sur md1) n'apparaît pas dans mdadm.conf
 
tu devrait tester sans le fichier de conf (tu renomme mdadm.conf en mdadm.conf.old par exemple), tu reboot, et après on voit, déjà le auto-read-only par défaut ça me paraît assez louche....

re!

je viens de renomer le fichier mdadm.conf

puis j'ai reboot la machine

ensuite, j'ai supprimé les partitions des disques avec l'option "d" de fdisk
puis, recrée les partition avec la commande que tu m'as donné

puis j'ai tapé cette commande:

maintenant quand je fait un

voici:

ou alors un

donne ceci

j'ai donc toujours le meme probleme, ce put*** de sdd1 qui se colle en Spare....
je ne comprend pas pourquoi, a l'origine du post, je t'avais dis que j'avais un disque de spare, et bien c'etait celui-ci, le sdd, mais la, apres tous les fdisk etc etc, je ne comprend pas pourquoi il me le met encore a cet endroit... comme si il avait retenu la toute premiere config'

je suis perdu, et je commence a ne plus trop y croire

tu avais essayé avec le --zero-superblock ?
 
Ok, sinon méthode radicale : suppression des partoches et surtout du superblock md avec un coup de dd  bien placé :
 
 

 
 
puis tu reboot et rebelotte      
fdisk -u -S8 /dev/sda / n, p, 1, 8, [enter], t, fd, w / for y in /dev/sd[b-d];do dd if=/dev/sda of=$y count=1;done / partprobe / mdadm --create /dev/md0 --level=5 --chunk=512 --layout=ra --bitmap=internal --raid-devices=4 /dev/sd[a-d]1

bon je me lance!

j'ai bien sur fais a chaque fois le --zero-superblock...

la premiere partie, je l'ai mis dans un fichier executable nommé script, puis je l'ai executé:

par contre la deusiere ligne de commande, c'est a mettre aussi dans un script?
sinon, partprobe n'est pas d'origine dans debian 6, il fait partie du packet parted, je l'ai installé

je vais maintenant rebooter la machine pour faire la suite de ton explication

ok, je vois que ça avance.
 
Bon, croises les doigts    
on verra bien, c'est possible qu'un le superblock md de la grappe précédente pose des pb effectivement, après une manip' pareille il ne doit pus rien rester  

mes disques ont changés suite a une modif dans le bios( sd[c-f] maintenant)

bon,voici la suite des évènements:

création de la partition

puis, je lance le script qui copie la table de partition sur les autres disques:

maintenant, partprobe + mdadm

j'affiche les details de mdadm:

j'ai l'impression que c'est la même chose que tout a l'heure... je sens que je vais pleurer...    

p.s: pour le read-only, c'est pas grave apparement:

"Hi,

this is not a bug. Raid arrays marked as auto-read-only will
automatically switch to read-write on first write.

Thorsten"

trouvé sur un forum debian

la modif dans le bios, c'est pas un passage de IDE à AHCI (ou l'inverse) ?
ce qui détermine l'ordre des disques avec ce genre de changement, c'est l'ordre de chargement des modules des contrôleurs inscrit dans le script init du initrd
(très pratique de le changer quand tu as un contrôleur raid hardware par exemple et que tu veux absolument faire passer son/ses VD avant des disques SATA   )
 
ouais bizare ce bug sinon, par contre ça n'explique pas pourquoi le dernier disque est toujours en spare, ça donne quoi un mdadm -E /dev/sd[c-f] ?
(-E = --examine)
 
parceque c'est bizare d'avoir un disque en spare alors que la grappe est affichée en 4 disques   (normalement les disques de spare ne rentrent pas dans le comtpe)

oui, je suis passé de AhCI a IDE, voir si le probleme n'etait pas d'ici
 
j'ai aussi lu qu apres une resync, certaines personnes ont vu leur disque spare disparaitre au profit d'un disque dans la grappe
mais je ne sais pas comment forcer une sync
 
aussi, je suis en train de formater /dev/md0 en ext4 voir si ca change quelque chose
 
je te donne le resultat de mdadm -E /dev/sd[c-f] des que j'ai la main

voila le resultat:
 

 
tu vois, apres le:
 

 
l'array n'est plus en read-only, je vais voir apres le resync si le disque de spare disparait....
 

 
euh! auto-correction:
il semble que ca soit bon la...
 

 
diable est ce que ca serait bon???

ah oui en fait c'est un mdadm -E /dev/sd[c-f]1 qu'il faut faire, oubli de ma part    
On va toujours voir du côté des superblock md, au détail, disque par disque
 
après il y a peut-être un problème venant de la bitmap, tu pourra toujours la virer pour voir (mdadm -G /dev/md0 -b none)
 
 
EDIT : j'ai rien dit, c'est bon \o/
 
ok, donc en fait sur cette implémentation de md là, le rebuild commence à la première opé d'écriture, ok, bon à savoir  
 
Là pour le moment ça se présente bien ton affaire
à la fin, sdh1 devrait passer en active sync normalement, plus que 5 petites heures de suspens  

j'ai pas compris ce que tu insinue par "l'oublie de ta part"
 
en effet, il fallait le savoir que ce mdadm était aussi tordu...
 
je te tiens au courant des que les 5 loooooooongues heures se seront ecoulées

 
En fait j'avais inscrit /dev/sd[c-f] au lieu de /dev/sd[c-f]1  
et forcément, md il n'y pige plus rien, si on ne lui indique pas les bons blockdevice

bon ben ca semble plutot pas mal...
 

 
maintenant il me reste a faire la meme avec mes 2 disques en RAID1...

Ok, nickel
 
Pour le raid1, rien de sorcier : mdadm --create /dev/md1 --level=1 --bitmap=internal --raid-devices=2 /dev/sd[ab]1
 
Le système tu l'as installé où ? il y a moyen d'installer le système sur du raid1 soft, mais également sur du raid0, raid5, raid6 (+ raid10 et raid4 pour les tarés mais ça demande de la grosse bidouille)

je l'ai installé sur un disque externe en USB2
donc pas de souci de ce coté
 
je vais essayer de comprendre un peut pour quoi le fait de faire commencer la partition a 8 aligne les secteur sur 4k, a moins que tu as plus d'explications a me donner, bien sur ^^

c'est juste un modulo, 8 secteurs logiques = 4Ko. Comme le kernel et les programmes de partitionnement sont prévu pour fonctionner sur des secteurs logiques de 512, et que les secteurs physiques font 4Ko, tu as des secteurs physiques qui sont donc découpés en 8 secteurs logiques. Si tu veux commencer un volume sur le début d'un secteur physique et non en plein milieu (=aligner, c'est juste ça l'allignement, en fait), tu dois donc choisir un secteur logique multiple de 8 différent de 0 (cad 8, 16, 24, 32, 48, 56, 64, etc...).
Si tu commences sur le secteur logique 1, 2, 3, 4, 5, 6 ou 7, tu sera toujours sur le secteur physique 0, que tu entamera en plein milieu, si tu créer un système de fichier là dessus, les blocs des systèmes de fichier seront aussi décalés par rapport aux secteurs physique, c'est pour ça que je t'ai dis de commencer à 8.
En terme de taille, dans ton cas un bloc ext2/3/4 fait par défault 4Ko, donc un bloc ext = 8 secteurs logiques = 1 secteur physique
 
C'est pareil avec les alignements de raid hardware (attention, ça ne concerne absolument pas les raid software sur disques avec secteurs de 512), si par exemple tu fais un raid0 hardware avec un chunk size de 32Ko et que tu veux faire un alignement, il faudra laisser les 32 premiers Ko libres, soit les 64 premiers secteurs (plage 0-63) et commencer sur le 65eme secteur (le secteur n°64).
Comme tous les comptes commencent à 0, en fait le premier secteur est bien le n°0
 
Les secteurs de 4Ko des disques 4Ko ou des SSD se gèrent exactement de la même façons qu'un alignement de raid (hardware).
 
L'autre solution d'alignement systématique, c'est celle employée par microsoft depuis vista, la solution de facilité : laisser le premier Mo libre (les 2048 premiers secteurs logiques, donc de 0 à 2047) et commencer la première partoche sur le secteurs 2048. ça fonctionne à tous les coups parceque n'importe quelle taille de secteur physique ou de chunk size est un sous-multiple de 2048. C'est efficace vu que ça fonctionne dans tous les cas (le plus gros chunk size existant sur raid hardware étant 1Mo). Il me semble que dans les releases récentes de distro comme ubuntu ça se passe aussi comme ça.

super, merci pour les explication, c'est plus clair maintenant!
 
j'ai un nouveau probleme avec le raid1 cette fois ci:
 

 
et au reboot suivant:
 

 
le raid1 a disparu,      

ok, fais déjà un mdadm -E /dev/sd[ef]1
 
si tu n'as pas de résultats, alors c'est que les superblock de md1 sur sde1 et sdf1 ne sont pas persistants, pas assemblés au démarrage ? (pourquoi ? mauvais ordre de chargement des modules dans le initrd ? bug dans la distro ? mystère)
Ou sinon, il y a peutêtre besoin d'un fichier de conf mdadm.conf, dans ce cas autant en refaire un proprement :
 
donc, /etc/mdadm.conf

 
après avoir écrit le fichier, tu peux recharger la bonne conf sans reboot avec un mdadm --assemble, tu vois tout de suite si ton raid1 est assemblé ou non, si oui tu reboot pour voir s'il est bien réassemblé automatiquement. Après à mon sens, il n'est pas normal -ni logique- que le raid5 soit persistant mais pas le raid1  

héhé t'es trop fort!!!
 
avant de lire ta reponse, j'ai passé un:
 

 
et au reboot suivant, le raid1 était la!
 
par contre ta commande ne me retourne rien sur le raid1:
 

 
bizare quand même...
 
 
 

ouais, plus que bizare, il te retourne des infos liées au raid5
 
oui particularité que j'ai remarqué sur mdadm : il n'aime pas trop les changements de nom des block device : c'est écrit en dur dans les superblock des même device. Je n'ai pas encore personellement rencontré de pb avec ça jusque là, ais toi il me semble que c'est le cas là ^^
Essaye de rechanger de mode ton contrôleur de disque (celui avec les 4 disques en raid5) pour les repasser sur les nom qu'ils avaient au moment de la création du raid et recommences ton raid1

ca a l'air d'etre bon maintenant:
 
info sur les disques en RAID1
 

 
info sur les disques en RAID5:
 

 
aurais-je fini avec mdadm????

ça y ressemble bien en effet