Si tu fais un outils générique de copie, cela peut être sympa d'utiliser des URI (file:// http://...).
Concernant la queue de copie, cela serait top d'avoir une queue par device. Certe, il y a un couplage pas marrant entre la lecture et l'écriture.
Concernant la copie elle-même, cela serait top d'utiliser splice()/vmsplice()/tee() pour faire de la zéro copie (ou mmap ?).
Si tu pouvais faire en sorte que "cp" soit enfin plus rapide que "dd", cela serait super. Les fread/fwrite bufferisent les IO dans un buffer de 64k. Cela fait donc un buffer dans la libc et un buffer dans le noyau (voir 2 avec un read/write classique), soit beaucoup trop de copies.
De plus, 64K est une taille de bloc beaucoup trop fine, même un raptor à une vitesse qui augmente à 1Mo et audela. Sur du raid, le plateau de vitesse est obtenu avec des tailles d'au moins 16 Mo.
# TODO list
Posté par Nicolas Boulay (site web personnel) . En réponse au journal gcp: un outil de copie à la cp. Évalué à 6.
Concernant la queue de copie, cela serait top d'avoir une queue par device. Certe, il y a un couplage pas marrant entre la lecture et l'écriture.
Concernant la copie elle-même, cela serait top d'utiliser splice()/vmsplice()/tee() pour faire de la zéro copie (ou mmap ?).
Si tu pouvais faire en sorte que "cp" soit enfin plus rapide que "dd", cela serait super. Les fread/fwrite bufferisent les IO dans un buffer de 64k. Cela fait donc un buffer dans la libc et un buffer dans le noyau (voir 2 avec un read/write classique), soit beaucoup trop de copies.
De plus, 64K est une taille de bloc beaucoup trop fine, même un raptor à une vitesse qui augmente à 1Mo et audela. Sur du raid, le plateau de vitesse est obtenu avec des tailles d'au moins 16 Mo.
"La première sécurité est la liberté"