Au passage j'ai eu l'occasion de jouer avec et j'ai pas trouve l'api vraiement genial :
- pas de methode seek, tout passe par un read, du coup si on veut faire un truc un peu optimiser (c'est deja assez lent comme ca), une des premiere chose qu'on fait dans le read c'est de regarder si on a fait un seek
- pas moyen de preciser forcer un blocksize pour l'ecriture/lecture. Du coup on doit passer par des buffers intermediares/se prendre la tete qd on commence/fini au milieu d'un block
- pas de reel gestion de cache : par default fuse lit par page, du coup on lit beaucoup, on attend que le buffer se vide, on relit beaucoup, ce qui peut parfois entraine des delai lors de la lecture sur des medias lent.
Je dis pas que soit doit forcement etre implementer dans le noyau, mais au moins la lib fuse pourrait proposer des solutions generiques pour eviter d'avoir a coder plus de glue generique que le reste...
[^] # Re: FUSE
Posté par M . En réponse au journal Traducteurs : LeHurd vs Linux !. Évalué à 3.
- pas de methode seek, tout passe par un read, du coup si on veut faire un truc un peu optimiser (c'est deja assez lent comme ca), une des premiere chose qu'on fait dans le read c'est de regarder si on a fait un seek
- pas moyen de preciser forcer un blocksize pour l'ecriture/lecture. Du coup on doit passer par des buffers intermediares/se prendre la tete qd on commence/fini au milieu d'un block
- pas de reel gestion de cache : par default fuse lit par page, du coup on lit beaucoup, on attend que le buffer se vide, on relit beaucoup, ce qui peut parfois entraine des delai lors de la lecture sur des medias lent.
Je dis pas que soit doit forcement etre implementer dans le noyau, mais au moins la lib fuse pourrait proposer des solutions generiques pour eviter d'avoir a coder plus de glue generique que le reste...