아카이빙용 파일 시스템

아카이빙용 파일 시스템

내 파일 시스템에 복잡한 읽기 전용 데이터가 있습니다. 여기에는 svn 저장소의 특정 개정판에 대한 수천 개의 스냅샷과 회귀 테스트 결과가 포함되어 있습니다. 스냅샷 간의 동일한 파일은 하드 링크를 사용하여 중복 제거됩니다. 이렇게 하면 저장 용량이 커질 필요는 없지만 여전히 많은 inode를 소비하므로 기본 파일 시스템에 대해 fsck가 엄청나게 길어집니다.

이 데이터를 다른 파일 시스템으로 이동하여 기본 파일 시스템에 너무 많은 영향을 미치지 않도록 하고 싶습니다. 추천 메뉴가 무엇인가요? Squashfs가 가능한 옵션처럼 보이지만 하드 링크를 효율적으로 처리할 수 있는지 확인해야 합니다.

답변1

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

나는 또한 squashfs가 중복 파일을 투명하게 제거할 수 있으므로 하드 링크를 처리하지 않더라도 여전히 이점을 볼 수 있다고 생각합니다(비록 이에 대해 확신할 수는 없지만). 파일 시스템의 데이터를 변경할 필요가 없다면 fsck를 md5sum으로 대체할 수 있으므로 squashfs가 아마도 최선의 선택일 것입니다.)

답변2

내가 선호하는XFS왜냐하면 나는 이 파일 시스템에 대해 좋은 경험을 갖고 있기 때문입니다. 하지만 데이터와 제안된 모든 파일 시스템을 테스트해 보시기를 진심으로 권장합니다.

답변3

fsck가 느린 경우 ext4를 사용해 보셨나요? fsck를 매우 빠르게 만들기 위해 몇 가지 기능을 추가했습니다.사용하지 않는 inode를 보지 마십시오:

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

답변4

나는 그것을 사용하는 여러 상점을 알고 있습니다.데이터 필드이러한 목적을 위한 것입니다.

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

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

FreeBSD가 ZFS v23을 갖게 되면 나머지 사람들도 중복 제거를 사용할 수 있게 됩니다.

관련 정보