큰 LVM 디스크 (8TB)를위한 파일 시스템은 무엇입니까?

2TB 디스크가 많은 Linux 서버가 있는데, 모두 현재 LVM에 있으며 약 10TB의 공간이 필요합니다. ext4 파티션에서이 공간을 모두 사용하고 있으며 현재 약 8,8TB의 데이터가 있습니다.

문제는 종종 디스크에 오류가 발생하고 오류가 발생하자마자 교체 (즉, 이전 디스크를 dd를 사용하여 새 디스크에 복사 한 다음 서버에 새 디스크를 넣음)하더라도 나는 종종 약 100MB의 손상된 데이터를 얻습니다. 따라서 e2fsck가 매번 미치게되며 ext4 파일 시스템을 다시 정상 상태로 만드는 데 일주일이 걸립니다.

따라서 질문은 : LVM에서 파일 시스템으로 사용하기를 권장하는 것은 무엇입니까? 아니면 대신 무엇을 권장합니까? (실제로 LVM이 필요하지 않습니다)?

내 파일 시스템의 프로파일 :

• 총 크기가 다른 많은 폴더 (일부 총 2TB, 총 100MB)
• 크기가 다른 거의 200,000 개의 파일 (약 10MB, 100MB와 4GB 사이의 1/4 중 3/4; 현재 ext4 파티션이 며칠 동안 완전히 망쳐 져 파일에 대한 더 많은 통계를 얻을 수 없음)
• 읽기는 많지만 쓰기는 거의 없습니다
• 내결함성이 필요합니다 (전체 디스크에 하나의 오류가있는 것을 좋아하지 않기 때문에 mdadm RAID 사용을 중단했으며 디스크 고장이 발생하여 가능한 한 빨리 교체하지만 손상된 데이터를 얻을 수 있음을 의미합니다) 내 파일 시스템)

가장 큰 문제는 디스크 고장입니다. 파일을 잃을 수는 있지만 동시에 모든 것을 잃을 수는 없습니다.

ext4를 계속 사용한다면 더 작은 파일 시스템을 만들어서 어떻게 병합해야한다고 들었지만 어떻게해야할지 모르겠습니다.

btrfs가 좋을 것이라고 들었지만 데이터가 복제되지 않을 때 디스크의 일부 (또는 전체 디스크)를 잃어 버리는 방법에 대한 단서를 찾을 수 없습니다 ( mkfs.btrfs -d single?).

질문에 대한 조언은 사전에 감사합니다!

파일 시스템 문제가 아니라 디스크의 물리적 한계입니다. 다음은 몇 가지 데이터입니다.

SATA 드라이브는 일반적으로 복구 불가능한 읽기 오류율 (URE)이 10 ^ 14로 지정됩니다. 즉 , 디스크가 제대로 작동하더라도 12TB 당 1 바이트가 복구 불가능하게 손실됩니다 .

즉, RAID가 없으면 드라이브가 고장 나지 않아도 데이터가 손실됩니다 . RAID가 유일한 옵션입니다.

RAID5 (총 용량 n-1, 여기서 n = 디스크 수)를 선택해도 충분하지 않습니다. 6 개의 2TB HDD로 구성된 10TB RAID5를 사용하면 연간 20 %의 드라이브 장애가 발생 하고 단일 디스크 장애가 발생합니다. URE로 인해 RAID5를 성공적으로 재구성하고 데이터의 100 %를 복구 할 확률이 50 %입니다. .

기본적으로 고용량 디스크와 상대적으로 높은 URE를 사용하면 단일 디스크 장애를 다시 방지하기 위해 RAID6이 필요합니다.

이것을 읽으십시오 : http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162

디스크를 위해 RAID를 사용하십시오. 심지어 mdadm이있는 소프트웨어 RAID 일 수도 있습니다. 또한 "디스크에 종종 오류가 발생하는"이유에 대해 생각해보십시오. RAID 등급 디스크 대신 저렴한 데스크탑 급 SATA 드라이브를 사용하는 경우를 제외하고는 정상이 아닙니다.

그 후, 파일 시스템은 더 이상 중요하지 않습니다-ext4, xfs는 모두 훌륭한 선택입니다.

ZFS와 함께 행운을 빕니다. 사용하는 배포판에서 사용할 수 있는지 확인할 수 있습니다. 공정한 경고, 아마도 전체 시스템을 재건하는 것을 의미하지만 실제로는 우수한 성능과 내결함성을 제공합니다.

더 큰 크기의 새 디스크를 점진적으로 추가

LVM 사용에 관심이 있고 여러 드라이브를 처리하려는 경우 간단한 대답은 LVM의 일부인 미러 기능을 사용하는 것입니다. 모든 물리 볼륨을 LVM에 추가하기 만하면됩니다. 논리 볼륨을 생성 할 때 --mirrors옵션을 전달하십시오 . 이것은 데이터를 복제합니다.

다른 옵션은 몇 개의 RAID1 쌍을 설정하는 것입니다. 그런 다음 모든 RAID1 볼륨을 VG에 PV로 추가하십시오. 그런 다음 스토리지를 확장 할 때마다 한 쌍의 디스크를 구입하십시오.

실제로 RAID 5, 6, 10, 50 또는 60을 사용해야합니다. 시작하는 데 도움이되는 자료는 다음과 같습니다.

RAID에 대한 배경 정보

• http://en.wikipedia.org/wiki/RAID
• http://www.techrepublic.com/blog/datacenter/choose-a-raid-level-that-works-for-you/3237

하우투 및 설정

• http://www.dedoimedo.com/computers/linux-raid.html
• http://www.linuxplanet.com/linuxplanet/tutorials/6514/1
• http://dtbaker.com.au/random-bits/ubuntu---howto-easily-setup-raid-5-with-lvm.html

추가 RAID 링크에 대한 맛있는 링크를 확인하십시오 : http://delicious.com/slmingol/raid

데이터 손상이 실제로 걱정된다면 zfs 및 btrfs와 같은 체크섬 파일 시스템을 권장합니다.하지만 btrfs는 여전히 개발 중이며 프로덕션 준비가 아닌 것으로 간주됩니다 .

디스크에서 읽은 데이터 (정상적으로 읽은 데이터)가 올바르다는 보장은 없습니다. 블록에는 체크섬이 있지만 항상 오류를 포착하지는 않는 간단한 체크섬입니다. ZFS와 같은 최신 파일 시스템은 파일에 더 많은 기능을 갖춘 체크섬을 첨부하며 하드 디스크 나 RAID 컨트롤러에서 알 수없는 데이터 오류를 포착하고 복구 할 수 있습니다.

따라 @ C2H5OH 말한다 는 복구 할 수없는이 중요하다 - 그것은 디스크가 이미 시도하고 분야를 다시 읽지 못했습니다 의미합니다.

내 경험상 디스크가 복구 불가능한 읽기 오류 (URE)를 생성하기 시작하면 일부 데이터가 영구적으로 손실되며, GNU ddrescue를 사용하여 모든 데이터를 즉시 백업 하면 실패한 섹터를 다시 시도하고 복구 할 수없는 섹터를 건너 뛸 수 있습니다.

백업이 있다고 가정하면 URE로 인해 백업이 실패했을 수 있으며 파일이 손상되었을 수 있으므로 동일한 파일 시스템의 다양한 백업에서 전체 데이터 세트를 구성해야합니다.

ZFS에 권장하는 다른 답변은 지속적인 데이터 스크러빙 및 RAID 기능이 향후 데이터를 안전하게 유지하는 데 도움이되지만 여전히 백업을 대체 할 수는 없지만 사용자 및 관리자 오류로부터 보호 할 수 있기 때문에 읽을 가치가 있습니다.

스냅 샷이 필요없는 경우에만 LVM을 사용합니다. RAID와 잘 통합되지 않으며, 데이터 스크러빙 / 데이터 체크섬을 포함하지 않으며, 여전히 백업이 필요하므로 ZFS와 같은 것이 더 나은 옵션 일 것입니다. 자세한 내용 은 LVM 문제 및 위험에 대한 답변을 참조하십시오 .