Por muito tempo pensei em versionar sistemas de arquivos. Este é um recurso matador e eu olhei para Wayback, ext3cow, zfs, soluções de fusíveis, ou apenas sobreposições de cvs / svn / git.
Eu considero ext3cow o modelo para minhas necessidades. Transparente, eficiente, mas posso fazer sem o recurso ls abc@timestamp extra. Desde que, de alguma forma, eu tenha versões de meus arquivos automatizadas e transparentes.
Pode ser instantâneo ou pode ser baseado em instantâneos em intervalos de 10s, 30s, 1m, 5m, 15m, etc. Apenas algo que lida eficientemente com milhares de arquivos em um determinado diretório, todos de vários tamanhos, , mas alguns acima de 100m a 1gb.
O ZFS não é realmente uma opção, já que estou no linux (e prefiro não usá-lo através do fusível, já que eu tenho uma configuração ext3 que eu quero para a versão, não algo novo).
Quais soluções estão por aí?
Se você envolver seus sistemas de arquivos usando o LVM, poderá criar um volume de captura instantânea usando a camada de volume lógico subjacente. É um processo bastante simples e surpreendentemente eficaz para coisas "instantâneas" padrão, como backup e desfazer rm -fr oopsies.
Após 8 anos de pesquisa , encontrei o SVNFS por Marco R. Gazzetta (que é diferente do projeto antigo com o mesmo nome de John Madden [em que se fazem coisas diferentes]). Este SVNFS usa svn transparentemente em operações de r / w:
Instead of creating a file system that does its own versioning, I used an existing versioning tool, subversion, and made its use transparent. The advantage is that this file system doesn't require you to learn a new tool, if you know subversion
Está escrito em Python e usa o FUSE:
Now you start the versioning file system by invoking the script attached:
python svnfs.py -o svnroot=/home/marco/svnfiles /home/marco/myfiles
Once everything is fine, you should be able to get a listing of both directories and see that the contents are the same.
Now, if you create (almost) any file in either directory, it will show up on the other side of the fence, as well. The big difference is that if you create a file in the myfiles directory, it will automatically be placed under version control (the opposite is not true).
No exemplo SVNFS usa o diretório separado para o repositório. Embora eu não tenha testado isso. Para as minhas necessidades, gostaria de ter o repositório no meu diretório de trabalho.
Eu também encontrei referência aos recursos de versionamento do Reiser4 4 anos atrás:
See Reiser 4. Files are directories.
eg:
diff -u main.C main.C/r/123Or to access properties
cat main.C/p/svn-eolstyle
echo "foobar" > main.C/p/my-property
It seems that it would be best to follow that model, since a major filesystem is already going that route.
-Paul Querna
Mas eu não verifiquei também.
Dois anos atrás, fui pesquisar mais, encontrei projeto FiST para gerar sistemas de arquivos empilháveis e contatou prof. Erez Zadok da Stony Brook University que foi conselheiro / mentor do projeto chamado versionfs há muito tempo. Citando:
allows users to manage their own versions easily and efficiently. Versionfs provides this functionality with no more than 4% overhead for typical user-like workloads. Versionfs allows users to select both what versions are kept and how they are stored through retention policies and storage policies, respectively. Users can select the trade-off between space and performance that best meets their individual needs: full copies, compressed copies, or block deltas. Although users can control their versions, the administrator can enforce minimum and maximum values, and provide users sensible defaults.
Additionally, through the use of libversionfs, unmodified applications can examine, manipulate, and recover versions. Users can simply run familiar tools to access previous file versions, rather than requiring users to learn separate commands, or ask the system administrator to remount a file system. Without libversionfs, previous versions are completely hidden from users.
Finally, Versionfs goes beyond the simple copy-on-write employed by past systems: we implement copy-on-change. Though at first we expected that the comparison between old and new pages would be too expensive, we found that the increase in system time is more than offset by the reduced I/O and CPU time associated with writing unchanged blocks. When more expensive storage policies are used (e.g., compression), copy-on-change is even more useful.
Pareceu-me muito interessante, mas entrar em contato com os caras que trabalharam no projeto revelou que não há lugar conhecido de seu código-fonte. O próprio professor declarou no correio:
Versionfs's code is very old now, and it only worked in kernel 2.4. If you still want a stackable versioning f/s, then one would have to write it from scratch — possibly based on wrapfs (see wrapfs.filesystems.org/).
Portanto, não há projeto de trabalho aqui, embora o conceito de sistemas de arquivos empilháveis pareça muito bom para mim. Alguém gostaria de iniciar o projeto baseado em wrapfs , notifique-me por favor:)
Você pode verificar gitfs . É um sistema de arquivos FUSE baseado no git, bastante estável e super fácil de usar.
Basicamente, é uma sobreposição do git. Sempre que você atualiza um arquivo ou diretório, ele cria uma confirmação com essa mudança (sabe que deve ordenar os commits para que você não acabe com 100 commits ao descompactar um arquivo). Também sabe sincronizar seu controle remoto e mesclar os conflitos usando a estratégia 'sempre aceite o meu'.
Quando você o monta, ele traz dois diretórios: current e 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
Mais informações podem ser encontradas nesta página .
o bup parece promissor.
Discussão mais antiga sobre isso aqui: link
Experimente o rsnapshot - eu mesmo não o usei, mas deparei com ele enquanto procurava sistemas de desduplicação em nível de arquivo @.
Tags git ext3 filesystems versioning