Re: J'ai du mal à comprendre

En fait, l'écriture se fait à la fin en grande partie, lors du sync. Les écritures sont toutes bufferisés. C'est sur la lecture qu'il y a une optimisation possible, mais un bon choix du readahead résoud ce problème.

Donc tu veux des plus petits fichiers, ok. Je vais aussi me mettre en condition plus violentes, 4 cp séquentiels contre 4 cp parallèles. Donc 4 dossiers contenants chacun 100 MiB en fichier de 10 KiB.

mkdir qqch{1..4}
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch1/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch2/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch3/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch4/

La commande de test sera pour le séquentiel :

rm -rf qqpart; mkdir qqpart; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 1 cp -r; sync"

Et pour le parrallèle :

rm -rf qqpart; mkdir qqpart; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 4 cp -r; sync"

Et alors là les performances sont même contraire à que vous suggerez :

• Séquentielle : 4 min 38 s
• Parallèle : 3 min 23 s

Je le répète, pour moi, c'est le rôle du noyau d'optimiser ce genre de chose, pas de l'utilisateur. Encore faut-il avoir une machine bien configuré, et assez de RAM relativement à la taille des données qu'on manipule. C'est vrai, sur une machine limitée en mémoire, le noyau ne peut pas optimiser car il ne peut pas garder assez de pages sales en mémoire, mais ce n'est pas le cas général.

Pour moi le raisonnement est simple, je configure bien mon système par rapport à mon usage, je lui donne les moyens adéquats (assez de mémoire), et après c'est son problème, pas le mien. Toutes ces solutions (mise en file pour une copie séquentielles, etc.) ne sont à mes yeux que des solutions de contournement, et elle ne sont donc d'aucunes utilité quand il y a rien à contourner.