Просто: вы ищете mhddfs .
Она претендует на то, чтобы быть одной большой файловой системой, записывает на диски в том порядке, в котором они были упомянуты, и в конечном итоге перемещает большие файлы на другое устройство, если первое было слишком полным. На самом деле он также может использовать подпапки на дисках, обеспечивая такую же функциональность.
Отдельные диски должны быть смонтированы в первую очередь и оставаться доступными. Он вообще не изменяет файловые системы и не заботится о том, какая файловая система находится на месте (если файловая система правильно сообщает о свободном пространстве). В случае, если диск потерян, вам придется заново подключить mhddfs (на лету) и данные на этом диске исчезнут.
Использование:
mhddfs /dir1,/dir2[,/path/to/dir3] /path/to/mount [-o options]
или в /etc/fstab
mhddfs#/path/to/dir1,/path/to/dir2 /mnt/point fuse defaults 0 0
Сложный и мощный: вы хотите unionfs .
Хотя mhddfs хорош и чрезвычайно прост, у меня были проблемы с правами доступа к файлам при предоставлении доступа другим через SSH. Я не мог найти никакого решения, но нашел unionfs.
Unionfs также позволяет вам монтировать несколько папок в разных файловых системах в одну, но делает это волшебно с разрешениями. Вы можете объединить несколько папок, доступных только для чтения, и одну доступную для записи одну, поэтому она выглядит как одна. Люди, с которыми вы поделились вашей объединенной папкой, могут затем писать в папку только для чтения - как им кажется - но файлы в конечном итоге оказываются в единственной доступной для записи. Загрузочные компакт-диски Linux работают следующим образом, записываемый диск является виртуальным диском. Люди могут даже удалять файлы в папках только для чтения, которые на самом деле не удаляют файл, но создают скрытый файл белого списка в своей директории записи. Если вы поймаете все варианты, вы можете использовать свою файловую систему как SVN для бедного человека .
Если вы слишком часто используете SVN-подобные параметры, вы можете пропустить существующие данные дважды (это невероятно в вашем сценарии, но возможно), в то время как ваша доступная для записи папка заполняется крошечными, скрытыми файлами белого списка. Помимо этого, он сохраняет ваши диски в чистоте и индивидуальном использовании. Что произойдет, если файл слишком велик для диска, я пока не знаю.
Использование:
unionfs-fuse -o cow,max_files=32768 \
-o allow_other,use_ino,suid,dev,nonempty \
/path/to/dir1=rw:/path/to/dir2=ro:/dir3
/u/union/etc
где =rwделает папку доступной для чтения и записи и =roделает ее доступной только для чтения, даже если в разрешениях указано иное. В etc/fstabэтом есть
unionfs-fuse#/path/to/dir1=rw:/path/to/dir2=ro:dir3 /path/to/mount fuse cow,allow_other 0 0
Если вы просто соединяете несколько устройств вместе, избыточности не будет, поэтому вы можете потерять данные. Но если вы используете медиа / файловый сервер для бизнеса, вы не должны ничего терять, потому что у вас есть все резервные копии на резервный сервер / стример.
Почему вы избегаете RAID? Смысл RAID - это доступность; если вы не хотите терять время из-за сбоя диска, вы можете использовать конфигурацию RAID 1, которая также может ускорить чтение. Они не слишком дороги, окупаются в первый раз, когда у вас возникает сбой диска, и если вы ДЕЙСТВИТЕЛЬНО избегаете платить за карту, вы можете настроить Linux для использования программного RAID, хотя в настройке это требует немного больше внимания и устранение неполадок, чтобы убедиться, что вы заменили правильный диск.
В противном случае вам придется прыгать через несколько обручей, чтобы попытаться восстановить те данные, которые вы можете с оставшихся дисков. Это было бы возможно, но вы вроде бы просите намного больше проблем, чем должны были. Получите хорошую резервную копию на месте и пересмотрите RAID.
источник
Если вы используете одну файловую систему, охватывающую все тома LVM, вся файловая система будет повреждена, поскольку FS не будет знать о базовых физических томах и не будет создавать структуры, соответствующие этому. Может быть возможно спасти некоторые части на рабочих дисках, но нет никакой гарантии для этого.
И просто восстановление файлов с поврежденного диска не будет работать по той же причине.
источник
Я думаю, что гораздо проще было бы настроить mdadm для вашего медиа-раздела. Если у вас нет аппаратного обеспечения для работы с «настоящим RAID», маршрут mdadm будет значительно проще и, похоже, будет соответствовать вашим требованиям к избыточности и простой замене диска.
Для получения дополнительной информации: http://en.wikipedia.org/wiki/Mdadm
Если вы используете mdadm и RAID 5, вы сможете потерять один диск и получить работоспособный массив, что приведет к снижению производительности.
источник
Я думаю, что важная вещь для понимания, о которой не упоминалось, это то, что файл в файловой системе не обязательно находится в одном месте на диске. Он разбит на блоки, которые могут находиться где угодно внутри файловых систем. Первые 4 КБ, если ваш файл может быть на диске 1, следующем диске 2 и т. Д. Вы можете представить беспорядок попыток восстановить что-либо, если вы потеряли часть файловой системы.
источник
Btrfs - хороший выбор здесь; вы можете иметь метаданные, устойчивые к потере одного диска (профиль чанка "raid1"); данные на других дисках по-прежнему будут доступны (так что мы ясно понимаем, что это означает, что файлы, заполненные дырами, везде, где есть ссылка на отсутствующий диск). Это делается путем запуска btrfs balance с фильтром :
источник