RAID sur du HP : activation (ou non) du write cache

Le Thu, 17 Jan 2013 03:49:00 +0100, Francois Lafont a écrit:

Comme vous pouvez voir, ça va plus vite sans le "write cache" qu'avec.
Est-ce normal ?

Non, c'est même exactement le contraire de ce qu'on attendrait
(normalement ça va 5 fois plus vite avec cache que sans). Bizarre.

--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Kaid Ahmed.

je ne suis pas spécialiste en raid, mais j'ai 2 ou 3 remarques:

- sur une grosse copie (6,3Go dans ton exemple) en un seul tenant, je
doute que le cache apporte quelque chose.
Il va être presque immédiatement saturé et donc sans aucun effet.


- le débit de ton raid de 4 disques me semble ridiculement bas. il
devrait être *au moins* 5 à 6 fois supérieur.
(il me semble que tu en avais déjà parlé)
je pense que ton problème de cache viens de la.
Si tu n'avais pas une carte raid, on pourrait penser que tes disques
sont en mode PIO 4

- je vois aussi une ligne:
SATA NCQ Supported: False
ca me semble pas très important, mais sur des accès multiples ca aide
un peu.

- tu ne dis pas si en lecture les débits sont du même ordre?

- je sais bien que tu as les mêmes résultats sur les machines qui n'ont
pas de 'low battery', mais j'espère que tu ne fais les tests que sur
les machines avec une batterie ok.
Si a un moment tu trouves une solution et que la batterie déchargée
empêche cette solution de marcher, tu ne le saura jamais... :-)

As-tu essayé de refaire tes tests depuis un autre système (un live dvd
avec une distrib récente autre qu'une debian pure et un noyau plus
récent par exemple)?
J'ai déja remarqué des différences de vitesses très marquées entre une
distrib basée sur une ubuntu 8.04 serveur (a jour) et un livecd
clonezilla récent (avantage très net à clonezilla)

Thierry

Bonsoir,

Le 18/01/2013 00:29, Th.A.C a écrit :

- sur une grosse copie (6,3Go dans ton exemple) en un seul tenant, je
doute que le cache apporte quelque chose.
Il va être presque immédiatement saturé et donc sans aucun effet.


- le débit de ton raid de 4 disques me semble ridiculement bas. il
devrait être *au moins* 5 à 6 fois supérieur.

Oui, sûrement. Avec ces serveurs, j'ai un mal fou à avoir des perfs ne
serait-ce que potables. Et je ne trouve pas beaucoup d'info sur le Web
concernant des tentatives de mettre une Debian sur ce modèle de machine.

- tu ne dis pas si en lecture les débits sont du même ordre?

C'était plus ou moins l'objet d'un fil précédent où j'essayais d'obtenir
des perfs à peu près potables en lecture.

--------------------------------------
# hdparm -tT /dev/cciss/c0d{0,1}

/dev/cciss/c0d0: # Lui ça correspond aux 4 disques du serveur
Timing cached reads: 1316 MB in 2.00 seconds = 657.59 MB/sec
Timing buffered disk reads: 444 MB in 3.02 seconds = 147.14 MB/sec

/dev/cciss/c0d1: # Ça c'est la baie SAS
Timing cached reads: 1274 MB in 2.00 seconds = 637.28 MB/sec
Timing buffered disk reads: 684 MB in 3.00 seconds = 227.68 MB/sec
--------------------------------------

Pas fameux non plus n'est-ce pas ? C'est globalement le mieux que j'ai
réussi à avoir (voir un long fil précédent).

- je sais bien que tu as les mêmes résultats sur les machines qui n'ont
pas de 'low battery', mais j'espère que tu ne fais les tests que sur
les machines avec une batterie ok.
Si a un moment tu trouves une solution et que la batterie déchargée
empêche cette solution de marcher, tu ne le saura jamais... :-)

Oui, tu as raison j'en prends bonne note pour la suite.

As-tu essayé de refaire tes tests depuis un autre système (un live dvd
avec une distrib récente autre qu'une debian pure et un noyau plus
récent par exemple)?
J'ai déja remarqué des différences de vitesses très marquées entre une
distrib basée sur une ubuntu 8.04 serveur (a jour) et un livecd
clonezilla récent (avantage très net à clonezilla)

Oui, effectivement. D'ailleurs, en gros, à chaque fois que j'ai eu des
perfs vraiment meilleures, c'est en essayant un noyau plus récent. Pour
un noyau donné, des bricolages ont permis parfois de grapiller un peu de
perfs mais globalement le seul truc qui a été vraiment probant c'est un
changement de noyau et c'est d'ailleurs pour ça que j'avais installé une
Squeeze avec un noyau backporté.

À l'occasion, j'essayerai la dernière Ubuntu server (12.10 qui utilise
un noyau 3.5 il me semble) sur ce serveur.

Ce qui m'énerve dans cette histoire c'est que je n'ai pas de piste de
recherche. En général quand on a un souci sous Linux, on va farfouiller
dans des logs (avec plus ou moins de réussite mais au moins on a des
infos, des pistes à creuser etc.) mais là je n'ai nulle part où
farfouiller et donc pas la moindre piste de réglage à faire.

Juste pour info, je vous copie-colle un morceau de la page d'aide de
l'utilitaire qui me permet de contrôler de contrôleur RAID. Inutile de
vous dire que j'ai déjà essayé de bidouiller pas mal de choses sans
succès. Peut-être que ces paramètres vont interpelleront...

(désolé, j'ai la flemme de remettre en ordre les sauts de lignes).

---------------------------------------------------------
The modify command changes the existing configuration. Where allowed,
the '?' keyword queries the current capabilities. Only one query can be
issued at a time.

<target> modify [arrayaccelerator=enable|disable]|[caching=enable|disable]
Enables or disables the caching for a given logical drive. The target
can be any valid logical drive target on a controller that supports
caching management.

<target> modify [cacheratio=#/#|?]
Sets the cache ratio for the controller. The first # is the read cache %.
The second # is the write cache %. The target can be any valid
controller.

<target> modify [chassisname="ABC"]
Sets the chassis name of the controller. If the chassis name has a space
character in it, the chassis name needs to be enclosed in double quotes,
e.g., chassisname="Free Bird". Reset the back to the default by specifing
chassisname="". The target can be any valid controller target that
supports
a chassis name.

<target> modify [chassisslot=#|?]
Specifies the preferred path logical drives that map to a given
controller
supporting active active redundancy. To force the controllers to only use
their preferred logical drive paths, preferred path mode must be set to
manual. The chassis slot keyword is something that only exists on
redundant
controllers. To see the chassis slot numbers, use the show command on a
controller that supports redundant controllers. The target can be any
valid
logical drive on a controller that supports active active redundancy.

<target> modify [preferredpathmode=automatic|manual|?]
If preferred path mode is set to manual, all I/O traffic to the logical
drive(s) will be directed through the preferred controller for that
logical
drive. Setting the preferred path mode to automatic allows the storage
system to change the preferred path to logical drives based on host I/O
patterns. The target can be any valid controller that supports redundant
controllers.

<target> modify [redundantcontroller=disable]
Disables the redundant controller. The redundant controller cannot be
re-enabled. The target can be any valid controller that has an enabled
redundant controller.

<target> modify [drivewritecache=enable|disable|?] [forced]
Enables or disables the physical drive write cache for the
controller. The
target can be any valid controller target that supports drive write
cache.

<target> modify [expandpriority=high|medium|low|?]
Sets the expand priority for the controller. The target can be any valid
individual controller target.

<target> modify [size=#|min|max|maxmbr|?] [forced]
Extends the logical drive to the specified size. The implied units
are MB.
max will extend the logical drive to its maximum size. maxmbr will
extend to
the maximum size the master partition table allows. The target can be any
valid logical drive.

<target> modify [led=on|off][duration=1-86400]
Flashes specified device's LEDs. An optional duration parameter may be
specified. Range is from 1 to 86400 seconds. Default is 3600. The
target can
be any valid individual device target.

<target> modify [drives=[#:]#:#,[#:]#:#,[#:]#:#-[#:]#:#],...]
Specifies the drives to be used for replace existing drives on an
array. #:#
is SCSI port:id or box:bay, depending on controller type. Some
controllers
may also support port:box:bay. Moving an array to a different drive
type is
now supported. The target can be any valid individual array or
logicaldrive
target.

<target> modify [spares=[#:]#:#,[#:]#:#,[#:]#:#-[#:]#:#],...|none]
Specifies the drives to be used for spares on an array. #:# is SCSI
port:id
or box:bay, depending on controller type. Some controllers may also
support
port:box:bay. The target can be any valid individual array or
logicaldrive
target.

<target> modify [drives=[#:]#:#,[#:]#:#,[#:]#:#-[#:]#:#],...]
[spares=[#:]#:#,[#:]#:#,[#:]#:#-[#:]#:#],...|none]
Specifies the drives to be used to replace drives and spares on an array
(Drive Movement). #:# is SCSI port:id or box:bay, depending on controller
type. Some controllers may also support port:box:bay. The target can
be any
valid individual array or logicaldrive target.

<target> modify [newarray=]|[drives=[#:]#:#,[#:]#:#,[#:]#:#-[#:]#:#],...]
Specifies an existing array to move the targeted logical drive to, or
specifies the drives to be used to create an array. #:# is SCSI
port:id or
box:bay, depending on controller type. Some controllers may also support
port:box:bay. The number of physical drives in the new array must be the
same as the number of physical drives of the current array that the
logical
drive belongs to. In combination with the 'drives=?' option, the
'drivetype=' option can be used to query the available drives by
drivetype.
The target can be any valid individual logicaldrive target.

<target> modify
[drives=[#:]#:#,[#:]#:#,[#:]#:#-[#:]#:#],...][modifyparitygroup
s=yes|no]
Specifies to move/replace one or all of the drive(s) of an existing
array.
#:# is SCSI port:id or box:bay, depending on controller type. Some
controllers may also support port:box:bay. In combination with the
'drives=?' option, the 'drivetype=' option can be used to query the
available drives by drivetype. Mixing of drive types is NOT allowed. The
target can be any valid individual array target.

<target> modify [raid=0|1|1adm|1+0|1+0adm|5|50|6|60|?]
[stripsize=8|16|32|64|128|256|512|1024|default|?]
Migrates the specified logical drive to the desired raid level and/or
strip
size. The implied units of stripsize are KB. The target can be any valid
logical drive.

<target> modify [rebuildpriority=high|medium|low|?]
Sets the rebuild priority for the controller. The target can be any valid
controller.

<target> modify [reenable] [forced]
Re-enables a failed logical drive. Re-enabling the selected logical drive
will allow the logical drive to be used again. Any previously
existing data
on the logical drive may not be valid or recoverable. The forced
parameter
represses the warning prompt. The target can be any valid logical drive.

<target> modify [adapterid|connectionname=#] [hostmode="ABC"|?]
Changes the host mode for a specified adapter id or chassis name. To
set a
host mode, a connection name must already exist. The target can be
any valid
controller target supporting hostmodes.

<target> modify [adapterid=#] [connectionname="ABC"]
Changes the connection name for a specified adapter id. The
connection name
can be reset back to the default by specifing connectionname="". The
target
can be any valid controller target supporting ssp.

<target> modify [ssp=on|off] [forced]
Turn SSP on or off. The target depends on whether your controller
supports
controller or logical drive centric SSP. For controller centric SSP,
specify
the controller. For logical drive centric SSP, specify the logical
drive. To
determine what type of SSP you have, use the show command on a controller
target supporting SSP.

<target> modify [mask|unmask=#,#,...|all] [forced]
Mask/unmask specified adapter id's or connection names for SSP. SSP
must be
enabled before mask/unmask can be set. To view available adapter id and
connection name options, see the show ssp command. # is the adapter id or
connection name. The target can be any valid logical drive.

<target> modify [surfacescandelay=0|1..30|?]
Sets the surface scan delay for the controller, where # is between 1
and 30
seconds. A value of 0 will disable the feature, causing the surface scan
mode to be set to Disabled.
The target can be any valid controller.

<target> modify [surfacescanmode=disable|idle|high|?]
Sets the surface mode for the controller. Can be disable, high, or
idle. If
idle is specified, a surface scan delay value must also be specified
The target can be any valid controller.

<target> modify [configurationmode=0|1|2|3|4|5|6|7|?]
Sets the configuration mode for the SEP. The target can be any valid SEP.

<target> modify [degradedperformanceoptimization=disable|enable|?]
Sets the degraded performance setting for the controller. The target
can be
any valid controller.

<target> modify [elevatorsort=disable|enable|?]
Sets the elevator sort for the controller. The target can be any valid
controller.

<target> modify [inconsistencyrepairpolicy=disable|enable|?]
Sets the inconsistency repair policy for the controller. The target
can be
any valid controller.

<target> modify [queuedepth=automatic|32|16|8|4|2|?]
Sets the queue depth for the controller. The target can be any valid
controller.

<target> modify [postprompttimeout=0|1..255|?]
Sets the F1/F2 POST prompt timeout for the controller during system boot.
The target can be any valid Smart Array controller.

<target> modify [mnpd=0-1440|?]
Sets the monitor and performance delay for the controller. The target
can be
any valid controller.

<target> modify [nobatterywritecache=enable|disable|?]
This option allows write caching to be enabled when a
battery/capacitor is
not present or fully charged. This setting affects all logical drives
created on the controller and there must be at least one logical drive
present before usage.

WARNING: Enabling write caching on a cache module without a fully charged
battery/capacitor could cause data loss in the event of a power failure.

The target can be any valid controller which supports this feature.

<target> modify [enableeraseddrive]
Enable the erased drive. The target can be any valid physical drive.

<target> modify [erase erasepattern=zero|random_zero|random_random_zero]
[deleteaftererase=yes|no]
Starts the drive erase process. The [deleteaftererase] option applies
only
to logical drives. The target can be any valid logical or physical drive.

<target> modify [stoperase]
Stops the drive erase process. The target can be any valid logical or
physical drive.

<target> modify [waitforcacheroom=enable|disable|?]
This option causes the controller to always wait for room in the
read/write
cache when full instead of automatically bypassing it in favor of higher
performance. Enabling this feature prevents RAID 1 inconsistencies that
occur whenever the host changes buffer contents during write operations.
This may however result in lower performance.

The target can be any valid controller which supports this feature.

<target> modify [surfaceanalysiseventnotify=enable|disable|?]
This option allows surface analysis inconsistency event notification and
serial debug messages to be generated for mirrored volumes.

The target can be any valid controller which supports this feature.

<target> modify [raid1writebuffering=enable|disable|?]
This option allows buffering of RAID 1 write requests to prevent
inconsistencies that occur whenever the host changes buffer contents.

The target can be any valid controller which supports this feature.

<target> modify [bootcontroller=enable|?]
This option sets the boot controller for the system. This option is only
avaiable in the offline environment.

The target can be any valid controller.

<target> modify [bootvolume=primary|secondary|none|?]
This option is used to designate primary and secondary boot logical
volumes
from local and remote logical volumes discovered by the currently
selected
controller. This option is only avaiable in the offline environment.

The target can be any valid logical volume.

<target> modify spareactivationmode=[failure|predictive]
This task allows the user to switch the spare activation mode of the
controller from the default behavior (activate on failure only) to
predictive spare activation and back.
The target can be any valid controller.

<target> modify consolidatespace
The consolidatespace command relocates the logical drives in the
array and
consolidate all the array free space to the end of the array. The
target can
be any valid array.

<target> modify disablepd
Disables (temporarily fails) the specified physical drive until
either a hot
plug event or a reset of the controller. The target can be any valid
physical drive.

Examples:
controller slot=3 logicaldrive 2 modify arrayaccelerator=enable
controller slot=3 logicaldrive 2 modify caching=enable
controller slot=1 modify cacheratio%/75
controller serialnumber=P21DA2322S modify chassisname="Lab B"
controller ch="lab 3" ld 1 modify chassisslot=1
ctrl chassisname="Lab B" modify preferredpathmode=manual
controller ch="lab4" modify redundantcontroller=disable
ctrl sn=P21DA2322S modify drivewritecache=enable
controller slot=5 modify expandpriority=low
controller slot=1 logicaldrive 1 modify size000
controller slot=1 array B modify led=on
controller slot=1 array B modify led=on duration`0
controller slot=5 array A modify drives=1:4-1:8
controller slot=5 array A modify spares=1:2-1:7
controller slot=5 array A modify drives=1:4-1:8 spares=1:2-1:7
controller slot=5 ld 1 modify newarray=C
controller slot=5 logicaldrive 2 modify drives=1:4-1:8
controller slot=5 ld 1 modify drives=? drivetype=sas
controller slot=5 array A modify drives=1:4-1:8 modifyparitygroups=yes
controller slot=5 array A modify drives=? drivetype=ss_sas
controller slot=5 array A modify drives=1:4-1:8 modifyparitygroups=yes
controller wwn=W4348483984 logicaldrive 1 modify raid=1 stripsized
controller slot=5 modify rebuildpriority=high
controller slot=1 ld 1 modify reenable
ctrl chassisname="Lab B" modify ai=P44940LDAORS4F hostmode=Windows
controller ch="Lab1" modify adapterid=P44940LDAORS4F connectionname="XP"
ctrl chassisname="Lab B" modify ssp=on
ctrl chassisname="Lab B" ld 1 modify unmask=P44940LDAORS4F,P42ASDASASDKHA
controller slot=1 modify surfacescandelay
ctrl slot=3 modify ssd=0

controller slot=1 modify surfacescanmode=high
controller slot=1 modify surfacescanmode=disable
controller slot=1 modify surfacescanmode=idle surfacescandelay=3
controller slot=5 sep 245 modify configurationmode=2
controller slot=5 modify dpo=enable
controller slot=5 modify elevatorsort=disable
controller slot=5 modify irp=enable
controller slot=5 modify queuedepth=automatic
controller slot=5 modify postprompttimeout
controller slot=5 modify mnpd`
controller slot=5 modify nobatterywritecache=enable
ctrl slot=1 modify nbwc=disable
controller slot=5 physicaldrive 1E:1:1 modify enableeraseddrive
controller slot=5 logicaldrive 1 modify erase erasepattern=zero
deleteaftererase=yes
controller slot=5 physicaldrive 1E:1:1 modify erase
erasepattern=zero
controller slot=5 logicaldrive 1 modify stoperase
controller slot=5 physicaldrive 1E:1:1 modify stoperase
controller slot=5 ssdpd all show
controller slot=5 ssdpd all show detail
controller slot=3 modify waitforcacheroom=enable
ctrl slot=2 modify wfcr=disable
controller ch="my_P600" modify surfaceanalysiseventnotify=disable
ctrl slot=5 modify saen=enable
controller slot=1 modify raid1writebuffering=enable
ctrl slot=5 modify r1wb=disable
controller slot=1 modify bootcontroller=enable
controller slot=1 ld 1 modify bootvolume=primary
controller slot=1 modify spareactivationmode=predictive
controller slot=1 modify spareactivationmodeúilure
controller slot=1 array A modify consolidatespace
controller slot=5 physicaldrive 1E:1:1 modify disablepd
---------------------------------------------------------


--
François Lafont

Peut-être que ça parlera à certains d'entre vous (perso c'est un peu du
chinois pour moi) mais voici le résultat de la commande suivante qui
semble effectuer une sorte de diagnostic du RAID :

hpacucli controller slot=3 diag file=diag_raid.txt

Ça m'écrit dans le fichier diag_raid.txt tout plein de choses que vous
pouvez lire ici :

http://sisco.laf.free.fr/codes/diag_raid.txt


--
François Lafont

Emmanuel Florac <eflorac@imaginet.fr> écrivait :

Le Thu, 17 Jan 2013 03:49:00 +0100, Francois Lafont a écrit:

Comme vous pouvez voir, ça va plus vite sans le "write cache" qu'avec.
Est-ce normal ?

Non, c'est même exactement le contraire de ce qu'on attendrait
(normalement ça va 5 fois plus vite avec cache que sans). Bizarre.

Si la batterie de la carte raid des proliant est désactivée ça fait ça :
il y a tentative d'écriture dans le cache puis erreur, donc écriture sur
disque directe (la batterie sers à ne pas perdre les données du cache en
cas de coupure de courant).

À vérifier donc.

--
Les simplifications c'est trop compliqué

Le Tue, 22 Jan 2013 09:31:27 +0100, Francois Lafont a écrit:

Du coup, sauf erreur de ma part, j'ai l'impression que les perfs sont
meilleures avec le writecache que sans

Heu non, c'est plutôt le contraire: 47 Mo/s en écriture SANS cache, et 36
Mo/s AVEC cache. Ce qui est un résultat surprenant pour le moins.

Je te conseille les options suivantes de bonnie++ (4 cycles, pas de test
en mode caractère, 100 000 fichiers):

bonnie++ -f -x 4 -n 100 -d /destination

Si tu utilises bonnie en tant que root il faut aussi spécifier "-u 0".

--
It is better to remain silent and be thought a fool than to open one's
mouth and remove all doubt.
Abraham Lincoln.

Le Wed, 23 Jan 2013 01:48:32 +0100, Francois Lafont a écrit:

On est d'accord que tout ça est tellement « bas niveau » que je n'ai
aucune chance d'avoir un log quelque part qui me donne des infos, des
pistes, mêmes obscures ?

Sauf si tu as des logs en provenance du contrôleur lui-même.

--
Désormais, pour les nations et pour les peuples, une goutte de pétrole
a la valeur d'une goutte de sang.
Georges Clémenceau.

Bonjour,

Le Thu, 24 Jan 2013 04:41:47 +0100, Francois Lafont a écrit :

# echo "options cciss cciss_allow_hpsa=1"
options hpsa hpsa_allow_any=1" > /etc/modprobe.d/raid.conf

Et ensuite je reboote le système. Mais après reboot, c'est toujours la
même situation et le lsmod me retourne la même chose que ci-dessus.

Pourtant, mes options sont correctes il me semble :

~# modinfo hpsa | grep ^parm parm: hpsa_allow_any:Allow hpsa driver to
access unknown HP Smart Array hardware (int)
parm: hpsa_simple_mode:Use 'simple mode' rather than 'performant mode'
(int)

~# modinfo cciss | grep ^parm parm: cciss_tape_cmds:number of commands
to allocate for tape devices (default: 6) (int)
parm: cciss_allow_hpsa:Prevent cciss driver from accessing hardware
known to be supported by the hpsa driver (int)
parm: cciss_simple_mode:Use 'simple mode' rather than 'performant mode'
(int)

J'ai aussi tenté un redémarrage après avoir inversé les deux lignes dans
le fichier raid.conf mais aucun changement constaté.

Ai-je oublié une commande indispensable afin que mon fichier raid.conf
soit bien pris en compte et que le module hpsa prenne le pas sur cciss ?

En effet, il faut mettre à jour l'initrd utilisé au boot pour que tes
options soient prisent en compte.

Pour cela sous Debian:

~#update-initramfs -uv `uname -r`

puis reboot.

Pour le module cciss que tu as compilé, peut être devrais tu le
désinstaller avant de faire l'update de l'initrd.

Si ton problème n'est toujours pas résolu avec tes options, tu peux
réinstaller le module cciss en version 4.6 puis:

~#depmod -a --dry-run |grep cciss

tu verras alors le chemin d'accès du module pris en compte.

si la bonne version

~#depmod -a
~#update-initramfs -uv -k `uname -r`

et reboot.

sinon (en effet ce n'est pas très propre)

tu déplaces le fichier cciss.ko se trouvant dans extra/ dans le
répertoire
/lib/modules/$(uname
-r)/kernel/drivers/block/ comme tu le suggérais puis:

~#depmod -a
~#update-initramfs -uv -k `uname -r`


Julien