보관을위한 파일 시스템

파일 시스템에 복잡한 읽기 전용 데이터가 있습니다. 여기에는 svn 저장소의 특정 개정판에 대한 수천 개의 스냅 샷과 회귀 테스트 결과가 포함됩니다. 스냅 샷 사이의 동일한 파일은 이미 하드 링크를 사용하여 중복 제거되었습니다. 이런 식으로 저장 용량이 클 필요는 없지만 여전히 많은 inode를 소비하므로 주 파일 시스템의 경우 fsck가 너무 오래 걸립니다.

이 데이터를 다른 파일 시스템으로 이동하여 기본 파일 시스템에 큰 영향을 미치지 않도록하고 싶습니다. 당신은 제안이 있습니까? Squashfs가 가능한 선택 인 것 같지만 하드 링크를 효율적으로 처리 할 수 ​​있는지 확인해야합니다.

fsck 속도 저하가 발생하면 ext4를 사용해 보셨습니까? 그들은 사용되지 않는 inode를 보지 않고 fsck를 정말 빠르게 만드는 몇 가지 기능을 추가했습니다 .

Fsck는 파일 시스템의 모든 inode를 검사하는 첫 번째 단계 인 매우 느린 작업입니다. Ext4에서는 각 그룹의 inode 테이블 끝에 사용되지 않은 inode 목록 (안전을 위해 체크섬과 함께)이 저장되므로 fsck는 이러한 inode를 확인하지 않습니다. 그 결과 사용 된 inode 수 (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4)에 따라 총 fsck 시간이 2 ~ 20 배 향상됩니다. 사용되지 않는 inode 목록을 작성하는 Ext4가 아니라 fsck라는 점에 유의해야합니다. 즉, 사용하지 않는 inode 목록을 만들려면 fsck를 실행해야하며 다음 fsck 실행 만 더 빠릅니다 (Ext3 파일 시스템을 Ext4로 변환하려면 fsck를 전달해야 함). 이 fsck 속도 향상에 참여하는 기능도 있습니다- "유연한 블록 그룹"

Btrfs는 스냅 샷을 기본적으로 지원하므로 중복 제거를 위해 하드 링크를 사용할 필요가 없습니다. btrfs 파일 시스템을 작성하고 필요한 가장 빠른 개정판으로로드하고 스냅 샷을 작성한 다음 스냅 샷이 필요한 각 시점으로 리포지토리를 수정하여 현재 설정을 다시 작성할 수 있습니다. 단계. 이는 하드 링크보다 효율적이며 설정도 더 간단해야합니다.

또한 squashfs는 파일을 투명하게 중복 제거하므로 하드 링크를 처리하지 않더라도 여전히 이점을 볼 수 있다고 생각합니다. 파일 시스템에서 데이터를 변경할 필요가 없다면, fsck를 md5sum으로 대체 할 수 있기 때문에 squashfs를 사용하는 것이 좋습니다.)

이 파일 시스템에 대한 경험이 많기 때문에 XFS를 선호 합니다. 그러나 실제로 데이터와 테스트 된 모든 파일 시스템으로 테스트하는 것이 좋습니다.

그 목적을 위해 DataDomain 을 사용하는 여러 상점을 알고 있습니다 .

보관 스크립트는 매우 단순 할 수 있으며 (예 : tar 또는 rsync 및 cron) 하드 링크 나 대부분의 파일 시스템에서 하드 링크 할 수없는 디렉토리 관리에 대해 걱정할 필요가 없습니다. 대역폭을 절약하기 위해 증분 복사가 필요하지 않습니다. 모든 마법은 블록 레이어 내에서 발생합니다. 1-2TB의 실제 디스크 공간 만 사용하면서 15-20TB의 가상 데이터를 호스팅하는 것은 드문 일이 아닙니다. 여전히 디스크 백업을 위해 남은 부분이 많습니다.

데이터가 NFS 또는 iSCSI를 통해 제공되지만 문제인지 확실하지 않습니다.

FreeBSD가 ZFS v23을 얻었을 때, 우리 모두에게 중복 제거가 가능할 것입니다.