le RAID logiciel est dans une couche inférieure au système de fichier et le contrôle du système de fichier se fait toujours avec le système de fichier non-monté
Premièrement le système RAID est un FS (un genre de) lui-même et il utilise un certain nombre de mécanismes VFS lui même. Deuxièmement en single user il est possible de faire un check d'un système de fichier si il est monté en R/O et c'était bien pratique (jusqu'en 2008/2009) pour la récupération d'infos sur un RAID primaire boot. A ma connaissance ca existe toujours (je n'utilise quasiment plus Linux depuis 18 mois, mais ca m'étonnerai franchement que ca ait disparu)
mais bon on parlait de fsck et lui fonctionne sans intervention du noyau.
Je rappelle ce que j'ai dit, à savoir que fsck a du mal à suivre toute les variations du noyau, principalement avec les modifs ext4 et VFS.
Déjà fsck peut fonctionner sans intervention du noyau, mais généralement il utilise quand même pas mal les interface que lui fourni le noyau.
Typiquement sur une partition RAID soft, fsck doit pouvoir faire la différence entre les cas suivant (entre autres):
pilote RAID chargé, device raid construit, superblock RAID généré par le noyau
superblock RAID persistant, device raid construit, pilote RAID non chargé
Sinon il ne peut que faire des conneries, et généralement ca fini par un superblock corrompu au reboot.
Après fsck a été modifié plusieurs fois au cours des dernières années pour prendre en compte tout un tas d'évolutions, par exemple les devices sans géométrie, les variations de superblock persistant, les modifications d'ext4 (avec un grosse flopée de bugs fin 2009 début 2010 notamment sur les OS 64bits).
A aujourd'hui je n'utiliserais pas un fsck de 2009 pour checker une bête partition ext2 des familles sur un kernel 2.6.30 ou plus. En théorie ca devrait marcher, en pratique des fois il y a des surprises. Et si la partition est un poil exotique (par exemple du RAID ou du chiffrement par dessus) je déconseille vraiment.
[^] # Re: ABI Gaël
Posté par phxonx . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à -5.
Premièrement le système RAID est un FS (un genre de) lui-même et il utilise un certain nombre de mécanismes VFS lui même. Deuxièmement en single user il est possible de faire un check d'un système de fichier si il est monté en R/O et c'était bien pratique (jusqu'en 2008/2009) pour la récupération d'infos sur un RAID primaire boot. A ma connaissance ca existe toujours (je n'utilise quasiment plus Linux depuis 18 mois, mais ca m'étonnerai franchement que ca ait disparu)
Je rappelle ce que j'ai dit, à savoir que fsck a du mal à suivre toute les variations du noyau, principalement avec les modifs ext4 et VFS.
Déjà fsck peut fonctionner sans intervention du noyau, mais généralement il utilise quand même pas mal les interface que lui fourni le noyau.
Typiquement sur une partition RAID soft, fsck doit pouvoir faire la différence entre les cas suivant (entre autres):
Sinon il ne peut que faire des conneries, et généralement ca fini par un superblock corrompu au reboot.
Après fsck a été modifié plusieurs fois au cours des dernières années pour prendre en compte tout un tas d'évolutions, par exemple les devices sans géométrie, les variations de superblock persistant, les modifications d'ext4 (avec un grosse flopée de bugs fin 2009 début 2010 notamment sur les OS 64bits).
A aujourd'hui je n'utiliserais pas un fsck de 2009 pour checker une bête partition ext2 des familles sur un kernel 2.6.30 ou plus. En théorie ca devrait marcher, en pratique des fois il y a des surprises. Et si la partition est un poil exotique (par exemple du RAID ou du chiffrement par dessus) je déconseille vraiment.