mhddfs: модуль FUSE для объединения нескольких файловых систем (В одну большую виртуальную)

[rm_]

Недавно созданный нашим соотечественником Дмитрием Обуховым модуль файловой системы FUSE под названием mhddfs позволяет объединить несколько обычных файловых систем в одну большую «виртуальную», которая будет содержать в себе не только все файлы объединённых ФС, но и всё их свободное место. Кроме того, в отличии от других подобных модулей, этот не ограничивает возможность записи на виртуальную объединённую ФС, а автоматически распределяет новые файлы по тем физическим дискам, где ещё есть свободное место.

• Официальный сайт
• Страница пакета в Debian
• Статья-описание примера использования

[(asper]

Только почему-то в той статье ничего не сказано про lvm.

[rm_]

Вдогонку, ссылка на сайт автора - http://mhddfs.uvw.ru/ (только что её случайно обнаружил в copyright-файле).
Про LVM там упомянуто:

Данный драйвер представляет собой высокоуровневую надстройку над файловой системой (в отличие от скажем LVM, которая может предоставить эту же функциональность но на более низком уровне), поэтому при изменении количества участвующих в работе файловых систем Вам не требуется запускать средства вроде fsck/resize*fs для того чтобы восстановить работоспособность системы.

[AEK]

Если мне не изменяет память, unionfs можно настроить точно так же. И благодаря kernel space потерь производительности из-за fuse не будет.

[rm_]

Если мне не изменяет память, unionfs можно настроить точно так же. И благодаря kernel space потерь производительности из-за fuse не будет.

unionfs, если не ошибаюсь, умеет только одну writable branch, и неограниченное кол-во read-only. И никаких умностей по отслеживанию свободного места, и уж точно - по перемещению наполовину записанных файлов "налету". А благодаря kernel space, оно очень любило устраивать мне kernel oops при каких-то абсолютно тривиальнейших и безобидных, казалось бы, экспериментах (но несомненно, это руки).
Потеря производительности с mhddfs возникает в одном случае - как раз в том, когда нужно в процессе записи срочно переразместить файл. Тогда да, будет пауза в записи, пока это выполняется. Но случай этот нечастый. В повседневной же работе никаких замедлений не замечено (у меня через неё подключено около терабайта суммарно на четырёх дисках), при операциях с диском mhddfs грузит ЦПУ не более чем на 2-3%.

[AEK]

Потеря производительности с mhddfs возникает в одном случае - как раз в том, когда нужно в процессе записи срочно переразместить файл

Да ну? Можно подумать, fuse никак не влияет на производительность.

[serzh-z]

Можно подумать, fuse никак не влияет на производительность.

Думается, что возможности предоставляемые подобным драйвером, вполне окупают затраты по производительности...

[AEK]

Можно подумать, fuse никак не влияет на производительность.

Думается, что возможности предоставляемые подобным драйвером, вполне окупают затраты по производительности...

Спорно (мягко говоря). Почему бы не сделать тогда RAID/LVM, который будет работать быстрее? Хотя, "если звёзды зажигают...".

[t.t]

Спорно (мягко говоря). Почему бы не сделать тогда RAID/LVM, который будет работать быстрее? Хотя, "если звёзды зажигают...".

Ради динамичности, думается.

[rm_]

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

Сейчас специально измерил разницу в скорости диска напрямую, и скорости его же, через mhddfs.
Во втором случае оказалось медленнее на 2.6%. Так что Вы правы, некоторое влияние FUSE всё-таки имеется.

Почему бы не сделать тогда RAID/LVM

Это уже надо в FAQ куда-нибудь заносить
Главный хинт - удобство и гибкость при изменении конфигурации, как запланированном (добавление или удаление дисков), так и внезапном (отказ одного из дисков). Если Вам не кажется это значительным преимуществом, тогда да, видимо эти "звёзды" светят для других. )
Ну и по сравнению с аналогичными по полезному объёму вариантами RAID - гораздо большая надёжность. Ведь при отказе одного диска в RAID0 или в JBOD (не важно, организованы они средствами контроллера или LVM), на оставшихся получаем непригодный к использованию мусор из кусочков файлов и структур ФС. Другими словами, теряется всё содержимое массива. А при отказе одного диска в mhddfs, имеем целыми и невредимыми все те файлы, которые хранились (целиком, ведь сами файлы mhddfs на куски не дробятся) на оставшихся живыми дисках.

[AEK]

Сейчас специально измерил разницу в скорости диска напрямую, и скорости его же, через mhddfs.
Во втором случае оказалось медленнее на 2.6%.

Как меряли-то?

[rm_]

Как меряли-то?

С помощью dd (с ключом conv=fsync).

[kma21]

А если у меня есть 2-а HDD по 10 ГБ, но свободно на каждом по 2 ГБ. Надо записать файл в 3 ГБ. Насколько я понял информацию с сайта ТС, программа сама выбирает диск, на котором свободного места больше. Но если ни на одном диске не хватает места, а в виртуальной ФС хватает места, то будет ли записан файл, и если да, то как?

[/dev/random]

А если у меня есть 2-а HDD по 10 ГБ, но свободно на каждом по 2 ГБ. Надо записать файл в 3 ГБ. Насколько я понял информацию с сайта ТС, программа сама выбирает диск, на котором свободного места больше. Но если ни на одном диске не хватает места, а в виртуальной ФС хватает места, то будет ли записан файл, и если да, то как?

Если я пробовал именно эту, а не какой-то аналог, то не влезет.

[rm_]

А если у меня есть 2-а HDD по 10 ГБ, но свободно на каждом по 2 ГБ. Надо записать файл в 3 ГБ. Насколько я понял информацию с сайта ТС, программа сама выбирает диск, на котором свободного места больше. Но если ни на одном диске не хватает места, а в виртуальной ФС хватает места, то будет ли записан файл, и если да, то как?

Начнёт писать на тот, где места больше, а когда место кончится - напишет "звиняйте не влезло".
Решение:
- выставляйте mlimit значительно выше среднего размера используемых файлов;
- не эксплуатируйте диски на пределе ёмкости (это плохая идея и по причине быстрее растущей в процессе этого фрагментации).

[kma21]

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

[sash-kan]

kma21
то, что вам требуется, видимо, lvm. или что-то подобное.

[frp]

Недавно созданный нашим соотечественником Дмитрием Обуховым модуль файловой системы FUSE под названием mhddfs позволяет объединить несколько обычных файловых систем в одну большую «виртуальную», которая будет содержать в себе не только все файлы объединённых ФС, но и всё их свободное место. Кроме того, в отличии от других подобных модулей, этот не ограничивает возможность записи на виртуальную объединённую ФС, а автоматически распределяет новые файлы по тем физическим дискам, где ещё есть свободное место.

Так есть ведь aufs, был еще unionfs.

[rm_]

Так есть ведь aufs, был еще unionfs.

И что дальше?

[amikhail]

Отличная штука. Ровно то, что искал. Именно таким образом устроено хранение данных в Windows Home Server. Там винты не имеют mounting point, а некий драйвер конвертит это в представление, аналогичное MHDFS. Мне в MHDFS не хватает ровно одной вещи, которая есть в WHS - там можно сделать мирроринг выбранной папки. Т.е вот у нас фильмы, так и фиг с ними, с фильмами. Пропадут, да и плевать. А вот тут у нас /home/very_important_data. И WHS автоматически копирует данные из этой папки на два РАЗНЫХ диска.

В следующей версии WHS-а он собираются отказаться от такого подхода. Они с ума сошли. По мне так это мегафича.

А потери в 2 процента в домашней файлопомойке - фигня. Не о чем говорить.

[Tmp001]

Такой вопрос:

Есть два совершенно пустых диска, 250Гб и 500Гб. Объединяем их и создаем кучу вложенных пустых каталогов. Затем в каком-нибудь последнем вложенном каталоге создаем файл на 400Гб, а потом еще один (в другом каталоге) - на 200Гб. После этого вынимаем эти диски и подключаем к другому компьютеру.
Вопрос - что будет с каталогами и файлами на первом и втором дисках?

[rm_]

Есть два совершенно пустых диска, 250Гб и 500Гб. Объединяем их и создаем кучу вложенных пустых каталогов. Затем в каком-нибудь последнем вложенном каталоге создаем файл на 400Гб, а потом еще один (в другом каталоге) - на 200Гб. После этого вынимаем эти диски и подключаем к другому компьютеру.
Вопрос - что будет с каталогами и файлами на первом и втором дисках?

Большие файлы - будут каждый на своём из дисков (200 на 250 ГБ, 400 на 500 ГБ), потому что иначе бы они не влезли.
Если там диски объединить в mhddfs, даже получите картину, идентичную наблюдаемой на первом компьютере.
Я не понимаю, к чему вопрос - ещё в статье из первого поста было ясно написано, что файлы не режутся, и по дискам раскладываются только целиком.

Неочевидный момент, который здесь есть - это то, что файл на 400 ГБ может не получиться записать вообще никуда, если:
- диск на 500 ГБ упомянут в точке монтирования первым
- первым начали писать файл на 200 ГБ
При таком сценарии 200-гиговый файл запишется на диск 500 ГБ, оставив на том 300 ГБ места.
В результате места, чтобы целиком разместить 400-гигабайтный файл, не останется ни на одном из дисков (свободно будет 250+300), и пишущая его программа выдаст ошибку о нехватке свободного места, записав 300 ГБ. Это можно решить, вручную перераспределив файлы между дисками.

[t.t]

Неочевидный момент, который здесь есть - это то, что файл на 400 ГБ может не получиться записать вообще никуда, если:
- диск на 500 ГБ упомянут в точке монтирования первым
- первым начали писать файл на 200 ГБ
При таком сценарии 200-гиговый файл запишется на диск 500 ГБ, оставив на том 300 ГБ места.
В результате места, чтобы целиком разместить 400-гигабайтный файл, не останется ни на одном из дисков (свободно будет 250+300), и пишущая его программа выдаст ошибку о нехватке свободного места, записав 300 ГБ. Это можно решить, вручную перераспределив файлы между дисками.

А можно и предвосхитить проблему, перечисляя диски в порядке возрастания?

[t.t]

А можно и предвосхитить проблему, перечисляя диски в порядке возрастания?

Впрочем, эта же проблема может снова возникнуть, если на диске, упомянутом позже, места останется меньше, чем на предыдущих…

[rm_]

t.t

А можно и предвосхитить проблему, перечисляя диски в порядке возрастания?

В чём именно проблема?

Есть параметр mlimit, который устанавливает минимальный объём свободного места, при котором уже "хватит" пытаться писать на этот диск новые файлы. Сделан он отчасти и для повышения шансов, что под "последний" из записываемых на этот диск файлов, места хватит. По умолчанию он равен 4 гигабайтам. При наличии у вас большого кол-ва более крупных файлов, можно выставить его в один-полтора-два размера такого файла. Самый большой файл у меня - гигабайт кажется восемь, и при терабайтных объёмах дисков, описанной выше ситуации не возникает в принципе.

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

Но я подозреваю, вопрос был не в этом, судя по "что будет если подключить к другому компьютеру" автор ошибочно полагал, что его файлы неким образом побъются по дискам и при подключении к компьютеру без mhddfs, там вдруг окажется каша.

[t.t]

t.t

А можно и предвосхитить проблему, перечисляя диски в порядке возрастания?

В чём именно проблема?

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

Но я подозреваю, вопрос был не в этом, судя по "что будет если подключить к другому компьютеру" автор ошибочно полагал, что его файлы неким образом побъются по дискам и при подключении к компьютеру без mhddfs, там вдруг окажется каша.

Да, похоже на то. Я скорее для себя пытался понять, насколько критична та гипотетическая ситуация, на которую Вы обратили моё внимание.

[Tmp001]

Но я подозреваю, вопрос был не в этом, судя по "что будет если подключить к другому компьютеру" автор ошибочно полагал, что его файлы неким образом побъются по дискам и при подключении к компьютеру без mhddfs, там вдруг окажется каша.

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

[rm_]

Tmp001
Долго объяснять, просто поставьте и поэкспериментируйте.
Вкратце: с этим всё здорово, проблем не будет.

[Tmp001]

Вкратце: с этим всё здорово, проблем не будет.

Хорошо бы. Я так понимаю, что на двух физических носителях будут одинаковые структуры каталогов, но разные файлы в них?

[rm_]

Вкратце: с этим всё здорово, проблем не будет.

Хорошо бы. Я так понимаю, что на двух физических носителях будут одинаковые структуры каталогов, но разные файлы в них?

На каждом из них будут ровно те каталоги (и вложенные в них), которые нужны, чтобы разместить оказавшиеся по таким путям (и попавшие на этот диск) файлы. Полного дубляжа всего дерева не будет, зачем. Однако при перемещении файлов туда-сюда, на некоторых дисках могут остаться пустые каталоги - специально они не чистятся. Удалятся они при удалении соответствующих им каталогов с виртуальной ФС (удаляете с неё пустой каталог - он удаляется со всех дисков, где такой был). Ну либо вручную можно удалить.
И я опять же не понимаю, чего мы теоретизируем. Поставить софтину, смонтировать два каталога, накидать туда файлов - дело пяти минут.