LINUX.ORG.RU

Единая файловая система

 


1

3

Есть 4 винта. на каждом есть папке «аниме». можно ли с помощью симлинков объединить эти папки в одну, и если на одном винте место заканчивалось, то каталог с новым аниме записывался на другой винт?

Что-нибудь наподобие, вероятно, можно сделать с помощью lvm, объединив 4 раздела на разных винтах в 1.

sudopacman ★★★★★ ()

С помощью симлинков - нет, можно с помощью mhddfs и подобных.

deadNightTiger ★★★★★ ()

Папку с симлинками - не вопрос.

Для остального

lvm raid

«если на одном винте место заканчивалось, то каталог с новым аниме записывался на другой винт»

А. Ну ещё ручками можно на другой винт писать. В принципе, не так уж много у тебя винтов ведь, чтобы автоматизацию городить, ня?

slamd64 ★★★★★ ()

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

Вопрос в том, как ты записываешь и как часто. Можно соорудить ссылку типа «MYHENTAI» и при логине переопределять её на случайный каталог. Или в скрипт запуска клиента торрента такой выбор сделать.

anonymous ()

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

ArcFi ()

можно написать скрипт, который будет по мере необходимости перетаскивать данные на другие винты и давать симлинки на них, но лучше LVM, там все обкатано. Добавишь винтов - не проблема, просто прибавилось свободное место. Еще бы очень хорошо было если б под lvm raid1

blokant ★★ ()

делал такое когда-то на UnionFS. работало весьма хорошо, но то было давно, не знаю жив ли проект

staz ()

Про LVM выше уже писали. Вариант, если нужно простое решение с полноценным объединённым файловым пространством и без потерь производительности. Минус — при отказе одного из дисков рискуешь потерять все файлы. Если откажет один из вторичных в последовательности дисков, то потеряешь только файлы, фрагменты которых лежат на нём. Если диск, на котором лежат таблицы ФС — потеряешь всё.

Альтернативный вариант — чуть более замороченный и тормозной, но с полной независимостью ФС разделов — это aufs. Скажем, в таком виде:

mount -t aufs -o br=/data1=rw:/data2=rw -o create=mfs none /data-union

После этого, если в /data-union будешь писать файл, он будет записываться или в /data1, или в /data2, смотря где больше места. Здесь /data1 и /data2 — смонтированные разделы HDD, /data-union — точка монтирования. create-mfs — опция для создания файлов в most free space разделе. Там и другие есть: http://aufs.sourceforge.net/aufs3/man.html#Policies to Select One among Multiple Writable Branches

KRoN73 ★★★★★ ()

Главное, перед использованием того или иного решения ответьте самому себе на такие вопросы:

  1. Как именно данные будут размазаны по дисками.
  2. Какой процент информации может оказаться безвозвратно утерян при сбое файловой системы.
  3. Смогу ли я самостоятельно восстановить данные при вылете любого из дисков.
ArcFi ()
Ответ на: комментарий от KRoN73

Минус aufs - нужно патчить ядро (хотя в дебиане вроде из коробки есть). Производительность тут особо не нужна, лучше FUSE-based что-нибудь ИМХО.

deadNightTiger ★★★★★ ()
Ответ на: комментарий от deadNightTiger

Минус aufs - нужно патчить ядро

В ядре из коробки OverlayFS, но она, по-моему, пишет только в одну директорию, а не распределяет по надобности.

proud_anon ★★★★★ ()
Ответ на: комментарий от proud_anon

Да, в overlayfs только одна rw-директория (в отличие от aufs), так что не подходит.

deadNightTiger ★★★★★ ()
Ответ на: комментарий от darkenshvein

то всё (наверное)

Я вообще, я бы не стал извращаться и просто отдал бы один ЖД под эту папку вместо размазывания её по нескольким.

sudopacman ★★★★★ ()
Ответ на: комментарий от darkenshvein

Сдохнет один из дисков в рейде? Заменишь и просинкаешь

blokant ★★ ()
Ответ на: комментарий от deadNightTiger

Минус aufs - нужно патчить ядро

В Ubuntu оно из коробки, в Gentoo идёт пакетом-модулем. Остальное — проблемы индейцев :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от deadNightTiger

Минус aufs - нужно патчить ядро

Кстати. Docker сейчас есть во всех меняемых дистрах. А он же через aufs работает. Так что всё сейчас всюду должно быть с этим ок, нет?

KRoN73 ★★★★★ ()
Ответ на: комментарий от darkenshvein

а если один раздел сдохнет, то чо?

Единая файловая система (комментарий)

а если один раздел сдохнет, то чо?

Единая файловая система (комментарий)

а если один раздел сдохнет, то чо?

Единая файловая система (комментарий)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

В убунте (и вообще дебиан-бейсед) да, в генте этот ебилд все равно патчит /usr/src/linux, но там в общем-то все равно нет проблемы пропатчить ядро. А вот в rpm-based уже посложнее будет.

deadNightTiger ★★★★★ ()
Ответ на: комментарий от deadNightTiger

А вот в rpm-based уже посложнее будет.

Так вот и вопрос попутный — а как там Docker работает?

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

У докера куча бэкендов: OverlayFS, AUFS, Btrfs, Device Mapper, VFS, ZFS. Например, в федоре:

Storage Driver: devicemapper
 Pool Name: docker-253:0-659420-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 53.74 MB
 Data Space Total: 107.4 GB
 Data Space Available: 44.55 GB
 Metadata Space Used: 606.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.109 (2015-09-22)

deadNightTiger ★★★★★ ()
Последнее исправление: deadNightTiger (всего исправлений: 1 )
Ответ на: lvm raid от darkenshvein

а если один раздел сдохнет, то чо?

C lvm, кстати, ничего страшного быть не должно - потеряются только те данные, которые хранились на этом разделе.

А вообще, дружище, ты хочешь и рыбку съесть и на кол не сесть. Так не бывает. Либо то, либо другое...

RAID-5, RAID-6, spare-диски - вот общепризнанные отказоустойчивые решение различной стоимости. :)

slamd64 ★★★★★ ()
Ответ на: комментарий от slamd64

потеряются только те данные, которые хранились на этом разделе

Но если на пропавшем разделе хранятся MFT (или что там вместо него в ext4/xfs), то накроется весь раздел, пусть его данные и останутся целями на других разделах. Тут нужна ФС с дублированием/резервированием MFT по всему разделу :)

KRoN73 ★★★★★ ()

использовал какое-то время mhddfs для торентопомойки, впринципе нормально себя показало, единственное надо понимать, что если у тебя 2 винта по 10Гб а ты пытаешься запилить 15Гб одним файлом, то это сразу фэйл.

jo_b1ack ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.