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

Я долго думал о версии файловых систем. Это убийственная функция, и я смотрел на Wayback, ext3cow, zfs, fuse solutions или просто наложения cvs / svn / git.

Я считаю ext3cow моделью для моих требований. Прозрачный, эффективный, но я могу обойтись без дополнительной ls abc@timestampфункции. Пока я каким-то образом получаю автоматическое, прозрачное управление версиями моих файлов.

Это может быть мгновенно или основано на моментальных снимках с интервалами в 10, 30, 1, 5, 15 м и т. Д. Просто то, что будет эффективно работать с тысячами файлов в данном каталоге всех размеров, в основном небольших, но некоторых свыше 100 м до 1 ГБ.

ZFS на самом деле не вариант, так как я нахожусь на Linux (и предпочел бы не использовать его через fuse, так как у меня уже есть настройка ext3, которую я хочу версии, а не что-то новое).

Какие есть решения?

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

После 8 лет поиска я нашел SVNFS по Марко Р. 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 

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

Пол Керна

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

Два года назад я отправился на поиски, нашел проект 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/).

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

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

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

Когда вы монтируете его, он приносит вам две директории: текущую и историю . ├── 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

Более подробную информацию можно найти на этой странице .

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

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

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

Взгляните на Hot Copy от R1Soft.

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

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

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