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

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

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

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

lvm raid

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

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

LVM

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

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

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

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

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

unionfs

Про 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

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

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

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

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

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

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

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

lvm raid

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

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

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

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

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

LVM/RAID/aufs3/mhddfs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У докера куча бэкендов: 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)

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

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

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

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

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

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

а кто сказал, что я вообще хочу рейд?

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