On Sun, 22 Dec 2002, Anne Possoz wrote:
> J'ai d'ailleurs �t� surprise car j'avais install� mon syst�me
> (redhat 7.3 up2date) sur 2 scsi syst�me en raid soft: sda et sdb.
> Puis j'ai connect� mon unit� de stockage qui a pris sda et mes
> 2 disques sont devenus sdb et sdc. Comment le syst�me s'en est sorti
> est encore pour moi un myst�re. Seul le swap n'�tait qu'� moiti�
> actif (celui du sda avait disparu).
C'est un bug du kernel de Linux, corrig� si tu installes `devfs'. Les
p�riph�riques prennent alors un nom �-la-UNIX, genre
/dev/bus/scsi/target0lun0
ou qqch comme �a, qui refl�te les ID SCSIs.
Une alternative est de n'utiliser que les labels de syst�mes de fichiers
dans /etc/fstab -- il faut alors un initrd (enfin je crois). C'est sauf
erreur ce que fait Red Hat depuis la 7.2.
Cf man 8 e2label; man 5 fstab
Enfin, on peut s'en sortir en n'ins�rant les nouveaux disques SCSI que
part num�ro croissant (on peut parfois m�me configurer un disque avec ID
!= 0 pour d�marrer avec certains BIOS, si n�cessaire).
> > blocks, soit avec des blocks de 512 bytes/secteur environ 2.1 TB.
>
> Divis� par 2 si le bit de signe est utilis�, ce qui semble bien le cas?
Calcul: (blockage � 512 bytes/block)
non sign�: 2^32 - 1 blocks == 2 TB
sign� (bug): 2^31 - 1 blocks == 1 TB
> kernel 2.4.18 plain redhat
Donc sur-patch�. Ce qui n'est pas la cause du probl�me dans ton cas,
cependant.
> Je vois ainsi comment cherche un informaticien...
C'�tait le but de la manoeuvre. Finalement, ce n'est pas si difficile et
on peut d�terminer tr�s rapidement la plupart des probl�mes. J'ajoute
aussi que si les types des variables utilis�s dans la division dans le
printf ne sont pas unsigned, il y aura d'autres probl�mes.
Dans d'autres logiciels plus complexe que le kernel (ceux �crits en C++
par exemple), on peut difficile retrouver aussi vite la r�ponse que l'on
cherche.
> Disk /dev/sda: 255 heads, 63 sectors, 160520 cylinders
> Units = cylinders of 16065 * 512 bytes
160520 * 16065 * 512 == 1'320'321'945'600 == 1.2 TB
donc fdisk et le kernel sont apparemment d'accord. Cela pourrait marcher.
Je ne le ferais qu'apr�s tests approfondis (y compris remplissage de tout
�a en donn�es et en fichiers).
> Ne dois-je pas configurer cela au niveau du hardware? Faire 2 slices
Oui. Dans la mesure de mes connaissances, je ne peux garantir aujourd'hui
que Linux peut supporter correctement un disque de plus de 1 TB (maximum �
1'099'511'627'264 blocks; prendre une marge).
En cons�quence je te conseille de couper ton RAID array en deux unit�s
logiques de 500 GB (ou une de 800 et une de 200 p.ex.). Que cela
corresponde � une cible SCSI (TARGET ID) ou � une unit� logique SCSI
(LOGICAL UNIT ID) n'est pas important (enfin si, dans ce dernier cas il te
faut un kernel qui supporte les LUNs).
Comment cela s'appelle dans la documentation de ton RAID mat�riel, je ne
le sais pas.
> Ou puis-je faire de mon raid hardware 2 disques raid?
C'est le principe.
> Qu'est-ce qui doit �tre fait au niveau hard et au niveau soft?
Au niveau soft, on peut ensuite utiliser ces deux disques de fa�on
totalement s�par�e (deux syst�mes de fichiers), ou les aggr�ger avec LVM
(avec le m�me risque en l'�tat que pr�c�demment), ou �ventuellement les
aggr�ger au niveau du syst�me de fichier.
Pour ce dernier point, certains fs sous *BSD permettent de faire quelque
chose comme:
mkfs.ffs /dev/sda # pas besoin de partitions
mkfs.ffs /dev/sdb
mount /dev/sda /data
mount --merge /dev/sdb /data
ce qui alloue certains des fichiers sur /dev/sda ou sur /dev/sdb. Je n'ai
pas tellement investigu� mais c'est probablement dans certains cas une
bonne id�e. Aucune impl�mentation n'existe sous Linux (on pourrait
bricoler mon `mfs' pour faire �a mais bon ...)
[ oui, je sais, j'ai tendance � d�river assez souvent sur des informations
non directement utilisables, mais bon, c'est le prix � payer pour
le support technique gratuit :->
]
> Oui. Mais la taille qui est vue n'est-elle pas la taille totale - le
> disque utilis� pour raid 5? En ce moment, au niveau hard, je lis un
> slice de 1259163 MB (ce que je vois bien comme 1.44*11/12).
La taille du disque de base de l'array RAID5 n'est pas vue depuis Linux,
c'est une co�ncidence que truncate(taille, 31 bits) donne cette valeur.
1'259'163 MB == environ 1.2 TB
Apparemment, chacun de tes 12 disques fait environ 120 GB de fa�on � avoir
12 disques == 11 `disque' donn�es + 1 parit� tournante, donc 11 x 120 GB
de capacit� == 1.3 TB. De �a j'ai envie de conclure que c'est un array
RAID IDE Transtec mais peut-�tre vais-je trop vite ? :->
Les conversions 1000 / 1024 marketing expliquent la diff�rence (ainsi que
peut-�tre quelques blocs d'information d'administration interne au RAID
array). (*)
PS: tu nous en dis plus sur tout �a: type de RAID array, type des disques
(IDE, SCSI, Fibre Channel; marque, taille) et prix ? :)
merci
(*) j'utilise en r�gle g�n�rale 1k = 1024, 1 M = 1024 * 1k, etc pour
la m�moire et le stockage, et 1000 pour les d�bits et la
t�l�communication.
1 TB stockage == 1099511627776 bytes
1 TB/seconde == 1000000000000 bytes / seconde
En r�gle g�n�rale, les constructeurs prennent la valeur la plus
avantageuse pour eux. Sur un TB, �a fait quand m�me pr�s de 10%
de diff�rence!
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
