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.
