> Le probleme vient du fait que l'extfs utilise des sortes de tables pour ces structures et que certaines operations ne sont pas atomiques au sens coherence.
Faut. Question, tu utilise des disques IDE ?
Car certains disque (la majorité) ne sont pas adaptés à ext3 ou tout autres systèmes de fichier journalisé. Les disques SCSI garantissent l'ordre d'écriture. Les disques IDE pour faire de l'optimisation peuvent changer l'ordre d'écriture.
De plus, les disques SCSI garantissent qu'un opération d'écriture sera réalisée même s'il y a une coupure de courant. Ce n'est pas le cas de la majorité des disques IDE.
> ben la le lost+found il va pleurer
Pour ext3 comme beaucoup d'autre, il y a deux structures de base. Les inodes et les blocks utilisés. Les inodes peuvent être relié dans le cas de répertoire. La table des inodes (il y en a plusieurs copies , chez moi c'est 40 et c'est la valeur par défaut pour mon disque!). Les inodes sont indépendants des répertoires. Un inode peut ne plus être référencé par un répertoire. Dans ce cas, il tombe dans lost+found. Des blocks peuvent ne plus avoir de inode. Dans ce cas, il tombe aussi dans lost+found.
Il y a aussi une table de group qui pointe sur le début de la table des inodes et block. Enfin, il y a les superblock qui pointent entre autre sur les groupes. Le point central, initial, c'est les superblock (plusieurs copie aussi). Si le premier superblock est perdu, tu peux utiliser une copie du superblock. Si tu ne sais plus où sont les superblock, t'es dans la merde. Pour éviter ce type de désagrément, sauvegarde la sortie de la commande dumpe2fs [partition] en lieu sure. Notes aussi que fsck peut voir que le système est totalement corrompu car il y a une erreur dans le superblock (genre "Block size", "Inodes per group", etc...). Ses valeurs sont read-only. Les modifications ne peuvent arriver que sur bug ou hardware qui déconne.
[^] # Re: Bon esprit...
Posté par matiasf . En réponse à la dépêche Interview de Gaël Duval à propos de Mandrake. Évalué à 5.
Faut. Question, tu utilise des disques IDE ?
Car certains disque (la majorité) ne sont pas adaptés à ext3 ou tout autres systèmes de fichier journalisé. Les disques SCSI garantissent l'ordre d'écriture. Les disques IDE pour faire de l'optimisation peuvent changer l'ordre d'écriture.
De plus, les disques SCSI garantissent qu'un opération d'écriture sera réalisée même s'il y a une coupure de courant. Ce n'est pas le cas de la majorité des disques IDE.
> ben la le lost+found il va pleurer
Pour ext3 comme beaucoup d'autre, il y a deux structures de base. Les inodes et les blocks utilisés. Les inodes peuvent être relié dans le cas de répertoire. La table des inodes (il y en a plusieurs copies , chez moi c'est 40 et c'est la valeur par défaut pour mon disque!). Les inodes sont indépendants des répertoires. Un inode peut ne plus être référencé par un répertoire. Dans ce cas, il tombe dans lost+found. Des blocks peuvent ne plus avoir de inode. Dans ce cas, il tombe aussi dans lost+found.
Il y a aussi une table de group qui pointe sur le début de la table des inodes et block. Enfin, il y a les superblock qui pointent entre autre sur les groupes. Le point central, initial, c'est les superblock (plusieurs copie aussi). Si le premier superblock est perdu, tu peux utiliser une copie du superblock. Si tu ne sais plus où sont les superblock, t'es dans la merde. Pour éviter ce type de désagrément, sauvegarde la sortie de la commande dumpe2fs [partition] en lieu sure. Notes aussi que fsck peut voir que le système est totalement corrompu car il y a une erreur dans le superblock (genre "Block size", "Inodes per group", etc...). Ses valeurs sont read-only. Les modifications ne peuvent arriver que sur bug ou hardware qui déconne.