Son argument ne tient pas la route car il y a des cas d'utilisation pour lesquels fsync(), qui attend la complétion effective des écritures, est overkill -- on a besoin dans certains cas uniquement d'une sémantique de barrière avec visibilité sur les plateaux d'une sous séquence de celle écrite via les syscall...
Imaginons qu'on écrive une "conf" de 1 Mo chaque seconde remplaçant la précédente, que le besoin alors que le système tourne est de pouvoir lire la plus récente à chaque instant, et que le besoin en cas de crash est simplement d'en récupérer une pas trop vielle (et surtout une ne consistant pas non plus en 0 octets pour cause de perte de données...) : si le FS se contente de garantir ce que Posix dit un fsync() est obligatoire à chaque fois, on va donc écrire 1 Mo par seconde. Alors que si un pattern ultra courant à la open() write() close() rename() induit implicitement une barrière entre l'écriture des data et des metadata, le FS peut se contenter de commiter 1 fois par minute (ou plus ou moins selon la configuration) et tout le monde est content.
C'est une garantie de la part du FS qui va au delà de Posix, certes. Une appli utilisant ça serait non portable ; mais on peut être malin et la rendre néanmoins portable grâce aux fonction Posix :
long fpathconf(int fildes, int name);
long pathconf(const char *path, int name);
Grâce à ces fonctions, il suffit pour écrire une application portable mais qui sait profiter des systèmes biens conçus, de vérifier la présence d'une capacité publiée par le FS indiquant qu'il garanti que les séquences open() write() close() rename() sont implicitement "sûres". Si la capacité n'est pas présente, l'application rajoute simplement un fsync().
Ce serait la bonne chose à faire. Bien meilleure que de demander à tout le monde de mettre tout le temps des fsync(), quitte à introduire des threads rien que pour ça et à écrire 42x plus sur le disque que nécessaire...
[^] # Re: Le post de Matthew Garett est aussi très intéressant
Posté par Guillaume Knispel . En réponse au journal Don’t fear the fsync!. Évalué à 3.
Imaginons qu'on écrive une "conf" de 1 Mo chaque seconde remplaçant la précédente, que le besoin alors que le système tourne est de pouvoir lire la plus récente à chaque instant, et que le besoin en cas de crash est simplement d'en récupérer une pas trop vielle (et surtout une ne consistant pas non plus en 0 octets pour cause de perte de données...) : si le FS se contente de garantir ce que Posix dit un fsync() est obligatoire à chaque fois, on va donc écrire 1 Mo par seconde. Alors que si un pattern ultra courant à la open() write() close() rename() induit implicitement une barrière entre l'écriture des data et des metadata, le FS peut se contenter de commiter 1 fois par minute (ou plus ou moins selon la configuration) et tout le monde est content.
C'est une garantie de la part du FS qui va au delà de Posix, certes. Une appli utilisant ça serait non portable ; mais on peut être malin et la rendre néanmoins portable grâce aux fonction Posix :
long fpathconf(int fildes, int name);
long pathconf(const char *path, int name);
(vu dans un commentaire de http://lwn.net/Articles/323752/ , article encore réservé aux abonnés à ce jour)
Grâce à ces fonctions, il suffit pour écrire une application portable mais qui sait profiter des systèmes biens conçus, de vérifier la présence d'une capacité publiée par le FS indiquant qu'il garanti que les séquences open() write() close() rename() sont implicitement "sûres". Si la capacité n'est pas présente, l'application rajoute simplement un fsync().
Ce serait la bonne chose à faire. Bien meilleure que de demander à tout le monde de mettre tout le temps des fsync(), quitte à introduire des threads rien que pour ça et à écrire 42x plus sur le disque que nécessaire...