Situation classique: j'ai rm
mal tourné et j'ai réalisé immédiatement après que j'avais supprimé les mauvais fichiers. (Rien de critique et j'avais des sauvegardes assez récentes, mais toujours ennuyeuses.)
Sachant que l'activité du disque était mon ennemi si je voulais récupérer les fichiers avec extundelete
ou de tels outils, j'ai immédiatement mis la machine hors tension physiquement (c'est-à-dire avec le bouton d'alimentation, pas avec halt
ou une telle commande). C'était un ordinateur portable sans tâches importantes en cours d'exécution ou quoi que ce soit ouvert, donc c'était une opération acceptable. (Au fait, j'ai appris depuis lors que la première chose à faire dans une telle situation serait d'estimer d'abord si les fichiers manquants peuvent toujours être ouverts par un processus https://unix.stackexchange.com/a/101247 - s'ils le sont, vous devez les récupérer de cette façon plutôt que d'éteindre la machine.)
Pourtant, une fois que la machine a été mise hors tension, j'ai réfléchi un moment et j'ai décidé que les fichiers ne valaient pas l'investissement en temps de démarrage d'un système live pour une criminalistique appropriée. J'ai donc rallumé la machine. Et puis j'ai découvert que mes fichiers se trouvaient toujours sur le disque: ils rm
n'avaient pas été propagés sur le disque avant la mise hors tension. J'ai fait une petite danse et j'ai remercié le dieu des administrateurs système pour son pardon inattendu.
Ma question est maintenant de comprendre comment cela a été possible et quel est le délai typique avant qu’un rm
ne se propage réellement sur le disque. Je sais que le disque IO n'est pas vidé immédiatement mais qu'il reste en mémoire pendant un certain temps, mais je pensais que le journal du disque garantirait rapidement que les opérations en attente ne soient pas entièrement perdues. https://unix.stackexchange.com/a/78766 semble faire allusion à un mécanisme distinct pour vider les pages sales et pour vider les opérations de journal, mais ne donne pas suffisamment de détails sur la façon dont le journal serait impliqué pour un rm
et le délai prévu avant les opérations sont vidées.
Quelques détails supplémentaires: les données étaient dans une partition ext4 à l'intérieur d'un volume LUKS, et lors du démarrage de la sauvegarde de la machine, j'ai vu ce qui suit dans syslog
:
Sep 24 10:24:58 gamma kernel: [ 11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [ 11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [ 11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
mais je ne suis pas sûr que ce soit lié à la rm
.
Une autre question serait de savoir s'il existe un moyen de dire au noyau de n'effectuer aucune des opérations de disque en attente (mais plutôt, disons, de les vider quelque part), plutôt que de mettre la machine hors tension. (Bien sûr, il semble dangereux de ne pas effectuer les opérations en attente, mais c'est ce qui se passerait quand vous éteignez la machine de toute façon, et dans certains cas, cela pourrait vous sauver.) Ce serait "plus propre", bien sûr, et aussi intéressant par exemple des serveurs distants où la mise hors tension physique n'est pas une option facile.
rm
écriture? En d'autres termes, les choses ne sont engagées dans le journal que lorsqu'une écriture est sur le point d'être effectuée? Ou l'image est-elle plus complexe que cela? Quant à alt-sysrq-u, c'est une bonne idée. Avez-vous une référence à donner pour la réclamation "Il semble"? (Cela ne semble pas découler des liens que vous avez donnés.) Merci! :)