Альтернативы LVM?

mdadm не осилил чтоль?

software raid?

unionfs?

>Надо чтобы при выходе из строя одного из винчестеров информация с остальных легко восстанавливалась.

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

DFS ?

> имеется несколько винчестеров, суммарным объёмом N, необходимо из них сделать файлохранилище объёмом N .... Надо чтобы при выходе из строя одного из винчестеров информация с остальных легко восстанавливалась.

Он хочет чтобы избыточность хранилась в астрале у коминтерна, ибо на винчестерах для избыточности место выделать не хочет.

ZOMG! А если ZFS?

И вообще, трахаться неделю "с драйвером" вместо покупки N+1-го винта для создания 5-го рейда - это нужно очень, ОЧЕНЬ не ценить своё время.

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

именно так! есть ли готовые решения?

> И вообще, трахаться неделю "с драйвером" вместо покупки N+1-го винта для создания 5-го рейда - это нужно очень, ОЧЕНЬ не ценить своё время.

мне не подходит драйвер

мне не нужна избыточность рейда с одной стороны

и мне нужно простое восстановление непотерянных данных с другой

Это называется "немотивированная иррациональная жадность" и лечится симлинками, инструкцией или организацией БД.

Также можно покурить маны к XFS и ZFS. В гуголь не посылаю, там весь ЛОР зобанили.

>Он хочет чтобы избыточность хранилась в астрале у коминтерна, ибо на винчестерах для избыточности место выделать не хочет.

смотри

например имеем такую задачу:

нужно выделить место под несколько зеркал больших серверов

потеря информации нам не так уж страшна в таком случае (потерянное рсинком перекачивается) однако не хочется перекачивать все

ну и подобных задач можно много придумать ))

(домашний сервер на котором храним фильмы/музыку которые сбакаплены на диски итп)

>Это называется "немотивированная иррациональная жадность" и лечится симлинками

расскажи подробнее как жадность полечить симлинками? чтобы пользователю не надо было помнить постоянно "вот на этом винте еще есть место а вот на том уже нет"

> расскажи подробнее как жадность полечить симлинками? чтобы пользователю не надо было помнить постоянно "вот на этом винте еще есть место а вот на том уже нет"

Ещё раз повторяю, если всё делается для пользователя - то твоя самая святая обязанность есть "снятие с себя геморроя по устранению проблем, которые пользователь сам себе создаст". Для этого придумали рейды.

Если нужно убить помянутое количество времени - займись тестированием софтрейдов или железных рейдов, напиши кучу бумаг и построй красивые графики. Освой опенсолярку и фрибсд, поковыряй ZFS, пройди тренинг у Санок, отчитайся и увеличь зряплатный доход.

Если это делается не по работе, а "для дома, для семьи" - то я тебя вообще не пониманию, рекомендуя принять валерьяночки и таки поспать.

я понял

предложить тебе нечего а повыпендриваться хочется

перечитай свои рекомендации в области валерьяночки и поспать и начинай!

Разумеется. Даже в энтерпрайзах такой хернёй не заморачиваются: http://xgu.ru/wiki/DRBD_LVM_GNBD_Xen, но ты осилишь сей тернистый путь, я верю! ;)

>http://xgu.ru/wiki/DRBD_LVM_GNBD_Xen

не подходит по условиям исходной задачи

>unionfs?

я посмотрел описание это почти то что я сейчас делаю

только я не понял оно умеет само выбирать каталог/винчестер с бОльшим объемом свободного места и перемещать данные с винчестера на винчестер?

то есть мне надо чтобы если мы записываем на hdd1 и при записи у нас заканчивается место то запись бы была продолжена на hdd2 итп

то есть преодолеть ситуацию с тем что у нас на 10 винчестерах места 100 гиг но мы не можем эти 100 гиг разместить?

к сожалению попробовать unionfs я смогу только завтра, поэтому если ответите сегодня буду благодарен ))

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

Хотя, конечно, драйвер (ядерный?) ФС - это гораздо, гораздо труевее :D

ZFS ?

тут кто-то (айфильтро и крон точно были замечены активными в треде) собирался писать драйвер для фс с данными размещенными на разных оптических носителях (который будет просить вставить соотв. диск при обращении), имхо у вас сходные условия, только файлы утройств разные, объедините усилия:)

>Хотя, конечно, драйвер (ядерный?) ФС - это гораздо, гораздо труевее :D

я пока с FUSE делаю ))

>тут кто-то (айфильтро и крон точно были замечены активными в треде) собирался писать драйвер для фс с данными размещенными на разных оптических носителях (который будет просить вставить соотв. диск при обращении), имхо у вас сходные условия, только файлы утройств разные, объедините усилия:)

не знаю, возможно потом можно будет добавить опцию

я правда довольно давно не пользовался разного рода оптическими девайсами кроме как для бакапа ))

нет с ЗФС пока ее драйвера не появятся в дебиан связываться не хочу ))

да, я тоже но они говорили что это оптимальный выбор коллекционера по цене/надежности, впрочем я не об этом а об том что вместе веселей, даже если частные случаи разные:)

вместе и правда веселее ))

я выложу версию 0.0.1 на сл неделе может и правда кто подтянется ))

есть Debian/kFreeBSD )

$ apt-cache search ZFS bzflag-server - bzfs - BZFlag game server

и все

я понимаю что на каких-то левых репозитариях оно может быть

но ставить неохота

Это называется JBOD. Один слетает - умирает только информация на нем. Прироста скорости или надежности нет. Задача кажется высосанной из пальца.

http://www.linux.org.ru/view-message.jsp?msgid=2575218

примерно делаю это же, тока более фичастое. стучись в жаббер.

>примерно делаю это же, тока более фичастое. стучись в жаббер.

постучусь завтра (сегодня я с чужого компа - не дома)

в первой версии у меня получается примерно такая система (пока сделано только r/o):

монтируем n каталогов в один

отображение в точку монтирования идет из всех каталогов сразу (содержимое каталогов объединяется, файлы с одинаковыми именами отображаются в виде одного файла (при этом доступ идет к нему же))

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

при переполнении места на винчестере куда пишется файл его начальное содержимое перемещается на другой где есть свободное место

это то что на первой версии будет (если будет время то уже завтра)

а в перспективе хочу сделать сплит и при переполнении одного диска на втором чтобы писался хвост файла. и соответственно объединение файлов в порядке монтирования (правда это я пока не продумывал до конца)

еще один которому свербит? нет рейды не подходят по условию задачи

JBOD - это не рейд. То, что остается на неслетевших хардах несложно восстанавливается. Зачем это вообще надо?

> рейды не подходят по условию задачи

Ну так подумай, не стоит ли изменить эти условия. Готовое, проверенное и отлаженное решение против самописаной (и даже еще не написанной) ФС - кто кого? Стоит ли время разработки лишнего диска-двух?

http://en.wikipedia.org/wiki/JBOD#Concatenation_.28JBOD_or_SPAN.29

10 отличий?

Может он хочет, что бы каждый диск сохранял некоторую "самостоятельность" от других?

Ну что бы каждый диск при случае можно было бы при необходимости монтировать совершенно отдельно от других.

Только я пока тоже не понял зачем это надо.

Нет, он так не хочет, если подразумевает разбиение файлов, которые не лезут в раздел.

>Ну что бы каждый диск при случае можно было бы при необходимости монтировать совершенно отдельно от других.

именно так и будет

>Нет, он так не хочет, если подразумевает разбиение файлов, которые не лезут в раздел.

да в перспективе думаю сделать сплит файлов что не лезут

восстановление информации можно будет проводить и без драйвера простыми find/cat/cp

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

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

непотерянные данные легко восстанавливаются с лвм, (rtfm), то есть лвм удовлетворяет требованиям вроде как.

>10 отличий?

РАИД он на низком уровне проводит объединение дисковых систем

на высоком уровне поверх всех этих раидов работает какая-то ФС иногда допускающая потерю части блоков иногда нет.

при утрате игрока (в случае если инфа не дублируется) восстановление данных производится средствами восстановления файлосистемы

что может быть как минимум нетривиально, как максимум невозможно (в зависимости от того что и как сломалось)

>непотерянные данные легко восстанавливаются с лвм, (rtfm)

Каким образом?

над ЛВМ всегда работает драйвер ФС (например ехт3) то есть при потере логик-блока лвм мы должны

1. подставить взамен утерянного (пусть фиктивный) новый блок

2. восстанавливать файлосистему с помощью средств вроде fsck которые работают с низким уровнем, а следовательно результат их работы не всегда удобоварим

если в этой области есть что-то более юзабельное, удобное поделитесь ссылками я для этого этот тред и создал)))

не, я имел ввиду fsck.. понял задачу после прочтения треда

> при создании нового файла выбирается одна из точек монтирования на которой больше всего доступного места

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

>может лучше выбирать точку с минимально-достаточным количеством ?

а откуда драйвер может узнать сколько надо на тот или иной файл?

я думаю вообще установить некий порог (скажем 4-10 гигов - будет меняться в опциях) и если на первом hdd будет свободного места превышать этот порог то создавать файлы на нем далее на втором третьем итп

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

Блин, нужна такая ФС для ftp. Думал сам писать, да времени нет. Могу помочь, если что чем смогу.

мой емыл linuxover@gmail.com в тестах помощь точно потребуется))

на днях добью первый вариант драйвера rw - выложу

> а вот в случае если все диски за этот порог вылетели то создаем файлы на том где больше места

и тут сталкиваемся с тем, что места у нас становится одинаково и, например, двдрип ложится на один диск, а неск. сопутсвующих файликов (кавер + описание) отправляются на второй т.к. места теперь больше там:)

>и тут сталкиваемся с тем, что места у нас становится одинаково и, например, двдрип ложится на один диск, а неск. сопутсвующих файликов (кавер + описание) отправляются на второй т.к. места теперь больше там:)

это да

мало того: в случае если это доразвивается до сплитов то местами даже половинки файлов лежать будут

собственно именно этого эффекта и добиваемся )

О, хороший тред. Тоже захотелось.

Уточню, что.

Чтобы было несколько винтов, монтируемых в одно место. При этом каждый винт в отдельности монтируется без бубна, и всё его содержимое легко доступно (файлы не делятся, целиком пишутся на один из винтов, можно раскидывать их по носителям как угодно).

Избыточности, скорости и прочего не надо. Лучше вместо этого иметь "искаробочность".

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

Подскажите, на что поглядеть надо?