> En faisant un snapshot, tu conserve l'atomicité.
Hu ?!
Le snapshot est une opération atomique. Mais le snapshot peut-être fait au milieu de ce que l'utilisateur (un client d'un sgbd par exemple) voir comme atomique. Le sgdb sait gérer ce cas (c-à-d qu'il fout toute la transaction à la poubelle ; ce qui est logique). Ce qui est atomique au niveau utilisateur peut impliquer de nombreuses actions au niveau du sgdb dont l'ensemble n'est pas atomique au niveau FS. Mais comme je l'ai déjà dit, le sgdb sait gérer ça (ou alors il est codé avec les pieds).
Notons qu'ext3 vient à notre secours même en cas de coupure de courant. Un fsync() qui aboutit avec ext3 garantit que les données et les méta-données sont cohérents et écrit physiquement sur le disque.
Typiquement le sgbd fait :
- plein d'écritures, l'ordre d'écriture physique n'est pas garantit
- fsync(). Tout est écrit sur le disk sauf l'info qui valide la transaction. Ici la transaction n'est pas validée même si elle est complète et le sgbd s'il est lancé à nouveau l'ignorera.
- une écriture atomique pour valider la transaction (un bloque disque maximum, ce qui est largement suffisant).
- fsync(). Celui-ci est optionnel. Ça dépend de ce que fait le sgdb après.
Je suis convaincu de l'intérêt d'ext3cow. Dommage qu'il ne soit pas ou peu maintenu. Faute d'ext3cow, il faut faire avec lvm/dm (ce qui est un peu lourd par rapport à ext3cow qui ne demande qu'une partition (qui peut être classique/raid/lvm/loopback, qu'importe)).
[^] # Re: rdiff-backup
Posté par IsNotGood . En réponse au journal Journalisation de fichier. Évalué à 2.
> En faisant un snapshot, tu conserve l'atomicité.
Hu ?!
Le snapshot est une opération atomique. Mais le snapshot peut-être fait au milieu de ce que l'utilisateur (un client d'un sgbd par exemple) voir comme atomique. Le sgdb sait gérer ce cas (c-à-d qu'il fout toute la transaction à la poubelle ; ce qui est logique). Ce qui est atomique au niveau utilisateur peut impliquer de nombreuses actions au niveau du sgdb dont l'ensemble n'est pas atomique au niveau FS. Mais comme je l'ai déjà dit, le sgdb sait gérer ça (ou alors il est codé avec les pieds).
Notons qu'ext3 vient à notre secours même en cas de coupure de courant. Un fsync() qui aboutit avec ext3 garantit que les données et les méta-données sont cohérents et écrit physiquement sur le disque.
Typiquement le sgbd fait :
- plein d'écritures, l'ordre d'écriture physique n'est pas garantit
- fsync(). Tout est écrit sur le disk sauf l'info qui valide la transaction. Ici la transaction n'est pas validée même si elle est complète et le sgbd s'il est lancé à nouveau l'ignorera.
- une écriture atomique pour valider la transaction (un bloque disque maximum, ce qui est largement suffisant).
- fsync(). Celui-ci est optionnel. Ça dépend de ce que fait le sgdb après.
Je suis convaincu de l'intérêt d'ext3cow. Dommage qu'il ne soit pas ou peu maintenu. Faute d'ext3cow, il faut faire avec lvm/dm (ce qui est un peu lourd par rapport à ext3cow qui ne demande qu'une partition (qui peut être classique/raid/lvm/loopback, qu'importe)).