11 월 중순에 호스팅 회사에서 임대하는 VPS가 응답을 멈췄습니다. 지원 부서에 연락했을 때 데이터 센터의 정전으로 인해 강제 재부팅 및 fsck가 발생했다고 설명했습니다. 결국, 왜 그렇게 오래 걸 렸는지 물었고 볼륨 크기가 30TB라고 들었습니다. 마지막으로 업데이트를받은 시간은 2 월이며 가장 최근의 문의에 응답하지 않았습니다.
일부 파일 시스템의 경우 fsck가 매우 느릴 수 있지만 fsck가 30TB 볼륨에서 6 개월이 걸릴 수 있음을 이해합니다. 달?
답변
fsck속도는 주로 파일 수와 파일이 각 디렉토리에 분산되는 방식에 따라 다릅니다. 즉, 6 개월 동안 fsck은 절대로 터무니없는 것입니다. 특히 xfs빠른 xfs_repair유틸리티를 사용 하는 경우 몇 시간 안에 완료해야 합니다. 여기서fsck 1 시간 (3600 초) 내에 완료된 규모로 달리기를 찾을 수 있습니다 . 따라서 fsck아직 실행 중일 수 없습니다 .
어쨌든, 예기치 못한 전력 손실이됩니다 하지 전체 타격의 원인이 fsck아니라 단지 매우 빠른 (일부 초) 저널 재생을 . 그러나 일부 키 파일이 손상된 경우 OS를 부팅 할 수 없습니다.
그러나 그들은 아마도 당신에게 거짓말을했을 것입니다. 즉시 지불을 중단하고 설명을 요청한 후 전체 환불을 신청해야합니다.
답변
결론 : 시스템은 최소한의 비용으로 최대 성능을 얻기 위해 가장 강력한 설정으로 가능한 모든 쓰기 캐시 (하드 드라이브 자체를 포함하여)를 포함한 BBU / FBWC없는 RAID (또는 소프트웨어 RAID)를 사용합니다. 이러한 설정으로 인해 정전이 발생하면 저널을 신뢰할 수없고 복구에 사용할 수없는 상태에서 저널링 파일 시스템이 남을 수 있습니다. 문제는 그러한 시스템이 적극적으로 쓰기 순서를 변경하고 연기한다는 것입니다. 즉, 데이터 작업 손실의 결과로 저널 항목을 쓸 수 있거나 결과적으로 발생한 데이터 작업에서 저널 항목이 손실 될 수 있습니다.
최악의 정전에서 이러한 시스템을 복구한다는 것은 실제로 모든 파일 시스템 구조를 실제로 검사하는 “느린”fsck / 수리를 수행해야한다는 것을 의미 할 수 있습니다. 실제로 30TB에 하루나 이틀이 걸릴 수 있습니다. 여러 복구주기를 실행해야 할 가능성은 없습니다. 직원이 항상이를 모니터링 할 수있는 것은 아니라는 점에 덧붙여 일주일에 한 fsck까지 쉽게 수행 할 수 있습니다. 그들은 아마 포기하고 잊었다.
답변
대부분의 파일 시스템의 경우 일반적으로 메타 데이터 만 확인되므로 오류가 있어도 훨씬 빠릅니다.
최악의 경우 30TB 동안 며칠이 걸릴 수 있는 전체 디스크를 읽을 수 있습니다 ( 예 : 와 같이 fsck.ext4 -cc /dev/sda모든 블록에서 비파괴 쓰기 테스트 수행). 드라이브의 속도를 알고 있다면 크기 / 속도를 계산할 수 있습니다 . 약 100MB / s의 복사 속도 를 가진 소비자 용 하드 드라이브 의 경우 몇 TB가 대부분의 사람들이 예상하는 것보다 더 많은 시간이 걸릴 수 있습니다.
서버 인 fsck경우 오류를 수정할 것인지 묻는 메시지 가 표시되면 부팅 된 다음 중단 되는 문제가 발생할 수 있습니다. 그러나 fsck모든 VPS가 오프라인 상태 인 동안 데이터 센터 관리자는 6 개월 동안 중단 되지 않습니다 .
그래서 그들은 당신에게 거짓말을하거나 큰 오해가 있습니다. 또는 그들은 얼마 전에 fsck를 실행 중이며 새로운 문제가 완료된 후에 업데이트하지 않았습니다.
