Les données, ce sont les données. Par exemple le contenu d'un fichier.
Les meta-données indiquent où trouver les données (c'est la table d'inode, des blocks libre, etc).
Ext3 est le seul FS a journaliser les données.
Exemple :
fd = open("toto") ;
write(fd, "data") ;
close (fd) (ou flush(fd)) ;
// coupure de courrant ou reset
Avec ext3, les données sont écrites, la taille du fichier est 4.
Avec xfs, jfs, reiserfs, les données peuvent ne pas être écrite et "pire" l'inode peut ne pas être créé. Si l'inode est créé, le fichier a une taille de 4 octets. Par contre rien ne garanti que les données sont écrites. Dans ces 4 octets il peut y avoir un bout d'un ancien /etc/passwd par exemple. C'est génant.
Si la coupure de courant ou le reset est fait avant le close() ou flush(), les données peuvent être écrite ou non. Par contre avec ext3 tu n'auras pas de mauvaises données. ext3 ne garantit l'ordre d'écriture que s'il y a un close() ou flush().
Donc :
fd = open("toto") ;
write(fd, "data") ;
seek(fd, quelque_part) // NB : ext3 mets les données à 0 si on va au-delà de la fin du fichier. Leur autres aussi sûrement (du moins s'il n'y a pas de coupure de courant ou reset).
write(fd, "data2") ;
// coupure de courant
"data2" peut être écrit alors que "data" n'est pas écrit. Si tu utilises un flush(), tu es sûr que "data" et "data2" sont écrits. ext3 journalise les données en premier (garanti que les données sont là) puis les méta-données.
C'est plus lent qu'un fs journalisé "classique" mais plus sûr. PostgreSQL (qui utilise flush comme d'autres SGBD, mais pas MySQL) sur ext3 est blindé.
Ça dépend du hardware. Avec SCSI il n'y a pas de problème sur coupure de courant.
[^] # Re: XFS
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 2.
Les meta-données indiquent où trouver les données (c'est la table d'inode, des blocks libre, etc).
Ext3 est le seul FS a journaliser les données.
Exemple :
fd = open("toto") ;
write(fd, "data") ;
close (fd) (ou flush(fd)) ;
// coupure de courrant ou reset
Avec ext3, les données sont écrites, la taille du fichier est 4.
Avec xfs, jfs, reiserfs, les données peuvent ne pas être écrite et "pire" l'inode peut ne pas être créé. Si l'inode est créé, le fichier a une taille de 4 octets. Par contre rien ne garanti que les données sont écrites. Dans ces 4 octets il peut y avoir un bout d'un ancien /etc/passwd par exemple. C'est génant.
Si la coupure de courant ou le reset est fait avant le close() ou flush(), les données peuvent être écrite ou non. Par contre avec ext3 tu n'auras pas de mauvaises données. ext3 ne garantit l'ordre d'écriture que s'il y a un close() ou flush().
Donc :
fd = open("toto") ;
write(fd, "data") ;
seek(fd, quelque_part) // NB : ext3 mets les données à 0 si on va au-delà de la fin du fichier. Leur autres aussi sûrement (du moins s'il n'y a pas de coupure de courant ou reset).
write(fd, "data2") ;
// coupure de courant
"data2" peut être écrit alors que "data" n'est pas écrit. Si tu utilises un flush(), tu es sûr que "data" et "data2" sont écrits. ext3 journalise les données en premier (garanti que les données sont là) puis les méta-données.
C'est plus lent qu'un fs journalisé "classique" mais plus sûr. PostgreSQL (qui utilise flush comme d'autres SGBD, mais pas MySQL) sur ext3 est blindé.
Ça dépend du hardware. Avec SCSI il n'y a pas de problème sur coupure de courant.