Как я получаю прозрачное, эффективное создание снимков файловой системы или управление версиями на ext3/4?

Если Вы переносите свои файловые системы с помощью LVM, то можно создать объем снимка с помощью базового слоя логического тома. Это - довольно простой процесс и удивительно эффективный для стандарта "snapshotty" вещи, такие как резервное копирование и отмена rm -fr oopsies.

Попробуйте rsnapshot - я не использовал его сам, но я наткнулся на него при взгляде системы дедупликации уровня файла.

Смотрите на Горячую Копию с R1Soft.

http://www.r1soft.com/tools/linux-hot-copy/

Это - модуль ядра, который обеспечивает снимки копии на записи для стандартных систем, не используя LVM. Это работало довольно хорошо на меня, и я могу установить его без перезагрузки.

Также см.: http://www.r1soft.com/tools/linux-hot-copy/hcp-tips/

bup выглядит многообещающим.

Более старое обсуждение его здесь: http://lwn.net/Articles/380983/

После 8 лет поиска я нашел SVNFS от Marco R. Gazzetta (который отличается от старого проекта с то же имя от Джона Мэддена [который делает разные вещи]). Эта SVNFS прозрачно использует svn в операциях чтения / записи:

Вместо создания файловой системы, которая выполняет собственное управление версиями, я использовал существующий инструмент управления версиями, Subversion, и сделал ее использовать прозрачный. Преимущество этой файловой системы в том, что вам не нужно изучать новый инструмент, если вы знаете subversion

. Она написана на Python и использует FUSE:

Теперь вы запускаете файловую систему управления версиями, вызывая прикрепленный скрипт:

python svnfs.py -o svnroot=/home/marco/svnfiles /home/marco/myfiles

Когда все в порядке, вы сможете получить список обоих каталогов и убедиться, что их содержимое одинаково.

Теперь, если вы создадите (почти) любой файл в любом каталоге, он появится по другую сторону забора, как хорошо. Большая разница в том, что если вы создаете файл в каталоге myfiles, он автоматически будет помещен в систему контроля версий (обратное неверно).

В примере SVNFS использует отдельный каталог для репо. . Хотя не тестировал. Для моих нужд я хотел бы иметь репозиторий прямо в моем рабочем каталоге.

Я также нашел ссылку на возможности управления версиями Reiser4 4 года назад:

См. Reiser 4. Файлы - это каталоги .

например: diff -u main.C main.C / r / 123

Или для доступа к свойствам

cat main.C/p/svn-eolstyle

echo "foobar" > main.C/p/my-property 

Кажется, было бы лучше следовать этой модели, файловая система уже идет по этому пути.

-Paul Querna

Но я тоже не проверял.

Два года назад я продолжил поиск, нашел проект FiST для создания стекируемых файловых систем и связался с проф. Эрез Садок из Университета Стоуни-Брук , который давным-давно был советником / наставником проекта 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 выходит за рамки простого копирования при записи, использовавшегося в прошлых системах: мы реализуем копирование при изменении. Хотя сначала мы ожидали, что сравнение старых и новых страниц будет слишком дорогостоящим, мы обнаружили, что увеличение системного времени более чем компенсируется сокращением времени ввода-вывода и процессорного времени, связанного с записью неизмененных блоков. Когда используются более дорогие политики хранения (например, сжатие), копирование при изменении становится еще более полезным.

Мне это показалось очень интересным, но общение с ребятами, работавшими над проектом, показало, что это неизвестное место. исходный код. Сам профессор заявил по почте:

Код Versionfs сейчас очень старый, и он работал только в ядре 2.4. Если вам по-прежнему нужен стекируемый f / s для управления версиями, то придется написать его с нуля - возможно, на основе wrapfs (см. Wrapfs.filesystems.org/).

Таким образом, здесь нет рабочего проекта, хотя концепция стекируемых файловых систем мне кажется очень милым.

Вы можете проверить gitfs . Это файловая система FUSE, основанная на git, довольно стабильная и очень простая в использовании.

По сути, это наложение поверх git. Всякий раз, когда вы обновляете файл или каталог, он создает фиксацию с этим изменением (знает, что нужно обработать коммиты, поэтому вы не получите 100 коммитов при распаковке архива). Также знает, как синхронизировать ваш пульт и объединить конфликты, используя стратегию «всегда принимать мой».

Когда вы монтируете его, он открывает вам два каталога: текущий и история . ├── текущий │ ├── test1.md │ ├── test2.md │ ├── test3.md -> current / test2.md │ ├── test4.md │ └── test_directory └── история ├── 23.11.2014 │ ├── 20-00-21-d71d1579a7 │ │ └── testing.md │ └── 20-42-32-7d09611d83 │ ├── test2.md │ └── testing.md ├── 08.12.2014 │ ├── 16-38-30-6d6e71fe47 │ │ ├── test2.md │ │ └── test1.md

Дополнительную информацию можно найти на этой странице .