файловый логический менеджер поверх различных ФС?

Как ты себе это представляешь? Я что-то совсем не понял.

Как я себе это представляю, а что сложного?
Файловые системы производящие каскадно-объединённое монтирование других файловых систем существуют: unionfs, aufs.
Так вот сделать подобное типа MigrateFS, подключить две ветки master, slave, запустить процесс миграции, ну и все ждать окончания.

все новые файлы либо модифицированные пишутся на slave, так же в бекграунде с пониженным приоритетом идет копирование с master на slave.

Я никак в толк не возьму, тебе нужна миграция в виде «превращения» одной ФС в другую без привлечения дополнительного свободного пространства?

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

Последний вопрос: миграция в пределах одного физического устройства, которое полностью занято изначальной ФС на другой тип ФС (/dev/sda1 (ext3) -> /dev/sda1 (XFS)? Если да, то это невозможно без конвертации, которая, понятно, доступна лишь для небольшого количества случаев. Если надо гладко перенести ФС на другое устройство без её превращения в другой тип — это умеет LVM.

Если же нужно что-то другое, то формулируй задачу в более конкретных терминах, с привлечением имён устройств и типов ФС, а то получается угадайка какая-то.

про LVM я знаю и использую.
Просто пример: есть 5.5Tb XFS с данными, есть 8 Tb свободный (хочу Ext4).
Хочу в онлайне поиметь все данные с первого на второй.
rsync как бы пока не вариант (на каждый файл жрет 120 байт оперативы, а ну файлов очень много, но за неимением лучшего придется воспользоваться)

2megabaks
а вы лучше удалите свой бред пока другие не увидели...

Теперь ясно. rsync не гарантирует консистентности файлов. Тут либо закрытие всех открытых на запись файлов, потом rsync, либо оффлайновый перенос. Снапшот LVM (плюс xfs_freeze) может обеспечить консистентность при «живом» копировании, но не поможет иметь на приёмнике изменения файла после. ИМХО, самое простое — временно обеспечить закрытие всех открытых на запись файлов, если это возможно.

Если существует готовое решение для идеальной миграции, то оно, видимо, должно быть на FUSE, поскольку в ядре ничего такого нет, либо мне оно не известно.

и вот давайте представим универсальный механизм для миграции, назовем MigrateFS.
Подключаются в него понятно, две ветки master (ФС с данными), slave (ФС куда будем мигрировать).
Запускается процесс миграции, который подразумевает собой конечно же копирование с xattrs, acl и т.п., и все новые, измененные файлы пишутся на slave.
В результате после миграции мы имеем два снапшота, неизмененные данные на master (можно назвать это бекапом), и текущее состояние на slave.

И да вы правы, В ситуации с копированием через rsync, мне придется повторить это копирование в процессе несколько раз.

LVM умеет мигрировать с физического тома на физический том online

если в терминах LVM, меня скорей всего интересуют логические тома.

>>Запускается процесс миграции, который подразумевает собой конечно же копирование с xattrs, acl и т.п., и все новые, измененные файлы пишутся на slave.

shared fs какую-нибудь прозреваю нужно.

а если без извратов - в zfs можно сделать снапшот, zfs send его на другой сторадж. когда готово, остановить io, по желанию инкрементал снапшот, и поменять точку монтирования. запускай. готого.

не для пропаганды, скорее hint.

Как бы тебе сказать... При наличии пункта

остановить io

это можно сделать и без zfs.

как бы тебе сказать... тут вопрос насколько остановить...
и как обеспечить актуальное состояние того что намигрируешь...

ну и последнюю строчку перечитай

Снапшот. Я выше писал. И zfs никак не поможет с миграцией на другой тип ФС.

>>Снапшот.

остановить io на время снятия снапшота, занятная перспектива, если еще и пару терабайт. про lvm ведь повесть?

И zfs никак не поможет с миграцией на другой тип ФС.

zfs sharenfs(smb) и копируй со снапшота куда угодно.

>> остановить io на время снятия снапшота, занятная перспектива

Где я это предложил?

дак lvm по дефолту «предлагает».

Только на время создания снапшота.

что значит только? это и есть главное различие и называется offline на время создания снапа.

>> что значит только?

Около секунды у меня сейчас ушло на эту операцию. Много?

дак тож поди инкрементал на уже сделаный?

~ # lvs
  LV   VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  boot vg   -wi-ao  64.00m                                      
  repo vg   -wi-ao  40.00g                                      
  root vg   -wi-ao 512.00m                                      
  tmp  vg   -wi-ao 256.00m                                      
  usr  vg   -wi-ao   6.00g                                      
  var  vg   -wi-ao   1.00g                                      
~ # time lvcreate -L1G -s -n varbackup /dev/vg/var
  Logical volume "varbackup" created

real	0m0.601s
user	0m0.000s
sys	0m0.036s
~ # lvs
  LV        VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  boot      vg   -wi-ao  64.00m                                      
  repo      vg   -wi-ao  40.00g                                      
  root      vg   -wi-ao 512.00m                                      
  tmp       vg   -wi-ao 256.00m                                      
  usr       vg   -wi-ao   6.00g                                      
  var       vg   owi-ao   1.00g                                      
  varbackup vg   swi-a-   1.00g var      0.01 
~ # file -s /dev/vg/varbackup 
/dev/vg/varbackup: symbolic link to `../dm-7'
~ # file -s /dev/dm-7 
/dev/dm-7: Linux rev 1.0 ext4 filesystem data, UUID=6b2089cf-31a1-4b0a-8c79-19c44b84b2e1, volume name "VAR" (extents) (large files) (huge files)
~ # mount /dev/vg/varbackup /mnt/tmp/
~ # df
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg-root   504M  153M  326M  32% /
tmpfs                 1.5G     0  1.5G   0% /lib/init/rw
udev                  1.5G  232K  1.5G   1% /dev
tmpfs                 1.5G   92K  1.5G   1% /dev/shm
/dev/mapper/vg-boot    62M   22M   41M  36% /boot
/dev/mapper/vg-repo    40G   32G  7.8G  81% /repo
/dev/mapper/vg-tmp    256M  368K  256M   1% /tmp
/dev/mapper/vg-usr    6.0G  3.6G  2.4G  61% /usr
/dev/mapper/vg-var   1008M  285M  673M  30% /var
tmpfs                 256M  368K  256M   1% /tmp
/dev/md126            247G  205G   30G  88% /home/gotf
/dev/mapper/vg-varbackup
                     1008M  285M  673M  30% /mnt/tmp

Или что?

В порядке бреда (сорри, давно не курил тему): прикрыть источник UnionFS'ом, на котором будут фиксироваться изменения. Источник в RO, его копируем куда следует. Потом каким-то образом синкаем UnionFS уже с таргетом.

или что, это меня от привычек понесло, zfs send идет автоматом в скриптах, если надо, и я приписал это время туда же.
но лишний останов не отменяет :р

Есть какя-то то ли fuse, то ли самостоятельная, в общем, CoW FS. Монтируем в ней исходную FS в RO, в качестве задней указываем целевую FS, и запускаем в screen'е самописную программу/скрипт, вся задача которой-- открыть файл, прочитать блок, записать его на старое место, по окончании записи выставить исходные дату и время файла. По её окончании имеем на целевой FS копию исходной, без остановки на копирование.

GlusterFS поможет