Pas terrible comme astuce.
Si jamais la Ooops s'est produit dans le code qui gère le FileSystem, et que avant de faire une Oops le code fautif à corrompu des buffers. Et bien en faisant une synchro des buffers(c'est ce que fait le remontage en ReadOnly), on fait recopie sur le disque des buffers CORROMPUS !!!
C'est vraiment une super idée si on a envie de perdre toutes les données d'une partition(bonjour la corruption de fichiers généralisée). Les développeurs du noyau conseilles de n'utiliser cette sys-req key seulement en connaissance de cause. "En connaissance de cause" voulant dire qu'on a une console sur le port série qui permet de savoir ou ca a déconné exactement.
Pour avoir été victime d'une corruption de fichier par ce biais je déconseilles plutôt catégoriquement cette technique(même s'il m'arrive de m'en servir de temps à autre). Le temps d'un fsck ne vaut pas le temps de réinstalle d'une partoche.
# Re: Eviter les check forced !
Posté par David FORT . En réponse au message [Terminal] Eviter les check forced !. Évalué à 1.
Si jamais la Ooops s'est produit dans le code qui gère le FileSystem, et que avant de faire une Oops le code fautif à corrompu des buffers. Et bien en faisant une synchro des buffers(c'est ce que fait le remontage en ReadOnly), on fait recopie sur le disque des buffers CORROMPUS !!!
C'est vraiment une super idée si on a envie de perdre toutes les données d'une partition(bonjour la corruption de fichiers généralisée). Les développeurs du noyau conseilles de n'utiliser cette sys-req key seulement en connaissance de cause. "En connaissance de cause" voulant dire qu'on a une console sur le port série qui permet de savoir ou ca a déconné exactement.
Pour avoir été victime d'une corruption de fichier par ce biais je déconseilles plutôt catégoriquement cette technique(même s'il m'arrive de m'en servir de temps à autre). Le temps d'un fsck ne vaut pas le temps de réinstalle d'une partoche.