Pour les quotas, lire la remarque ci-dessus.
Et effectivement, la journalisation de ReiserFS ne garantie que l'intégrité de la structure des données, pas des données elles-memes. C'est pareil pour XFS et la plupart des systèmes journalisés pour des raisons évidentes de performances.
Ext3 place dans son journal aussi bien les modifications effectuées sur les méta-données que celles effectuées sur les données. C'est ce qui explique sa lenteur (et c'est beaucoup plus simple de logger les deux plutot qu'uniquement les méta-données) .
Pour en perdre le moins possible, il faut effectuer toutes les écritures de façon synchrone. Désactiver tous les caches, y compris celui du disque dur.
D'une part les performances ainsi obtenues sont minables, d'autre part, il n'y a aucune intégrité au niveau des applications. Si ça plante lorsque l'on était en train d'écrire un fichier, qu'est-ce-qui prouve qu'au prochain reboot, le fichier est encore exploitable vu qu'il en manque un bout ? Quelque soit le filesystem, le problème est le meme : quand il n'y a plus de courant electrique (ou un plantage du noyau), difficile d'écrire quoi que ce soit sur le disque dur !
Actuellement, la seule solution est de gérer ça au niveau applicatif. Par exemple en utilisant une base de données munie de transactions (pitié, pas de trolls sur MySQL qui supporte maintenant très bien les transactions avec BerkeleyDB), ou en ne faisant que des opérations atomiques.
[^] # Re: Avantage
Posté par Anonyme . En réponse à la dépêche ReiserFS sous Linux. Évalué à 0.
Et effectivement, la journalisation de ReiserFS ne garantie que l'intégrité de la structure des données, pas des données elles-memes. C'est pareil pour XFS et la plupart des systèmes journalisés pour des raisons évidentes de performances.
Ext3 place dans son journal aussi bien les modifications effectuées sur les méta-données que celles effectuées sur les données. C'est ce qui explique sa lenteur (et c'est beaucoup plus simple de logger les deux plutot qu'uniquement les méta-données) .
Pour en perdre le moins possible, il faut effectuer toutes les écritures de façon synchrone. Désactiver tous les caches, y compris celui du disque dur.
D'une part les performances ainsi obtenues sont minables, d'autre part, il n'y a aucune intégrité au niveau des applications. Si ça plante lorsque l'on était en train d'écrire un fichier, qu'est-ce-qui prouve qu'au prochain reboot, le fichier est encore exploitable vu qu'il en manque un bout ? Quelque soit le filesystem, le problème est le meme : quand il n'y a plus de courant electrique (ou un plantage du noyau), difficile d'écrire quoi que ce soit sur le disque dur !
Actuellement, la seule solution est de gérer ça au niveau applicatif. Par exemple en utilisant une base de données munie de transactions (pitié, pas de trolls sur MySQL qui supporte maintenant très bien les transactions avec BerkeleyDB), ou en ne faisant que des opérations atomiques.
-Jedi.