On Thu, 17 Oct 2002, Christophe DONZELOT (f1rpc) wrote:
> Les 2 disques sont des disques SCSI Ultra160 qui ont un d�bit brut de 50
> Mbytes/s d'apr�s hdparm.
En miroir (RAID1) et en lecture, on peut donc supposer que la performance
est de 50 MByte/s, du moins dans de bonnes conditions (grandes I/O, pas de
buffering inutile, lecture seulement sur un disque sans load-balancing).
Tester avec hdparm directement sur /dev/md0. Si cela ne marche pas,
utiliser un autre outil (dd p.ex.).
> Apr�s test sur des volumes diff�rents un filesystem ext3 d�livre
Tester avec ext2, nous dire quelle taille de block (-b 4096 p.ex.), quelle
densit� d'inodes, et quel mode de fonctionnement ext3 (ordered ?)
Comparer avec et sans LVM, et �tre s�r que le rebuild de l'array a
termin�.
Aussi quel kernel et quels patches si ce n'est pas un kernel pur de
kernel.org dont la signature de la source joue.
Pour optimiser ext3, lire notamment:
- les modes de journalisation (ordered, etc):
http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
Le mode `je journalise tout (lent, hyper-s�r):
"mount -o data=journal"
Le mode: `je journalise seulement les m�tadata (structures), pas
les donn�es, mais je m'arrange pour que les fichiers
ne contient en aucun cas des donn�es vol�es � d'autres
fichiers' (lent, s�curitaire).
"mount -o data=ordered"
Le mode: `je fais au plus vite, genre NTFS5 ou reiserfs, avec
des risques sur une machine multiuser en cas de crash'
(tr�s rapide).
Des patches suppl�mentaires � la base du code peuvent offrir
d'autres modes (comme p.ex. les directory indexes, similaires
aux balanced trees de reiserfs (AFAIK)).
- les optimisations pour `bulk I/O'
- taille du journal
- fr�quence des synchronisations/checkpoints du journal
- les commentaires quant � la bonne ad�quation de ext3 pour
le mode `cr�ation de nombreux petits fichiers d�truits tr�s vite'
(queues de mail p.ex.) par rapport � reiserfs
Faire quelques recherches sur Google p.ex.
> Est-ce-que l'adjonction du 2�me cpu am�liorera mes mes affaires ?
Etant donn� qu'il n'y a pas de g�n�ration de parit� en RAID1 cela
m'�tonnerait.
> Cependant le propri�taire est tronqu� � 8 caract�res (EICN_NT+) ce qui
> m'emp�che de fixer des droits plus secure que 777 , ce qui est ennuyeux .
La plupart des syst�mes UNIX ont une telle limitation qui il est vrai sous
Linux, en tous cas pour les programmes utilisant PAM est historique.
Maintenant je ne sais pas dans quelle mesure il faut modifier Samba pour
cela ou si une table de conversion `noms EICN' vers `noms internes ou UID
UNIX' peut faire l'affaire. Je n'ai pas d'exp�rience dans ce domaine
cependant.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
