XFS가 시스템 시작 시 fsck를 구현하지 않는다는 사실을 발견했습니다. 이는 저널링 파일 시스템이 비정상 종료 후 파일 시스템이 일관된 상태인지 확인하는 데 도움이 되는 이유 중 하나입니다. 저널은 다음 마운트 시(예: 재부팅 후) 재생됩니다. ) .
비정상적인 종료 후에도 fsck가 여전히 필요합니까? 왜?
답변1
나는 "저널링 파일 시스템"의 일반적인 맥락에서 이 질문에 대답하고 있습니다.
내 생각에 당신이 "불순한 종료"를 많이 한다면 (를 통해)전원 코드 같은 것을 당기나요?fsck) 조만간 fsck 또는 이에 상응하는 도덕적인 명령인 .fileystsm이 필요한 파일 시스템 상태 에 빠지게 될 것입니다. xfs_repair내 노트북의 .fileystsm은 ext4대부분 완전한 종료를 포함하여 재부팅할 때마다 로그를 재생하지만 가끔은 전체 로그를 실행합니다. fsck.
하지만 “일지를 다시 읽어보는 것”으로 무엇을 얻을 수 있는지 스스로에게 물어보세요. 로그를 재생하면 파일 시스템의 나머지 부분에 대한 디스크 블록이 로그 항목에 필요한 순서와 일치하는지 확인할 수 있습니다. 재생 일기는 일기의 작은 부분 fsck이거나 전체 일기의 일부 입니다 fsck.
내 생각에는 몇 가지 언어적 속임수가 진행되고 있는 것 같습니다. 재생 로그의 역할은 전통적인 역할의 일부이며 프로그램(또는 다른 파일 시스템)과 정확히 동일 fsck합니다 . xfs_repairXFS 사람들은 단지 그들의 경험으로 인해 부팅할 때마다 실행되지 않고 로그만 재생된다고 믿게 됩니다.e2fs.fsckfsckxfs_repair
답변2
비정상적인 종료 후에도 파일 시스템이 일관된 상태를 유지하도록 도와줍니다.
가장 먼저 주목해야 할 점은 대부분의 XFS, reiser 및 ext 구성이 fsck를 방지하기 위해 메타데이터 로깅만 구현한다는 것입니다. 로그는 시작 시 항상 재생되지는 않습니다. 불완전한 경우 폐기될 수 있습니다.
일부 시스템은 전체 데이터 로깅을 지원하지만 실제로 이러한 시스템은 실제 시나리오에서 매우 낮은 수준의 보장으로 메타데이터 로깅만 제공합니다.
따라서 "일관되지 않은 상태"와 fsck가 해결하는 문제는 메타데이터와 파일 자체 간의 불일치입니다. 이를 방지하기 위해 운영 체제는 제안된 메타데이터 변경 사항을 로그에 기록한 다음 실제 데이터를 디스크에 쓴 다음 로그에서 복사된 메타데이터 변경 사항을 디스크에 적용합니다. 유일한 문제는 디스크 컨트롤러가 요청을 버퍼링하고 재정렬할 수 있다는 것입니다. 이를 방지하기 위해 대부분의 저널링 파일 시스템은 장벽을 구현합니다. 장벽은 각 작업을 분리하고 디스크가 작업이 완료되었음을 확인할 때까지 기다립니다. 그러나 많은 최신 디스크는 실제로 데이터를 커밋하기 전에 쓰기 완료를 인정합니다. 그러므로 상황이 혼란스러울 수 있습니다.
비정상적인 종료 후에도 fsck가 여전히 필요합니까? 왜
대부분의 파일 시스템은 마운트 횟수를 유지합니다. 이 횟수에 도달하면 다음에 디스크를 마운트하려고 시도할 때 전체 fsck가 트리거됩니다. 그 이유는 명시적으로 기록되지 않았거나 소프트웨어에 버그가 없더라도 디스크 데이터가 손상될 수 있기 때문입니다. 위의 psusi 의견이 잘못되었습니다.
답변3
단지 비정상적인 종료 때문에 저널 파일 시스템을 fsck할 필요는 없습니다.
이것모두메타데이터 로깅의 런타임 성능 저하를 허용하는 이유는 파일 시스템이 완전히 마운트 해제되지 않은 경우 다음 마운트 시 메타데이터 로그를 자동으로 재생하여 파일 시스템이 다시 100% 일관성을 유지할 수 있다는 것입니다.
fsck의 유일한 역할은 메타데이터 일관성을 보장하는 것이므로 파일 시스템이 제대로 마운트 해제되지 않았다는 이유로 fsck를 실행하는 것은 중복됩니다.
그러나 저널링 파일 시스템은 하드웨어 오류, 드라이버 오류, 관리 오류 등 다른 이유로 인해 손상될 수 있으므로 fsck 도구가 반드시 필요합니다. 단지 비정상 종료로 인해 전화할 이유가 없습니다.