> Пока что btrfs позволяет stripe и raid1,А также raid5/6 если вы ощущаете себя реальным камикадзе. Но оно пока сырое и не для продакшна.
А вообще, теоретически btrfs может на ходу разложить "вот этот файл" в "вон такую схему RAID". При условии что свободное место на достаточном количестве девайсов это позволит. Это уход от фиксированных уровней RAID, жестко привязанных к дискам и их количеству. Совсем иной взгляд на то как можно делать RAID. Есть девайсы и свободное место на них. Можно для "вот этого объекта" заказать "вот такой уровень RAID". И если число девайсов и доступное место на них это в принципе позволяет изобразить - вы это получите.
> при ограниченном бюджете и не принимая в расчет сервера с кучей дисков,
> raid5 на 3-4 диска это самое оно,
У btrfs RAID достаточно забавно сделан - админы привыкшие к тому что RAID фиксированно размещен по дискам и является какой-то определенной и более-менее фиксированной в плане его типа величиной - будут долго делить на ноль. Архитект btrfs не искал простых путей и решил что летать низко - не к нему. Не знаю тянет ли это на совсем новое поколение, но это совершенно иной подход и мне нравится такое мышление архитекта. Это круто и гибко. Чувак не любит проползать под планкой - он в настроении брать новые высоты.
> если вы хотите обезопасить свои файлы, но не покупать кучу дисков для зеркал.
Если вы хотите обезопасить файлы - делайте бэкапы. Ни RAID, ни снапшоты их не заменят. Желательно на физически отдельный компьютер. Потому что если у вас например пыхнет БП и overvoltage protection не сработает - синхронно умрет ВСЯ электроника. При этом все-равно - 1 у вас диск или 10.
> А про кодинг и тестирование - уже есть ZFS которая прекрасно работает, зачем?
Понятия о прекрасном - у всех разные. Древнючий CoW с рядом бестолковостей, без нормальных экстентов, без дефрагера, с дурным управлением памятью, отсутствием backrefs для простого и быстрого вынимания диска из пула и прочее - как-то совсем не предел мечтаний, имхо.
> Несомненно фича интересная, но вызывает много вопросов, например насколько хорошо оно будет
> балансировать данные между дисками,
Если так вышло что баланс вам не нравится - есть ребалансер. Кроме всего прочего оно еще и гибкая штука в плане размещения данных.
> при наличии множества разных уровней raid и не будет ли кучи потерянного места.
Вообще-то куча потерянного места - это для начала про классические RAID с их деревянным допущением что все файлы имеют одинаковую ценность на продолб, а все диски обязаны быть одинакового размера. Это проще всего реализовать, но отнюдь не самое эффективное решение. На многодисковых конфигах btrfs может доюзывать место которое бы пропало на обычном RAID. Путем например использования разных сочетаний дисков. Как вам мысль: RAID-1 с блоками на "вот этом диске" может иметь *несколько* *разных* парных дисков для разных групп блоков? При этом все блоки будут иметь избыточную копию на отдельных дисках, но схема не будет жестко завязана на размеры дисков как таковые. При помирании диска все объекты с RAID1 имеют копию блоков на других дисках. При этом в degraded выпадает не "RAID вообще", а "объекты которые имели блоки на проблемном диске". Вот так вот.
> А также как оно себя поведет, если например у вас в пуле raid0 диск накрылся,
Ложки нет. И диска/пула "raid0" - нет. Такая фигня. Есть "raid0 у вон того объекта". А у вон того - raid 1. Если упал диск на котором было 2 объекта, один с raid-0 и второй с raid-1, объекты хранившиеся как RAID1 выживут за счет копий на других дисках. А raid0 на то и raid0 что ставит скорость выше сохранности, объекты хранимые как raid0 содержавшие блоки на проблемном диске будут ессно порушены. Придется вам перекачать прон заново. А рабочие документы перекачивать не придется. Мне такой подход видится куда как более разумным, чем то что сейчас, когда предлагается делать судьбоносное решение на века, а потом попробуй дескать это решение переиграть, не проклянув все на свете.
> но пару файлов вы как raid1 хранили - их конечно можно будет
> fsck выковырять я так понимаю..
С логической точки зрения... метаданные всегда как минимум дублируются, если у вас многодисковая конфига. Так что ФС сама по себе не должна обрушиться в том плане что у нее будет исправная копия метаданных по которой можно продолжать работать как раньше. Участь файлов ессно зависит от того с каким уровнем RAID их было решено хранить. RAID-1 выживут за счет копий блоков на иных дисках, raid0 - помрут. А потом втыкаем новый диск на замену, говорим rebalance - и файлы которые в degraded - должны восстановить свою избыточность путем раскидывания копий на другие диски (новый + те на которых было место).
> Вот и я не понимаю почему такую элементарную вещь btrfs не может,
> а кому-то данные очень важны...
Учитывая как btrfs работает с RAID - не вижу фундаментальных проблем класть блоки файла в 5 копиях на 5 дисков. При условии что у вас в системе как минимум 5 дисков в пуле с достаточным свободным местом в принципе было. Если вам такое надо и то что уже есть не нравится - ну, попробуйте попросить фичу, если можете внятно описать зачем так надо. Стоит понимать что для очередного RAID все-таки пилить логику рекавери и ряд утилит, так что безбашенно просить черти-что для красоты - не надо.
> Можно также спорить, что управление мешаниной из различных уровней raid тоже филиал ада.
Это филиал ада... но не для админа, а для ФС и ее разработчиков в основном. Так по крупнопу - вилы вылезли например вон в том вопросе по свободному месту. Потому что есть свободное место на дисках. Ничего не известно о том как попросят разложить данные. Если вы захотите raid0 - влезет так. А если raid-1 - эдак. И какую величину вам показать как прогноз "сколько уместится"? Ну так, с логической точки зрения :). ФС ведь не знает заранее - порево вы собираетесь дозаписать или документы.
Зато админ может переиграть судьбоносные решения в плане уровней RAID без тотальной перетряски всего убер-стоража на 100500 дисках. Это довольно круто задумано, а? Хоть и имеет странноватые tradeoffs.
> Хотя согласен, что при наличии всего двух хардов, наверно удобно документы хранить
> в raid1, а порно в raid0 на тех же дисках.
Более того - можно запилить новую схему RAID ... без перетряски старых данных. Тот факт что ФС стала уметь raid5 и даже запись новых блоков в raid5 никак не мешает жить блокам в raid1 которые уже были. Они по прежнему будут raid1. На дисках будет некая смесь разных уровней raid а возможность починки при отвале будет пообъектно определяться уровнем RAIDизации объекта vs то что сдохло.
> Я знаю многих, у кого на десктопе raid5.
Ну ... допустим мне перестало хватать места на существующем raid5. Мои дальнейшие действия? А чтоб без эпического кластерфака? В btrfs в идеале - добавить 1-2 диска, может пересмотреть уровни RAIDов неких сущностей, ребаланснуть, чтобы новички в игру вступили, взяв часть нагрузки. Это просто и понятно. И ранее запрошенные уровни RAID для объектов никак не изменятся от самого факта "добавили 2 диска". И кто сказал что новые диски - того же объема что и старые, etc?
> Google тоже использует ext4 без журнала, потому что им проще тупо диск
> заменить если с ним что-то не так и засинхронизировать с другого сервера.
ИЧСХ это вполне валидный подход. Более того - они сочетают скорость ФС без журнала с надежностью получше любого RAID, т.к. отдельно взятый сервак может вообще выгореть синим пламенем вместе со всеми дисками, а этого никто и не заметит. Я нахожу это весьма логичным устройством большой распределенной конструкции. В конце концов, вы не сможете бесконечно добавлять диски и делать 1 сервер все круче и круче. А они это могут масштабировать бесконечно.
> ZFSonLinux в IBM Sequoia используется например.
Мне не жалко, флаг им в руки. А для себя я хочу решение без типовых грабель ZFS и встроенное в майнлайн. Кстати те же IBM были одной из фигур за btrfs. Когда-то давно IBM, Oracle и кто-то еще устроили некое обсуждение и в итоге решили отбабахать ФС нового поколения, взяв лучшее из существующих дизайнов. Мэйсон попыхтел, посмотрел на существующие ФС и их проблемы, да и сделал btrfs. Как раз по заявкам этих слушателей. Насколько получилось - вопрос интересный. Но ряд дурных грабель старых дизайнов и правда остался за бортом, а такое сочетание фич не присутствует ни в какой другой ФС.
И, например, невозможность вырубить CoW механику под базой - это достаточно жирные грабли файловой системы, если что. Это накрывает медным тазом многие применения ФС с БД. Если так обратить внимание, те кому надо нагруженные базы данных - совсем не рвутся ZFS использовать. Там нет рукояток позволяющих захинтить ФС что базу не надо CoW'ать, а CoW базы с активной записью - ахтунг-ахтунг-ахтунг.
> В том то и дело, что zfs вполне можно доверить данные, поэтому
> статья и говорит что оно production ready с небольшими оговорками.
Так доверяйте, я не против. Я просто высказал свое мнение насчет перспектив всей этой возни и устройства этой ФС.
> У ZFS тоже есть недостатки, в частности домашних пользователей печалит невозможность на
> данный момент удалить диск из пула (в проекте)
Я не совсем понимаю как они намерены удалять диск из пула малой кровью. Для этого надо "рояль в кустах" - back references, позволяющие посмотреть кому принадлежали блоки и просто и быстро заапдейтить метаданные после перемещения блоков, чтобы блоки теперь искали в новой локации. В btrfs такое *заранее* предусмотрели. Ну то-есть, абсолютно нерешаемой эта проблема не решается, но когда архитект это еще на фазе дизайна явно предусмотрел - это сиииииильно упрощает дело. Более того - я не понимаю почему кто-то мнит что после столь крутой перетряски дисковой механики на самом базовом уровне все эти ахи-охи про стабильность будут применимы. Скорее всего под такое надо будет разворотить половину кода, а после таких изменений его весь надо будет тестировать с ноля и вылезет уйма новых вкусных грабель, ибо чудес не бывает.
> или добавит диск в vdev (Т.е. вместо raidz на 3 диска сделать raidz на
> 4 и сделать перестройку массива.
Ну а вот в btrfs никакие бучие "перестройки" делать по сути не надо (кроме случая "диск сдох"). Можно вообще новый уровень RAID запилить никак не затрагивая существующие данные. А новые данные сохранить уже с новым уровнем RAID, например. Технически их подход позволяет наворачивать иные методы RAID, плавно и постепенно мигрировать на них без глобальной перетряски стоража. И такой стиль мышления архитекта мне, определенно, нравится. Он таки подумал о практических аспектах эксплуатации многодискового пула. При том подумал свежо и оригинально, рискнув сделать нетривиальные но многообещаюище решения вместо трусливого заметания проблем под ковер и упрощения себе жизни. Это как-то более честно чем замести технические проблемы, сделав как проще и вытянуть потом маркетинговым булшитом, как это любили делать сани.
> Добавить vdev к страйпу можно и сейчас
А если там не страйп - придется обломаться и ребилдить, да? :)
> и также можно заменить все диски в vdev на больший объем и сделать ресайз).
А в btrfs весь этот эпичный кластерфак просто obsoleted - by design.
> С памятью по большей части проблемы надуманы и в основном относятся к ONLINE! dedup,
А я склонен полагать что аллокатор без экстентов чудес производительности с неба не хватает и гигазы оперативы нужны в том числе и для вытягивания достаточно тормознутых свойств такого дизайна. Как вы понимаете, все новые дизайны ФС свалили на экстенты не потому что это модно, а потому что так лучше работает в большинстве нагрузок. Вкатить одним махом запрошенный регион - самое логичное решение которое можно придумать. Логично что это неплохо работает. Если задаться целью - завалить такую механику неудобной нагрузкой конечно тоже можно, но завалить можно любую механику ФС. Все ФС в среднем работают сильно лучше чем краевые worst case.
> который почти наверняка у BTRFS будет жрать столько же памяти, это почти неизбежно.
Btrfs не надо вытягивать тормоза аллокатора. Экстентные аллокаторы сами по себе довольно шустрые, без подпирания десятками гиг оперативы. Одно дело лопатить кучу блоков и метить это, и другое - если повезло то просто вбахать влобовую запрошенный регион, как просили, и на этом успокоиться.
> Но в целом на данный момент ZFS гораздо более надежна и функциональна
> по сравнению с BTRFS для большинства применений, кроме самых базовых вроде
> fs на одном диске/stripe/mirror.
Возможно. Но говоря за себя - я предпочитаю увидеть btrfs доведенный до ума в майнлайне, а не странный zfs с кучей трудноустранимых грабель дизайна и где-то сбоку. Интеграция с системой - это хорошо. Куда удобнее поставить дистр на файлуху средствами штатного инсталлера чем сношать себе мозг с докачкой и отдельными бутовыми разделами и/или самоличным закатом солнца вручную.
Я не хочу всю жизнь ребилдить RAID. Это булшит. Я не хочу переворачивать полсистемы вкорячивая левые third-party модули. Турбореактивные самолеты стали основным средством перевозки. Даже если Туполеву и пришлось пару раз обтечь за первые ТУ-104, в результате винтовые самолеты - нишевая штука, а отнюдь не основное средство перевозки. Мэйсон сделал то же самое с уровнями RAID. Даже если ему придется пару раз обтечь - это не отменяет того факта что он применил ряд новых подходов, которые вполне могут задать новую планку, которую всем остальным придется или взять, или свалить на свалку истории как безнадежный хлам.
Вариант для распечатки
(ok), 12-Сен-14, 20:15 
