남자 e2fsck가 말했습니다.
마운트된 파일 시스템에서 e2fsck를 실행하는 것은 일반적으로 안전하지 않습니다. 유일한 예외는 -c, -l 또는 -L 옵션 없이 -n 옵션이 지정된 경우입니다. 그러나 그렇게 하는 것이 안전하더라도 파일 시스템이 마운트되면 e2fsck에 의해 인쇄된 결과는 유효하지 않습니다. e2fsck가 마운트된 파일 시스템을 확인해야 하는지 묻는 경우 유일한 정답은 "아니오"입니다. 자신이 무엇을 하고 있는지 잘 아는 전문가만이 이 질문에 다른 방식으로 답하는 것을 고려해야 합니다.
파일 시스템에 오류가 발생하고 있음을 (적어도 ext4에서는) 알 수 있습니다 journalctl -k. 표면상으로는 Journalctl은 dmesg 유틸리티에서 보고한 것과 동일한 커널 메시지를 받습니다. fsck는 각 파일 시스템에서 다르게 작동하지만 일반적으로 실제 fs 로그를 확인하고 각 inode(iirc)에서 몇 가지 다른 항목을 찾습니다. man dmesg를 읽는 동안 특수 블록 장치 /dev/kmsg와 /proc/kmsg 파일에 대한 언급을 보았습니다. cat /dev/kmsg메시지를 읽을 수 있어요 . 이것이 journalctl -k데이터를 얻은 소스와 동일합니까? 이게 무슨 상관 인가요 e2fsck -n?
답변1
journalctl -k로그에 커널의 메시지를 표시합니다. dmesg커널 링 버퍼의 내용을 표시합니다. 둘 다 파일 시스템 드라이버의 오류 메시지를 포함하여 커널의 오류를 표시합니다.
이 중 어느 것도 e2fsck.파일 시스템 로그에서 나오지 않으며 .access "로그"와 관련이 없습니다 journalctl. 마운트된 파일 시스템에서 실행하면 파일 시스템 드라이버가 유지 관리하는 데이터가 e2fsck런타임 시 반드시 디스크에 위치할 필요는 없고 런타임 시 변경될 수 있으므로 잘못된 결과가 발생할 수 있습니다.e2fscke2fsck
답변2
추가 상황에 대한 참고 사항: 시작하는 동안,일부구성은 루트 파일 시스템에서 systemd명령을 실행 합니다.fsck읽기전용으로 설치된 경우. 의 경고에 따르면 man e2fsck이는 이상적이지 않습니다. 선호되는 구성은 일반 작업을 수행하는 initramfs를 사용하는 것입니다.fsck 앞으로루트 파일 시스템을 완전히 마운트합니다.
(이를 설명하는 기존 Q&A가 있지만 엉망입니다.)
e2fsck -n 읽기 전용으로 마운트된 파일 시스템에서유효한 결과를 인쇄합니다.
e2fsck외부가 -n완전히 "안전"한지 여부는 또 다른 문제입니다. (안전하지 않은 경우 잘못된 결과가 나올 위험도 있습니다.) 조심하겠습니다:-). 하지만 현재 수행되고 있는 작업이 systemd이전 세대 스크립트보다 "덜 안전한" 것은 아니라는 점은 신뢰할 수 있다고 생각합니다 .
제 생각에는줄이다fsck위험합니다. 변경이 필요한 경우 시스템을 즉시 다시 시작해야 한다는 것이 규칙입니다 .