The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Логическое объединение нескольких файловых систем при помощи mergerfs
FUSE-модуль Mergerfs позволяет логически объединить несколько файловых
систем в одну, например, для объединения разнесённых на разные диски коллекции
видео или музыки в одну иерархию.


В отличие от aufs и overlayfs в mergerfs не создаётся отдельного слоя для
записи и данная ФС не может применяться поверх разделов, доступных в режиме
только для чтения. Но mergerfs даёт возможность прямой записи в
примонтированный раздел в соответствии с заданной политикой, например, запись
может осуществляться в ФС, в которой больше свободного места. Также можно
включить в один сводный раздел ФС, доступную на запись, и ФС только для чтения.
В такой конфигурации операции записи будут производиться в разделе, который
допускает запись.

Среди особенностей mergerfs:  настройка поведения размещения новых файлов,
работа в пространстве пользователей через FUSE,  поддержка расширенных
атрибутов (xattrs) и смены атрибутов chattr, работа с различными ФС, поддержка
POSIX ACL.

Проектом собираются пакеты для Fedora, Debian и Ubuntu.

Устанавливаем mergerfs в Fedora 31:

   wget https://github.com/trapexit/mergerfs/releases/download/2.29.0/mergerfs-2.29.0-1.fc31.x86_64.rpm

   sudo dnf install mergerfs-2.29.0-1.fc31.x86_64.rpm


Допустим, в системе есть два раздела /disk1 и /disk2, на которых имеются  каталоги с видео:

   $ df -hT | grep disk
   /dev/sdb1      ext4      23M  386K 21M 2% /disk1
   /dev/sdc1      ext4      44M  1.1M 40M 3% /disk2

   $ ls -l /disk1/Videos/
   total 1
   -rw-r--r--. 1 curt curt 0 Mar 8 17:17 file1.mkv

   $ ls -l /disk2/Videos/
   total 2
   -rw-r--r--. 1 curt curt 0 Mar 8 17:17 file2.mkv
   -rw-rw-r--. 1 curt curt 0 Mar 8 17:21 file3.mkv


Создадим логический раздел /media, который будет включать в себя как  /disk1, так и /disk2:

   $ sudo mergerfs -o defaults,allow_other,use_ino,category.create=mfs,moveonenospc=true,minfreespace=1M /disk1:/disk2 /media

где

    defaults - применение настроек по умолчанию
    allow_other - возможность доступа непривилегированных пользователей, а не только root
    use_ino - манипуляция исходными inode вместо libfuse для того, чтобы связанные файлы имели одинаковые inode.
    category.create=mfs - распределение новых файлов в зависимости от доступного свободного пространства.
    moveonenospc=true - в случае сбоя записи искать раздел с большим свободным местом.
    minfreespace=1M - минимальное свободное место для записи.
    disk1 - первый подключаемый раздел
    disk2 - второй подключаемый раздел
    /media - точка монтирования


После монтирования получим:

   $ df -hT | grep media 
   1:2        fuse.mergerfs  66M      1.4M 60M 3% /media 


Если скопировать в /media/Videos/ большой новый файл, для которого не хватает
места в /disk1, но который вмещается в /disk2, то это файл будет размещён в
разделе /disk2. Разделы /disk1 и /disk2 после монтирования остаются доступны
для любых операций, /media объединяет их лишь логически.

   $ ls -lh file4.mkv
   -rw-rw-r--. 1 curt curt 30M Apr 20 08:45 file4.mkv

   $ cp file4.mkv /media/Videos/


   $ ls -l /disk1/Videos/ 
   total 1
   -rw-r--r--. 1 curt curt 0 Mar 8 17:17 file1.mkv

   $ ls -l /disk2/Videos/
   total 30003
   -rw-r--r--. 1 curt curt 0 Mar 8 17:17 file2.mkv
   -rw-rw-r--. 1 curt curt 0 Mar 8 17:21 file3.mkv
   -rw-rw-r--. 1 curt curt 30720000 Apr 20 08:47 file4.mkv

   $ ls -l /media/Videos/
   total 30004
   -rw-r--r--. 1 curt curt 0 Mar 8 17:17 file1.mkv
   -rw-rw-r--. 1 curt curt 0 Mar 8 17:21 file2.mkv
   -rw-r--r--. 1 curt curt 0 Mar 8 17:17 file3.mkv
   -rw-rw-r--. 1 curt curt 30720000 Apr 20 08:47 file4.mkv
 
02.05.2020 , Источник: https://fedoramagazine.org/using-me...
Ключи: mergerfs, unionfs, linux, mount / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Диски и файлы / Файловые системы

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Анонимный аноним (?), 17:43, 02/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что будет, если туда писать лог?
    Место на одном диске закончилось, запись прервётся?
     
     
  • 2.5, sharddin (?), 16:13, 04/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Создал скрипт mergerfs -o defaults,allow_other,use_ino,category create m... большой текст свёрнут, показать
     
     
  • 3.9, _hide_ (ok), 11:36, 13/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы советовал написать нормальный init скрипт и вызывать его из юнита. Чтобы быть уверенным в работоспособности решения.
     
     
  • 4.14, пох. (?), 08:56, 20/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Я бы советовал написать нормальный init скрипт и вызывать его из юнита.

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

    Впрочем, у него из юнита вообще не вызывается ничего - похоже, ошибка копипасты, или автор и впрямь не в курсе что такое юнит и как работает, нашел на серферфолте? (Где execstart-то?! stop вижу, только он, мягко говоря, странный - похоже, бинарник без параметров зачем-то вызывает.)

    я бы посоветовал - показать скрипт, логи (journalctl и syslog).
    А автор показал непонятно-что. Если у него правда # это начало скрипта, а не затесавшийся рутовый промпт - его ждет еще много чудных открытий, конечно.

    Может, прежде чем юниты писать и статьи на опеннет - книжек каких про юниксы почитать, а? Узнать что этот # означает в разных местах, хотя бы.

    А  mergerfs пока поставить из пакета, я уверен что там есть юнит, и работающий, в отличие от васян-поделки.

     
     
  • 5.23, sharddin (?), 13:41, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Скрипт такой (да, убрал в начале #, заменив на $ и добавил  sudo  перед командой:
    ==================================
    $!/bin/bash

    sudo mergerfs -o defaults,allow_other,use_ino,category.create=mfs,moveonenospc=true>
    ==================================
    В юнитах, конечно, не очень-то и разбираюсь - нашёл две страницы для создания собственного юнита и сварганил по их советам один общий...

    ... Отключил, вообщем, всё из этого...

     

  • 1.2, КО (?), 07:50, 03/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "объединение нескольких файловых систем"
    Видимость объединения скорее уж, толку от которого мало.
     
     
  • 2.3, Crazy Alex (ok), 12:37, 03/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну... с другой стороны, в отличие от lvm/raid0 если так сцепить несколько дисков - то если один крякнется на других данные уцелеют самым что ни на есть тупым и понятным манером. Что-то вроде бэкапного ящика, куда диски докидываются по необходимостиЮ да ещё и убрать старьё можно - вполне. FUSE, конечно, ну и чёрт бы с ним
     
     
  • 3.6, aa (?), 14:29, 06/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    когда новый файл записывается на случайный диск - это нифига не "понятным манером"
     
     
  • 4.8, Crazy Alex (ok), 23:19, 07/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, оно конфигурируемо. Во-вторых - это всё же не страйпы собирать - слил вместе - и готово, что выжило - в том же состоянии, в каком и было до смерти одного из дисков. В-третьих - лично у меня было довольно много случаев, когда файлы независимы. Бэкапы в архивах, образы дисков и так далее.
     

  • 1.4, Жёлтый Джек (?), 14:24, 04/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В отличие от aufs и overlayfs(,) в mergerfs не создаётся отдельн[ого](ый) сло[я](й) для

    записи(,) и данная ФС не может применяться поверх разделов, доступных [в режиме]
    только для чтения.

    () - добавить.

    [] - удолить.

     
     
  • 2.24, pavlinux (ok), 19:13, 09/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > [] - уд{о}лить.

    {} - зоминить

     

  • 1.7, Аноним (7), 16:35, 06/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда-то пробовал подобное в качестве замены всевозможным striped volume на уровне объектов ФС, оказалось, что работает чертовски медленно при существенной нагрузке (файл-сервер). Уж лучше костылить решения с симлинками.
     
     
  • 2.13, пох. (?), 08:47, 20/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пейсателям гуаностатей на заметку: а вот это и есть та информация, которая (в отличие от бездарной статейки) и имела хоть какой-то смысл. Человек не только с пятого на десятое освоил командную строку, но и может рассказать о проблеме, хотя бы два слова - "не ходите туда".

    В общем-то, ничего удивительного не вижу - твой файлсервер поди сасамба? Итого четыре лишних контекст-свитча на каждое обращение. (Модуль для прямого доступа в обход vfs для сасамбы никто не написал? Или аналогичного для ganesha? Это типовое решение для подобных случаев, если что.)

    Обычно,afaik, его в другую сторону применяют - десяток недосерверов с сасамбами объединить в один сплошной пул. Проигрываешь на контекст-свитчах, выигрываешь (если правильно объединил) на том что доступ может идти параллельно к нескольким серверам и контекст-свитчи жуются в том числе их процессорами.

     
     
  • 3.15, Crazy Alex (ok), 12:55, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оно, блин, FUSE, то, что оно не вытянет нагрузку - очевидно с самого начала. FUSE  в продакшне и с хоть какими-то заметными нагрузками - это особая "храбрость".

    А вот обойтись на домашней медиа-помойке без LVM и прочих RAID когда суёшь туда очередной винт - прокатит отлично. И когда один из прежних навернётся - тупо делается recheck торренту и он, по возможности, перекачивает битое.

     
     
  • 4.18, пох. (?), 20:24, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно, блин, FUSE, то, что оно не вытянет нагрузку - очевидно с

    странно, что оно совершенно неочевидно автору ntfs3g, в какой-то момент всерьез померявшегося х...ями аж с тогдашней ext4 (да, в панике улучшили производительность...а он пообещал когда-нибудь в будущем - хотя бы дебаг выключить ;-) не вполне очевидно было авторам lustre (да, переписали, но далеко не сразу), и совсем неочевидно авторам gluster и moose.

    > самого начала. FUSE  в продакшне и с хоть какими-то заметными
    > нагрузками - это особая "храбрость".

    расскажи это redhat с ее промышленными storage clusters.

    > А вот обойтись на домашней медиа-помойке без LVM и прочих RAID когда
    > суёшь туда очередной винт - прокатит отлично. И когда один из

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

    Оно вообще не для замены raid было придумано. Оно для тех у кого этих винтов - опой жуй.

     
     
  • 5.19, Crazy Alex (ok), 14:42, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, как насчёт ntfs (никогда не интересовался), а с остальной троицей всё очевидно - сетевые ФС, где локальные задержки ничего не значат, плюс это крупные проекты на слуху, раз не сдохли - можно предположить, что более-менее работают и что в них вбито приличное количество ресурсов.

    А в среднем по больнице FUSE - это мелкий тормозной самопал, обменявший качество кода и эффективность на гибкость и простоту написания, если уж даже на сторонний модуль ядра не сподобились, не говоря о добавлении в мейнлайн. Ну или адская экзотика какая-нибудь, но здесь явно не тот случай.

    Так вот, для FUSE  в общем случае надо отдельно указывать не то что оно тормозит (это естественное ожидание), а то, что оно каким-то чудом НЕ тормозит.

    Насчёт "потерять все данные" - так это во все времена лечилось только бэкапом. И именно с mergefs теряются не все, как в LVM со сдохшим винтом или RAID0. Другое дело, что если это не домашняя хранилка - RAID почти наверняка всё равно понадобится, а добавлять винты тогда надо на нём или на слое ниже.

    А вот дома - ну да, помрёт часть какой-нибудь торрентопомойки со сдохшим винтом. Ровно так же, как и померла бы без mergefs. Дополнительных проблем не создаёт, пнуть торренту rehash и пусть докачивает, что может - без бэкапов же хоть как-то компетентный человек важные данные не держит, правда? А тот, кто подобное настраивает, хоть некоторую компетенцию явно имеет.

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

     
     
  • 6.21, пох. (?), 17:30, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    мущина, проснитесь - во времена 100G адаптеров сеть постоянно оказывается быстре... большой текст свёрнут, показать
     

  • 1.10, trunk (?), 04:54, 18/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    mhddfs
     
     
  • 2.11, Нолекс (?), 19:16, 19/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По всей видимости он больше не разрабатывается, хотя пакеты под Debian, до сих пор собирают... o_O
     

  • 1.12, пох. (?), 08:40, 20/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Еще одна васянская статья ниочем. Чувак вчера открыл для себя mergerfs и бежит поделиться тем, что и так знает любой.

    Или узнает, если бегло прочитает README.

    Вы знаете, я вчера нашел такую программу, mc называется! Она умеет файлики копировать и удалять, представляете! И окошки у нее синенькие!
    Вот примерно и все что я про нее могу вам рассказать. Зачем это на опеннете?! Чтобы окончательно вся аудитория свелась к школию-недоучкам?

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

    В 10-м обычной - засмеют, пожалуй.

     
     
  • 2.16, Crazy Alex (ok), 12:57, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала надо знать, что такая штуковина вообще существует.

    Отслеживать все поделки на FUSE - жизни не хватит, а так - сравнительно интересное само приползло.

     
     
  • 3.17, пох. (?), 20:19, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Для начала надо знать, что такая штуковина вообще существует.

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

    Кроме того что - существуют.

     
     
  • 4.20, Crazy Alex (ok), 14:46, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сюрприз - сейчас пишется такая куча разных приблуд, чтобы самому пересмотреть всё - жизни не хватит. И то, что кто-то нарыл интересное, потыкал палочкой, оно у него собралось и в принципе работает - уже ценно. А нюансы можно отдельно покопать, и для хоть какого-то "рабочего" использования это придётся делать в любом случае. Здесь основная ценность - именно в том, что о самм существовании интересной штуковины узнаёшь.
     
  • 4.22, Нолекс (?), 16:17, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как по мне - статей бы побольше, всяких разных. А флуда бы меньше...
     

  • 1.25, Аноним (25), 16:27, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Но mergerfs даёт возможность прямой записи
    > в примонтированный раздел в соответствии с заданной политикой

    Какой-то троллейбус из буханки ака btrfs из спичек и желудей.

     
  • 1.26, getfr (?), 13:11, 18/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автор объединительной штуки не осилил symlink?
    А как иначе объяснить желание городить огород посередине огорода?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру