파일 시스템 버전 관리에 대해 오랫동안 생각해 왔습니다. 이것은 킬러 기능이며 Wayback, ext3cow, zfs, 퓨즈 솔루션 또는 cvs / svn / git 오버레이를 살펴 보았습니다.
내 요구 사항에 대한 모델을 ext3cow로 간주합니다. 투명하고 효율적이지만 추가 ls abc@timestamp기능 없이 할 수 있습니다. 어떻게 든 파일의 자동화 된 투명 버전을 얻는 한.
10s, 30s, 1m, 5m, 15m 등의 간격으로 스냅 샷을 기반으로하거나 순간적으로 생성 될 수 있습니다. 주어진 디렉토리에있는 수천 개의 파일을 다양한 크기, 가장 작지만 일부 파일을 효율적으로 처리 할 수있는 것 100m ~ 1gb 이상
ZFS는 내가 리눅스에있는 것처럼 실제로 옵션이 아닙니다 (그리고 내가 버전 화하려는 ext3 설정이 이미 있기 때문에 퓨즈를 통해 사용하지 않는 것을 선호합니다).
어떤 솔루션이 있습니까?
답변:
8 년 동안 검색 한 결과 Marco R. Gazzetta 의 SVNFS ( John Madden 의 동일한 이름을 가진 이전 프로젝트와 다릅니다) (다른 작업을 수행함) 를 발견했습니다 . 이 SVNFS 는 r / w 작업에서 svn을 투명하게 사용 합니다.
자체 버전 관리를 수행하는 파일 시스템을 만드는 대신 기존 버전 관리 도구 인 subversion을 사용하여 투명하게 사용했습니다. 장점은이 파일 시스템은 서브 버전을 알고 있다면 새로운 도구를 배울 필요가 없다는 것입니다
파이썬으로 작성되었으며 FUSE를 사용합니다.
이제 첨부 된 스크립트를 호출하여 버전 화 파일 시스템을 시작하십시오.
python svnfs.py -o svnroot=/home/marco/svnfiles /home/marco/myfiles
모든 것이 잘되면 두 디렉토리의 목록을 얻을 수 있으며 내용이 동일한 지 확인할 수 있습니다.
이제 어느 디렉토리에 파일 (거의)을 만들면 펜스의 다른 쪽에도 파일이 나타납니다. 가장 큰 차이점은 myfiles 디렉토리에 파일을 작성하면 자동으로 버전 제어 아래에 배치됩니다 (반대가 사실이 아님).
예제에서 SVNFS 는 저장소에 별도의 디렉토리를 사용합니다. 테스트하지는 않았지만. 내 필요에 따라 작업 디렉토리에 저장소를 갖고 싶습니다.
또한 4 년 전 Reiser4 의 버전 관리 기능에 대한 참조를 찾았습니다 .
Reiser 4를 참조하십시오. 파일은 디렉토리입니다.
예 :
diff -u main.C main.C/r/123또는 속성에 액세스
cat main.C/p/svn-eolstyle
echo "foobar" > main.C/p/my-property
주요 파일 시스템이 이미 그 경로로 가고 있기 때문에 해당 모델을 따르는 것이 가장 좋습니다.
폴 쿠 에르 나
그러나 나는 그것을 점검하지 않았다.
2 년 전에 추가 검색을 하기 위해 쌓을 수있는 파일 시스템을 생성하는 프로젝트 FiST 를 발견 하고 교수에게 연락했습니다. Stony Brook University 의 Erez Zadok 은 오래 전에 versionfs 라는 프로젝트의 고문 / 멘토였습니다 . 인용 :
http://www.fsl.cs.sunysb.edu/docs/versionfs-fast04/
http://www.fsl.cs.sunysb.edu/docs/versionfs-msthesis/versionfs.pdf
사용자는 자신의 버전을 쉽고 효율적으로 관리 할 수 있습니다. Versionfs는 일반적인 사용자와 유사한 워크로드에 대해이 기능을 4 % 이하의 오버 헤드로 제공합니다. Versionfs를 사용하면 보관 정책과 보관 정책을 통해 보관할 버전과 보관 방법을 모두 선택할 수 있습니다. 사용자는 전체 사본, 압축 사본 또는 델타 차단과 같이 개별 요구에 가장 적합한 공간과 성능 간의 균형을 선택할 수 있습니다. 사용자는 버전을 제어 할 수 있지만 관리자는 최소값과 최대 값을 적용하고 사용자에게 합리적인 기본값을 제공 할 수 있습니다.
또한 libversionfs를 사용하면 수정되지 않은 응용 프로그램이 버전을 검사, 조작 및 복구 할 수 있습니다. 사용자는 별도의 명령을 익히거나 시스템 관리자에게 파일 시스템을 다시 마운트하도록 요구하지 않고 친숙한 도구를 사용하여 이전 파일 버전에 액세스 할 수 있습니다. libversionfs가 없으면 이전 버전은 사용자에게 완전히 숨겨집니다.
마지막으로, Versionfs는 과거 시스템에서 사용했던 간단한 copy-on-write를 뛰어 넘습니다. 처음에는 이전 페이지와 새 페이지 간의 비교가 너무 비쌀 것으로 예상했지만 시스템 시간 증가는 변경되지 않은 블록 쓰기와 관련된 I / O 및 CPU 시간 감소로 인해 상쇄되는 것으로 나타났습니다. 더 비싼 스토리지 정책이 사용되는 경우 (예 : 압축) 변경시 복사가 훨씬 더 유용합니다.
그것은 나에게 매우 흥미로워 보이지만 프로젝트에서 일한 사람들에게 연락하면 그 소스 코드의 알려진 곳이 없다는 것을 알았습니다. 교수 자신은 우편으로 다음과 같이 언급했다.
Versionfs의 코드는 현재 매우 오래되었으며 커널 2.4에서만 작동했습니다. 여전히 스택 가능한 버전 관리 f / s를 원한다면 wrapfs를 기반으로 처음부터 작성해야합니다 (wrapfs.filesystems.org/ 참조).
따라서 스택 가능한 파일 시스템의 개념이 나에게 매우 좋은 것처럼 보이지만 여기에는 작동하는 프로젝트가 없습니다. 하고 싶은 누군가는 ONF 기반 프로젝트 시작 wrapfs을 나에게 알려주세요 :)
gitfs 를 확인할 수 있습니다 . git 기반의 FUSE 파일 시스템으로 매우 안정적이며 사용하기 쉽습니다.
기본적으로 git 위에 오버레이입니다. 파일이나 디렉토리를 업데이트 할 때마다 해당 변경 사항으로 커밋이 생성됩니다 (아카이브를 압축 해제 할 때 커밋을 일괄 처리하여 100 개의 커밋으로 끝나지 않음). 또한 '항상 승인'전략을 사용하여 리모컨을 동기화하고 충돌을 병합하는 것도 알고 있습니다.
마운트하면 current 와 history의 두 디렉토리가 나타납니다 .
├── current
│ ├── test1.md
│ ├── test2.md
│ ├── test3.md -> current/test2.md
│ ├── test4.md
│ └── test_directory
└── history
├── 2014-11-23
│ ├── 20-00-21-d71d1579a7
│ │ └── testing.md
│ └── 20-42-32-7d09611d83
│ ├── test2.md
│ └── testing.md
├── 2014-12-08
│ ├── 16-38-30-6d6e71fe47
│ │ ├── test2.md
│ │ └── test1.md
자세한 내용은이 페이지를 참조하십시오 .
bup은 유망 해 보인다.
그것에 대한 이전 토론 : http://lwn.net/Articles/380983/
rsnapshot을 사용해보십시오. 내가 직접 사용하지는 않았지만 @ 파일 수준 중복 제거 시스템을 보면서 넘어졌습니다.
R1Soft의 Hot Copy를 살펴보십시오.
http://www.r1soft.com/tools/linux-hot-copy/
LVM을 사용하지 않고 표준 시스템에 대한 COW (Copy-On-Write) 스냅 샷을 제공하는 커널 모듈입니다. 그것은 나를 위해 상당히 잘 작동했으며 재부팅하지 않고 설치할 수 있습니다.