필자는 XFS가 시스템 부팅시 fsck를 구현하지 않았으며 저널링 파일 시스템에서 선전 된 이유 중 하나는 부정확 한 종료 후 파일 시스템이 일관된 상태를 유지하는 데 도움이된다는 것을 알았습니다. 다음 마운트 (예 : 재부팅 후)에서 저널이 재생됩니다.
부정한 종료 후에도 여전히 fsck가 필요합니까? 그 이유는 무엇입니까?
필자는 XFS가 시스템 부팅시 fsck를 구현하지 않았으며 저널링 파일 시스템에서 선전 된 이유 중 하나는 부정확 한 종료 후 파일 시스템이 일관된 상태를 유지하는 데 도움이된다는 것을 알았습니다. 다음 마운트 (예 : 재부팅 후)에서 저널이 재생됩니다.
부정한 종료 후에도 여전히 fsck가 필요합니까? 그 이유는 무엇입니까?
답변:
나는 "journalled filesystems"의 일반적인 맥락에서 이것을 대답하고있다.
조만간 전원 코드 나 무언가 를 잡아 당겨 여러 번 "정상적인 셧다운" 을 한 경우, 파일 시스템 상태가 fsck되거나 fsck와 같은 도덕적 수준에 도달 할 것이라고 생각합니다 xfs_repair. ext4내 랩톱 의 fileystsm은 대부분 재부팅 할 때마다 깨끗한 종료를 포함하여 저널을 재생 하지만 가끔씩 완전히 재생됩니다 fsck.
그러나 "저널 재생"이 무엇을하는지 스스로에게 물어보십시오. 저널을 재생하면 나머지 파일 시스템의 디스크 블록이 저널 항목이 요구하는 순서와 일치하게됩니다. 저널 재생은 작은 것 fsck또는 전체의 일부에 해당합니다 fsck.
나는 저널을 재생하는 것이 전통적 일의 일부를 fsck수행하고 xfs_repair정확히 같은 종류의 프로그램 e2fs.fsck(또는 다른 파일 시스템 fsck)과 같은 것입니다. 방금 믿었던 XFS 사람들이나 그들의 경험으로 인해 xfs_repair모든 부팅에서 실행되지 않고 저널을 재생하기도했습니다.
fsck은 '펜던트'가 아닙니다. ext3 LVM파티션을 변환하고 변환 된 'LVM'파티션에서 비트 맵의 디스크 내 및 메모리 내 사본에서 불일치를 일으키는 코드 ext4의 버그로 인해 'ext4_mb_generate_buddy'오류가 발생하기 시작했습니다 ext4. 에서 알 수있는 한 fsck부패가 발생하지 않았습니다. 해결책은 UNINIT_BG옵션 을 끄 거나 데이터를 이동하고 파티션을 다시 초기화하는 것입니다 ext4. 나는 후자를 밟았다. 그러나 나는 여전히 몇 분을 기다리는 fsck것이 데이터를 잃지 않을 가치가 있다고 생각합니다 !
부정확 한 종료 후 파일 시스템이 일관된 상태를 유지하도록 도와줍니다.
가장 먼저 주목할 것은 XFS, reiser 및 대부분의 ext 구성은 메타 데이터 저널링 만 구현한다는 것입니다. 이는 fsck를 피하는 것입니다. 저널은 시작시 항상 재생되지는 않습니다. 저널이 불완전하면 삭제 될 수 있습니다.
완전한 데이터 저널링을 지원하는 시스템이 있지만 실제로 메타 데이터 저널링에 대한 보장 수준은 실제 시나리오에서는 매우 작습니다.
따라서 '일관되지 않은 상태'와 fsck로 해결 된 문제는 메타 데이터와 파일 자체의 불일치입니다. 이를 피하기 위해 OS는 제안 된 메타 데이터 변경 사항을 저널에 기록한 다음 실제 데이터를 디스크에 기록한 다음 저널에 복제 된 메타 데이터 변경 사항을 디스크에 적용합니다. 이것의 유일한 캐치는 디스크 컨트롤러가 요청을 버퍼링하고 잠재적으로 재정렬한다는 것입니다. 이를 방지하기 위해 대부분의 저널링 파일 시스템은 장벽을 구현합니다. 각 작업을 분리하고 디스크가 작업을 완료했음을 확인하기를 기다립니다. 그러나 많은 최신 디스크는 실제로 데이터가 커밋되기 전에 쓰기 완료를 확인합니다. 따라서 일이 더러워 질 수 있습니다.
부정한 종료 후에도 여전히 fsck가 필요합니까?
대부분의 파일 시스템은 마운트 횟수를 유지합니다. 일단이 횟수에 도달하면 다음에 디스크를 마운트 할 때 전체 fsck가 트리거됩니다. 디스크 데이터가 소프트웨어에 버그없이 기록되지 않은 경우에도 디스크 데이터가 손상 될 수 있습니다. 위의 psusi의 의견이 잘못되었습니다.
hdparm -W)를 활성화 하지 않으면 디스크는 매체에있을 때까지 쓰기 요청을 완료하지 않습니다. 왜 그 옵션이 존재한다고 생각합니까? 여러 요청이 발행 될 때 장벽이 재정렬을 방지합니다. 장벽이 없으면 fs는 이전 요청이 완료 될 때까지 더 이상 요청을 발행하지 않으므로 디스크 쓰기 캐시가 활성화되어 있지 않으면 장벽없이 순서를 유지합니다. 장벽의 목적은 충돌시 fs를 손상시키지 않고 쓰기 캐시를 활성화 할 수 있도록하는 것입니다.
sync. 저기 조금 혼잡해서 잊어 버렸습니다 . 다시 시도하겠습니다. 장벽없이 디스크에 쓰는 절차는 저널에 sync쓰는 것이므로 쓰기 캐시를 플러시 한 다음 실제 데이터를 쓰는 것입니다. 이렇게하면 충돌 후 저널을 항상 fs를 복구하는 데 사용할 수 있지만 동기화하면 작업 속도가 느려지고 쓰기 캐시의 목적이 절반으로 줄어 듭니다. 따라서 장벽이보다 나은 대체품으로 추가되었으며 sync적절한 디스크 지원을 통해 동기화가 수행하는 많은 성능을 안전하게 회수 할 수 있습니다.
부정확 한 종료 때문에 단순히 저널링 파일 시스템을 fsck 할 필요가 없습니다.
전체 메타 데이터 저널링의 런타임 성능 저하를 지속 이유는 파일 시스템은 파일 시스템이 정상적으로 마운트 해제 아니었다면 자동으로 마운트 다음에 메타 데이터 로그를 재생하여 다시 일관된 100 %를 할 수 있도록하는 것입니다.
fsck의 유일한 역할은 메타 데이터 일관성을 보장하는 것이므로 파일 시스템이 올바르게 마운트 해제되지 않았기 때문에 fsck를 실행하는 것이 중복됩니다.
저널링 파일 시스템은 하드웨어 오류, 드라이버 버그, 관리자 오류 등 다른 이유로 손상 될 수 있으므로 fsck 도구가 반드시 필요합니다. 부정확 한 종료로 인해 단독으로 호출 할 이유가 없습니다.