`rm`이 나쁜 후에 내 컴퓨터의 전원을 끄는 이유는 무엇입니까?

고전적인 상황 : 나는 나쁜 rm것을했고 곧 잘못된 파일을 제거했다는 것을 깨달았습니다. (중요한 것은 없으며 최근 백업을 견딜 수 있었지만 여전히 성가신 일입니다.)

extundelete이러한 도구를 사용 하여 파일을 복구하려는 경우 추가 디스크 활동이 적이라는 것을 알고 즉시 기계의 전원을 즉시 끕니다 (예 : 전원 단추를 사용 halt하거나 명령 하지 않음 ). 중요한 작업이 실행 중이거나 열려 있지 않은 랩톱이므로 허용되는 작업이었습니다. (그런데, 나는 누락 된 파일이 여전히 프로세스에 의해 열 수있는 경우는 이러한 상황에서 할 첫 번째 일은 먼저 추정 될 것이라고 그 이후로 배운 https://unix.stackexchange.com/a/101247 - 이러한 경우에는 시스템의 전원을 끄지 말고 이러한 방식으로 복구해야합니다.)

그래도 일단 시스템 전원이 꺼지면 잠시 동안 생각하고 파일을 적절한 법의학을 위해 라이브 시스템을 부팅하는 데 시간 투자 가치가 없다고 결정했습니다. 그래서 나는 기계를 다시 가동시켰다. 그런 다음 파일이 여전히 디스크에 앉아 있음을 발견했습니다 rm. 전원을 끄기 전에 디스크에 전파되지 않았습니다. 나는 약간의 춤을 추고 그의 예기치 않은 용서에 대해 sysadmins의 신에게 감사했다.

내 질문은 이것이 어떻게 가능한지, 그리고 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.

또 다른 질문은 커널에게 머신의 전원을 끄는 대신 보류중인 디스크 작업을 수행하지 말고 (어딘가에 덤프)하는 방법이 있는지 여부입니다. (물론, 보류중인 작업을 수행하지 않는 것이 위험하게 들리지만, 이것은 기계의 전원을 끌 때 발생하는 일이며, 경우에 따라 사용자를 구할 수있는 경우도 있습니다.) 물론 "깨끗한"것입니다. 예를 들어 물리적 전원 차단이 쉬운 옵션이 아닌 원격 서버.

무슨 일이 있었는지 잘 알 것 같습니다.

예, 변경 사항이 디스크에 커밋되기 전에 시스템의 전원을 끈 상태이므로 백업 할 때있었습니다.

시스템은 디스크에 플러시하기 전에 모든 쓰기를 캐시합니다. 이 동작을 제어하는 ​​몇 가지 옵션이 있으며 모두 /proc/sys/vm/dirty_* ^{[ kernel doc ]에} 있습니다. fsync() ^{[ man 2 fsync ]} 를 통해 응용 프로그램에서 플러시를 명시 적으로 수행하지 않으면 데이터가 충분히 오래되었거나 쓰기 캐시가 채워질 때 데이터가 커밋됩니다.
위에서 사용 된 "데이터"의 정의에는 파일을 삭제하기 위해 디렉토리 항목을 수정하는 것이 포함됩니다.

이제 저널에 관해서는, 그것이 저널이 무엇을하는지에 대한 일반적인 오해 중 하나입니다. 저널의 목적은 변경 사항이 재생되거나 데이터가 유실되지 않도록하는 것이 아닙니다. 저널의 목적은 파일 시스템이 아닌 파일 시스템 자체의 손상을 방지하는 것입니다. 저널에는 변경 사항에 대한 정보가 포함되어 있으며 변경 사항에 대한 전체 데이터가 아니라 일반적으로 변경 사항에 대한 정보가 들어 있습니다. 정확한 세부 사항은 파일 시스템 및 저널 모드에 따라 다릅니다. ext3 / 4의 경우에있는 data마운트 옵션을 참조하십시오 man 8 mount.

재부팅하지 않고 보류중인 쓰기를 막을 수있는 방법이 있는지에 대한 보충 질문에 대답하려면 다음을 수행하십시오.

커널 소스 코드를 빠르게 읽는 것부터 magic sysrq u명령 ^{([ wikipedia ], [ kernel doc ])} 을 사용하여 긴급 마운트 다시 읽기 전용 작업을 수행 할 수있는 것처럼 보입니다 . 동기화 작업 없이 모든 볼륨을 읽기 전용으로 즉시 다시 마운트하는 것으로 보입니다 .

이를 사용하려면 Alt+ SysRq+ 를 누르기 만하면 u됩니다.

보낸 사람 : https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

commit = nrsec (*) Ext4는 모든 'nrsec'초마다 모든 데이터와 메타 데이터를 동기화하도록 지시 할 수 있습니다. 기본값은 5 초입니다. 즉, 전력을 잃으면 최근 5 초 동안 작업을 잃게됩니다 (저널링 덕분에 파일 시스템은 손상되지 않습니다). 이 기본값 (또는 낮은 값)은 성능을 저하 시키지만 데이터 안전에 좋습니다. 0으로 설정하면 기본값 (5 초)으로 두는 것과 같은 효과가 있습니다. 매우 큰 값으로 설정하면 성능이 향상됩니다.

또한이를 비우는 방법에 대한 내용도 참조하십시오 . Linux 시스템에서 버퍼를 비우고 캐시하는 방법은 무엇입니까?

위 링크에서 인용 :

참고 : 불필요한 것들의 메모리를 정리하십시오 (Kernerl 2.6.16 이상). 유용한 것들을 디스크로 플러시하려면 항상 sync를 먼저 실행하십시오 !!!

To free pagecache:

$ echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:

$ echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:

$ echo 3 > /proc/sys/vm/drop_caches