Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).
Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.
Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 1.
C'est pas faux.
Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).
Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.
Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.
"La première sécurité est la liberté"