기본적으로 180 일 또는 몇 번의 마운트 후, 대부분의 Linux 파일 시스템은 파일 시스템 검사 (fsck)를 강제 실행합니다. 물론 이것은 ext2 또는 ext3에서 tune2fs -c 0 -i 0을 사용하여 끌 수 있습니다.
작은 파일 시스템에서이 검사는 단지 불편합니다. 그러나 파일 시스템이 더 크면이 검사를 완료하는 데 몇 시간이 걸릴 수 있습니다. 사용자가 생산성을 위해이 파일 시스템에 의존하는 경우 NFS를 통해 홈 디렉토리를 제공한다고 가정하면 예약 된 파일 시스템 검사를 비활성화 하시겠습니까?
이 질문은 현재 오전 2시 15 분이므로 완료하기 위해 매우 긴 fsck (ext3)를 기다리고 있습니다!
답변:
180 일 기본 fsck 시간은 ext3이 온라인 일관성 검사를 지원하지 않는 설계 결함에 대한 해결 방법입니다. 실제 솔루션은이를 지원하는 파일 시스템을 찾는 것입니다. 성숙한 파일 시스템이 있는지 모르겠습니다. 진짜 비극입니다. 아마도 btrfs는 언젠가 우리를 구할 것입니다.
표준 유지 관리의 일환으로 전체 fsck를 사용하여 예약 된 재부팅을 수행하여 fsck에서 여러 시간 동안 다운 타임이 발생하는 문제에 응답했습니다. 이것은 생산 시간 동안 경미한 부패가 발생하여 실제 가동 중단으로 전환되는 것보다 낫습니다.
문제의 큰 부분은 ext3이 fsck를 느리게 느리게한다는 것입니다. xfs는 fsck가 훨씬 빠르지 만 배포에 너무 많은 메모리를 사용하여 큰 파일 시스템에서 기본적으로 xfs를 권장합니다. 그러나 대부분의 시스템에서 이것은 문제가 아닙니다. xfs로 전환하면 최소한 fsck가 상당히 빨라집니다. 이로 인해 일반적인 유지 관리의 일환으로 fsck를 쉽게 예약 할 수 있습니다.
RedHat을 실행 중이고 xfs 사용을 고려하고 있다면 xfs 사용을 얼마나 강력하게 억제하고 있으며 실행중인 커널에서 xfs를 사용하는 사람이 거의 없다는 사실에주의해야합니다.
내 이해는 ext4 프로젝트가 적어도 fsck 성능을 향상시키는 목표를 가지고 있다는 것입니다.
이것이 프로덕션 서버가 단독으로 실행되지 않아야하며 항상 핫 / 콜드 백업이 있거나 두 개의 노드 클러스터에 참여해야하는 또 다른 이유라고 말할 수 있습니다. 오늘날의 가상화에서는 물리적 주 서버와 가상 서버를 쉽게 가질 수 있습니다.이 가상 서버는 X 일마다 수행되는 물리적 사본 만 인계받을 수 있습니다.
그렇지 않으면 이것은 도움이되지 않는 대답입니다. 데이터의 중요성에 균형을 맞춰야한다고 말하고 싶습니다. 이것이 단지 클러스터 노드 인 경우 건너 뛰십시오. 이것이 클라이언트의 백업되지 않은 웹 서버 인 경우 다음에 미리 계획 할 수 있습니다. :-)
예를 들어 QMail 스택을 실행하는 정기 유지 관리를 위해 한 대의 서버가 다운되었습니다. QMail은 시간이 지남에 따라 많은 파일을 생성하고 죽이고 매우 바쁜 메일 서버였습니다. fsck는 약 36 시간이 걸렸습니다. 우리가 거래에서 많은 성능을 저축하지는 않았지만 궁극적으로 파일 시스템이 더 건강하다고 주장 할 수 있다고 생각합니다. 그래도 혼란이 가치가 있습니까? 아니. 에서. 모두.
XFS는 흥미 롭습니다. 항상 일관된 FS입니다. fsck가 필요하지 않습니다. fsck로 인해 다운 타임이 발생하지 않습니다.
그러나 다른 문제가 있습니다. HDD 불량 블록 처리를 지원하는 RAID 컨트롤러가 필요합니다.
XFS에는 OS가 불량 블록에 대해 알기 시작하고 HDD 하드웨어 불량 블록 목록이 가득 찬 경우 불량 블록을 블랙리스트에 추가하는 기능이 없습니다.
ext2 / 3 / 4, fat, ntfs 등 (오프라인 테스트)은 불량 블록을 블랙리스트에 올릴 수 있지만 XFS는 차단할 수 없습니다.
따라서 비 기업용 설치의 경우 XFS가 적합하지 않을 수 있습니다. 내용이 시간이 지남에 따라 크게 바뀌지 않는 작은 파일이 많은 백업 파티션에 Linux 소프트웨어 raid1과 함께 XFS를 사용하고 있습니다.