Blocage au redémarrage d'IPCOP

par **only** » 28 Jan 2010 14:56

Bonjour à tous,

Je cherche une explication sur une version 1.4.21 + BOT + advanced Proxy etc ..

Après l'installation de la mise à jour 1.4.21 de BOT + Netraffic + Advanced Proxy, Filtre URL etc ...

Au redémarrage le système se bloque à " setting bringing wireless rules" ...

Rien .. même après 10 minutes d'attente

Je dois faire un arrêt froid de la machine pour avoir un boot normal et ensuite tout fonctionne correctement en SSH et en HTML

HARDWARE de base sous ATHLON carte mère de base 1 disque SATA MAXTOR 1 go de RAM dans chassis industriel ... rien d'exceptionnel

J'ai donc X machines à faire ... je gère un "dd if of "sur mes disques MAXTOR sans problème avec une machine de prod ... le dd fonctionne parfaitement

Mais le redémarrage plante ....

Je continu à chercher ... je pense à une incompatibilité hardware mais je suis en sda bs=8225280

Merci pour vos lumières ...

par **jdh** » 28 Jan 2010 20:15

Même remarque que sur autre fil :

- attention à "dd", il faut préférer des commandes tar imbriquées
- je préconise de réinstaller grub par "grub-install" (ou boot par supergrub) pour assurer un loader opérationnel.

par **Franck78** » 28 Jan 2010 22:50

8225280 ? Et bien, moi qui en est lancé un avec 'bs=1k' pour un raid de 60go recopié sans problèmes en trois heures... D'ou tu sort cette valeur??

par **jdh** » 28 Jan 2010 23:14

Un bs=8225280 est assez logique avec un disque de 255 têtes (heads) x 63 secteurs (secteurs) ce qui devienat assez standard avec des disques sata de grande capacité.

Cela donne des cylindres de 255x63x512 = 8225280 octets ce qui me semble très logique d'utiliser comme valeur de bs pour la commande "dd" (du coup count vaut le nombre cylindre !).

par **only** » 06 Fév 2010 20:07

Il suffit de faire un fdisk /l pour connaitre les valeurs des disques à dupliquer.

Le BS y est indiqué en nombre de bytes.

Bien à vous

par **Franck78** » 08 Fév 2010 22:08

le calcul est bon, certe, mais l'utilisation me semble idiote.

le bs (block size) sert a optimiser la lecture (ou l'écriture) quand il s'agit de copier un disque.

Lire d'un coup en nombre d'octet "logique" n'a pas de sens pour la mécanique interne du disque.

Pour le sata, je n'en ai pas pour essayer.

En tout cas, j'ai essayer sur une HP/G3 carte smart array 642

bs=1k => 7Mb/s
bs=2k => un peu plus (genre 9)
bs=4k => 14
bs=8k => 15 Mb/s
bs=16k =>15.5 Mb/s
bs=32k =>14

J'ai pas poussé plus loin mais un trois test (avec un count=donné pour copier 300Meg) , quand j'ai refait une copie des disques scsi, je suis passé de trois heures à 40 minutes.

Il est clair qu'il y avait une nombre d'octet adapté pour remplir correctement les buffers du systeme.

par **jdh** » 09 Fév 2010 01:33

@Frank78 :

Je reconnais là ta précision habituelle.

Il est parfaitement clair que les systèmes disque, étant des périphériques de type block (b et non c), sont organisés pour traiter 1 ou des secteurs, qu'ils utilisent des buffers pour anticiper des lectures (à la manière du très vieux smartdrv.sys). Par conséquent, il est utile d'utiliser un "bs" adapté à l'image de "hdparm -m"

Il est clair qu'il faut commencer par hdparm quand on veut regarder les perfs disques (particulièrement hdparm -t).

L'intérêt d'utiliser 8225280 est que le count devient le nombre de cylindres ! Mais c'est surement pas optimal !

Blocage au redémarrage d'IPCOP

Blocage au redémarrage d'IPCOP

Qui est en ligne ?