잘못된 "rm"을 입력한 후 컴퓨터를 종료하면 파일이 저장되는 이유는 무엇입니까?

전형적인 시나리오: 실행이 잘못됐는데 rm잘못된 파일을 삭제했다는 것을 즉시 깨닫게 됩니다. (중요한 것은 없으며 최근 백업이 있지만 여전히 짜증납니다.)

그러한 도구를 사용하여 파일을 복구 하고 싶다면 추가 디스크 활동이 나의 적이라는 것을 알았고 즉시 물리적으로 시스템 전원을 껐습니다(즉 , 그러한 명령을 extundelete사용하는 대신 전원 버튼을 사용함 ). halt중요한 작업을 실행하지 않거나 아무 것도 열지 않는 노트북이므로 허용되는 작업입니다. (그런데, 나는 이 상황에서 가장 먼저 해야 할 일은 먼저 프로세스에서 누락된 파일을 열 수 있는지 여부를 추정하는 것임을 배웠습니다.https://unix.stackexchange.com/a/101247-- 그렇다면 머신을 종료하는 대신 이 방법으로 복원해야 합니다. )

그래도 일단 기계의 전원이 꺼지면 잠시 생각해 본 결과 적절한 법의학을 위해 라이브 시스템을 부팅하는 데 시간을 투자할 가치가 없다고 판단했습니다. 그래서 기계를 다시 시작했습니다. 그러다가 내 파일이 여전히 디스크에 있다는 것을 발견했습니다. rm전원을 끄기 전에는 파일이 디스크에 전파되지 않았습니다. 나는 약간의 춤을 추고 예상치 못한 용서에 대해 시스템 관리자 신들에게 감사했습니다.

이제 내 질문은 이것이 어떻게 달성되고 rm실제로 디스크에 전파되기 전에 일반적인 지연이 무엇인지 이해하는 것입니다.디스크 IO가 즉시 플러시되지 않고 잠시 동안 메모리에 유지된다는 것을 알고 있지만 보류 중인 작업이 완전히 손실되지 않도록 디스크 로그를 빠르게 확인할 수 있을 것이라고 생각했습니다.https://unix.stackexchange.com/a/78766더티 페이지 플러시와 로그 작업 플러시를 위한 별도의 메커니즘을 암시하는 것처럼 보이지만 로그가 플러시 작업에 참여하는 방식 rm이나 플러시 작업 전 예상되는 지연에 대한 세부 정보를 충분히 제공하지 않습니다.

자세한 내용: 데이터는 LUKS 볼륨 내부의 ext4 파티션에 있으며 머신 백업을 시작하면 다음 항목이 표시됩니다 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)

하지만 이것이 rm.

또 다른 질문은 머신의 전원을 끄지 않고 보류 중인 디스크 작업을 수행하지 않고 대신 어딘가에 덤프하도록 커널에 지시하는 방법이 있는지 여부입니다. (물론 정지된 작업을 수행하지 않는 것이 위험하게 들리지만, 이는 기계를 종료할 때 발생하는 일이며 어떤 경우에는 절약할 수 있습니다.) 물론 "더 깔끔"하며 많은 즐거움을 주기도 합니다. 예를 들어, 원격 서버의 전원을 물리적으로 끄는 것은 쉬운 옵션이 아닙니다.