.png)
fast_commit대부분의 ext4 파일 시스템에서 너무 빨리 활성화한 것 같고 그 이후로 FS 손상이 자주 발생했습니다. 나는 ext4에서 그런 문제를 겪은 적이 없으며 수년 동안 나에게 매우 견고했습니다.
e2fsck데이터 손실 없이 문제를 해결하는 것이 항상 가능하기 때문에 그다지 나쁜 것은 아니지만 부팅할 수 없는 시스템은 빠르게 쓸모 없게 됩니다.
fast_commit지금은 비활성화했는데 설정할 tune2fs -O "^fast_commit" /dev/partitions때 놓친 부분이 있는지 궁금합니다.
이것이 알려진 문제입니까? 예를 들어 저널 주문 방법을 변경해 볼까요? 나는 그것을 변경하지 않았으므로 변경하거나 관련이 없게 만들지 ordered않는 한 여전히 기본 모드 에 있는 것 같습니다 .fast_commit
답변1
그냥 "나도"라고 말하고 싶었어요. 내 시스템에 fast_commit을 넣었다가 수동 fsck가 필요하여 시스템이 부팅되지 않기 때문에 결국 제거했습니다.
나생각하다fsck가 일부 불일치를 발견하고 fast_commit이 해당 내용을 파일 시스템에 커밋할 기회를 얻지 못하는 경우(정전, 충돌, 아버지가 전원 버튼을 눌러 데스크톱을 종료하기로 결정하는 등) fsck는 신뢰할 수 있습니다. 이 문제를 해결하는 것은 문제가 되지 않지만, fsck는 이러한 상황을 인식하고 이것이 정상임을 인식하도록 업데이트되지 않았으므로 "수동으로 fsck를 실행하고 수동으로 결정"하는 상황에 들어갑니다.
fast_commit이 나왔을 때 그 디자인을 살펴봤더니 매우 보수적이었습니다. 먼저 해당 커밋을 새 로그에 기록한 다음 편리할 때 파일 시스템에 기록합니다. 따라서 최악의 시나리오는 완전한 파일 시스템 충돌 및 데이터 손실이 아니라 파일 시스템 변경의 마지막 몇 초가 손실되는 것입니다.