Брендон Филипс (Brandon Philips), технический директор компании CoreOS Inc, развивающей основанное на идеях контейнерной изоляции серверное окружение CoreOS (https://www.opennet.ru/opennews/art.shtml?num=40275), выступил (https://groups.google.com/forum/m/#!topic/coreos-dev/NDEOXch...) с предложением ухода от использования по умолчанию файловой системы Btrfs в пользу связки из Ext4 и многослойной файловой системы OverlayFS (https://www.opennet.ru/opennews/art.shtml?num=40947).
В качестве причины прекращения использования по умолчанию Btrfs упоминается периодическое поступление от пользователей жалоб о работе Btrfs, в том числе об ошибках при исчерпании свободного дискового пространства, требующих ручного вмешательства проблемах с ребалансировкой метаданных и низкой производительности (https://docs.google.com/presentation/d/1npITxQaHSq0QZlZYL7cJ...), по сравнению с другими ФС. Выбор в пользу OverlayFS обусловлен более высокой производительностью, простотой реализации и появлением данной ФС в составе штатного ядра Linux 3.18 (https://www.opennet.ru/opennews/art.shtml?num=41210).
URL: https://groups.google.com/forum/m/#!topic/coreos-dev/NDEOXch...
Новость: https://www.opennet.ru/opennews/art.shtml?num=41312
Ура, здравый смысл восторжествовал!
Пусть пилят и пилят свою лучшую файловую систему с деревьями, обмазанными маслом:) Файловая система не пасьянс -- тут несколько более высокие требования к стабильности.
Они все с деревьями. Которые современные.
Не сомневаюсь. Ты это к чему?
Если ты про мою фразу, то я намекал на название ФС, в котором фигурируют деревья и даже, по некоторым сведениям, масло:)
А я думал что это просто чемпионат по тормозизму.
Ага, а OverlayFS прямо вся такая годами обкатанная в боевых условиях.
Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%, и не заменят регулярный бэкап.
>если юзер допускает заполнение диска на 100%Можно подумать что это не штатная ситуация. Это нормально. И это уж никак не повод рассыпаться.
> Можно подумать что это не штатная ситуация. Это нормально. И это уж
> никак не повод рассыпаться.Так обычно и не рассыпается. Но может потребоваться костыль в виде ребаланса.
> Так обычно и не рассыпается. Но может потребоваться костыль в виде ребаланса.UPD: В ядре 3.18 костылирование автоматизировано :)
годами обкатана пользователями openwrt
условия правда больше не боевые, а домашние, зато полет вроде у всех нормальный в отличие от
> условия правда больше не боевые, а домашние, зато полет вроде у всех
> нормальный в отличие отПравда условия тепличные, типа записи мегабайта в год...
> зато полет вроде у всех нормальный в отличие отв отличие от?
> Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%, и не заменят регулярный бэкап.Чтобы юзер не допускал заполнение диска на 100%, нужно, чтобы системный вызов statfs (используемый командой df и всеми существующими решениями для мониторинга в искоробочной конфигурации) не врал. А вся претензия тут именно в том, что он врет, и вместо его починки предлагается гонять какой-то нестандартный btrfs-специфичный.
> искоробочной конфигурации) не врал. А вся претензия тут именно в том, что он врет,Он не врет. Просто btrfs может на ходу кроить произвольные уровни RAID и ответ на вопрос "сколько места?" зависит от "в каком RAID будете сохранять?".
> Просто btrfs может на ходу кроить произвольные уровни RAIDЭто какие? RAID-0 (который RAID'ом называется чисто условно) и RAID-1 разве что.
> Это какие? RAID-0 (который RAID'ом называется чисто условно) и RAID-1 разве что.Теоретически - любые, которые набор девайсов позволяет. Есть девайсы и свободное место на них. Если надо зеркало - значит пишем на 2 девайса (свободного места на них станет меньше). Если stripe - аналогично.
Практически есть "no raid", RAID0, RAID1, а в экспериментальном виде RAID5/6. Кстати в 3.19 рекавери с райдов 5/6 улучшили и оно приближается к продакшновому состоянию. Если уж на то пошло. А покажи мне еще ФС где можно разные уровни райдов на одном и том же наборе девайсов? Как ты понимаешь, совсем не факт что все данные имеют одинаковую ценность. Поэтому какая нибудь шара с видео с корпоратива - одно, а рабочие документы - другое. И логично их хранить с разными уровнями райда.
>А покажи мне еще ФС где можно разные уровни райдов на одном и том же наборе девайсов?LVM в AIX давно это умеет. Лет 20, наверное...
> LVM в AIX давно это умеет. Лет 20, наверное...Что, оно прямо так уж пофайлово может принимать решения? Дескать, вон тот файл мы как RAID-1 запишем, а этот как RAID-5? Если да - ну я рад за ибмщиков, здорово обогнавших остальных. Но боюсь что мне aix - ни в п...у, ни в красну армию.
ППС
> Кстати в 3.19 рекавери с райдов 5/6 улучшили и оно приближается к
> продакшновому состоянию.
> рекавери
> продакшновому состояниюрекавери приближается к продакшновому состоянию?
> рекавери приближается к продакшновому состоянию?Для RAID5/6, поддержка которых как известно была заявлена экспериментальной фичой. Собственно оно экспериментальное в том числе и потому что там не было кода который бы делал рекавери порушеных данных по избыточным данным райдов 5/6. В 3.19 судя по коммитам за это дело взялись и этот код появляется. Обычная сборка автомобиля во время гонки, которой так славится опенсорс :).
"А покажи мне еще ФС где можно разные уровни райдов на одном и том же наборе девайсов"А зачем это всё в одну ФС утрамбовывать? Уже много лет доступен вариант с mdadm и часть HDD добавляешь в RAID0, другую часть в RAID1. То что можно отформатировать в разные ФС - это бонус, а не недостаток.
> А зачем это всё в одну ФС утрамбовывать? Уже много лет доступен
> вариант с mdadm и часть HDD добавляешь в RAID0, другую часть
> в RAID1. То что можно отформатировать в разные ФС - это
> бонус, а не недостаток.В случае btrfs по задумке райды могут сосуществовать и возможно их перегонять 1 в другой. Постепенно. Это пока в зачаточном состоянии, но на уровне архитектуры - заложено. И возможность гибко прогибать уровни райда под текущие нужды, без огромных перетрясок - это фича. А какая-то там возможность откусить кусок - заявка на головную боль, ибо потом это на ходу переконфигурировать - сплошной гемор. Надо решения на столетия вперед принимать.
Он врет. Уровни RAID никак не связаны с числом байт которые в данный момент времени система может не использует.
> Он врет. Уровни RAID никак не связаны с числом байт которые в
> данный момент времени система может не использует.Можно сколько угодно выводить количество байт, которые система не использует - эта характеристика бесполезна при определении возможности заполнения устройства, а значит, в вашей терминологии, является враньем.
Дано: два винта по 1000Гб в одном пуле btrfs. На каждом из них занято по 990Гб. Не используется, таким образом, 20Гб.
Вы хотите узнать, достаточно ли на них места для записи 15Гб файла. Если вы будете записывать его в режиме stripe, потратится 15Гб. В режиме mirror - 30Гб.
Помогли, сынку, тебе твои поляки?
> Помогли, сынку, тебе твои поляки?Вот этот момент замшелые мамонты никак понять не могут :). А тем временем иметь возможность менять уровни райда и назначать разным данным разные уровни и все это на лету и без многотерабайтных перетрясок - более чем.
А так ждем когда эти ретарды заметят у себя в системе оверкоммит и возмутятся тем что программам вывешивается больше адресов чем в системе есть памяти.
оверкоммит давно выключен, ибо нефиг
> оверкоммит давно выключен, ибо нефигПравильно, давайте неиспользуемые адреса оперативой обеспечим.
> Можно сколько угодно выводить количество байт, которые система не использует - эта характеристика бесполезна при определении возможности заполнения устройства, а значит, в вашей терминологии, является враньем.Ну-ну. И какое отношение число байт которые можно записать в файловую систему имеет к числу байт которые система не использует на устройстве?
Или может вы хотите сказать, что в рамках ОДНОЙ файловой системы Btrfs один файл может записать как RAID0 а второй как RAID10?
И я не хочу узнать достаточно ли места для 15Гб файла. Я хочу что бы Btrfs как xfs/ext*/ufs*/ntfs/fat*(!) когда осталось на доступных устройствах осталось 0 байт продолжала нормально работать на чтение. Увы, но самая прогрессивная ФС современности почему то в этом уступает даже fat16.
> Или может вы хотите сказать, что в рамках ОДНОЙ файловой системы Btrfs
> один файл может записать как RAID0 а второй как RAID10?Именно - оно спроектировано так, что технически при создании файла можно заказать ему любой поддерживаемый ФС уровень райда. Далее если на достаточном кол-ве девайсов есть достаточно места, файл будет записан с именно такой схемой размещения. Реально пока есть не все уровни райда, а утиля умеет конфигурирование по субволумам. Что тоже довольно неплохо - каждый сабволум может иметь свой уровень RAID и они все используют один и тот же пул девайсов и спободного места на них, что как бы намекает.
> осталось 0 байт продолжала нормально работать на чтение.
Так она при этом нормально работает на чтение?
> Вы хотите узнать, достаточно ли на них места для записи 15Гб файлаКто Вам сказал такую глупость? Я хочу, чтобы, когда у меня возникнет потребность записать файл 15ГБ, я мог его просто взять и записать, не задумываясь о том, сколько туда ещё можно записать. Для этого я хочу знать, когда надо начинать освобождать место.
И вообще, если задаётся вопрос "сколько свободного места" то надо отвечать именно на этот вопрос, а не подменять его вопросом "сколько ещё можно записать".
> И вообще, если задаётся вопрос "сколько свободного места" то надо отвечать именно
> на этот вопрос, а не подменять его вопросом "сколько ещё можно записать".Полный ответ на этот вопрос содержит список девайсов и список места на них. Это делается командой btrfs filesystem df или соответствующими вызовами. Видя эту информацию уже можно делать некие выводы по части влезет ли такой-то файл с такой-то запрошенной схемой размещения. Но это далеко от архаичного простого сискола.
И даже это не верно.
Потому что этот ответ не доступен пользовательскому ПО бау_дезигн уже несколько поколений как.
К примеру — вот место есть. Но 5% (или 3%, или 10%. От админа зависит, а не от фс, lvm или ещё чего) заресервировано для рута. Или например админ квоты выставил.Пользовательское ПО должно просто грамотно обрабатывать исключение нехватки ресурсов и всё.
И делать это до того, как потеряются данные (например вначале попытаться выделить место и только потом писать туда).
Именно такая логика при разработке ПО для юзер-спейса в многозадачной (и много-пользовательской) среде.
Не понимающие этого — просто недоученные ламеры (вопли которых на форумах, кстати, всё равно ничего не решают)
А в более-менее однопользовательской среде что делать? Качаем пол-дня большой файл и посреди закачки натыкаемся на нехватку места - как здесь, черт возьми, "грамотно обрабатывать исклбчения нехватки ресурсов"? На ПК, знаете ли, обычно нет квот и извращенных рейдов. А необходимость пользователю (и его софту) знать, сколько места свободного - есть. Хрен с ними, со сложными ситуациями - там спецы будут разбираться. Простые надо вменяемо обрабатывать. Где древнего сисколла ещё как хватит.
> А в более-менее однопользовательской среде что делать?И более-менее однозадачной?
Ну ставьте дос, раз вам так всё плохо.
> Качаем пол-дня большой файл и посреди закачки натыкаемся на нехватку места - как здесь, черт возьми, "грамотно обрабатывать исклбчения нехватки ресурсов"?Выделять место зарание. Уже было сказано.
> На ПК, знаете ли, обычно нет квот и извращенных рейдов. А необходимость пользователю (и его софту) знать, сколько места свободного - есть.Удаляешь одно ненужное и закачиваешь поновой другое очередное ненужное.
Как все более-менее пользователи и делают. И даже не знают как называется их ФС.И для безпардонных умников, с претензией на профессионализм, такая мелочь всё-равно не перебивает плюсы работы со снэпшотами (которые не в пример гибче, чем у zfs), работы с субволумами, возможности компрессии на лету и тд, и тп.
Почему однозадачной? В однопользовательской среде пользователь отлично знает, что и насколько может забить диск. Потому что, по факту, кроме его деятельности и каких-нибудь торрентов больше это делать и нечему. И в таком сетапе нет вообще никакого резона не отдавать нормлаьно свободное место. Сейчас число совсем от балды - а так она будет осмысленной для частного, но распространённого случая.И правильно - прибиваешь одно и качаешь или создаёшь другое. Но для этого нехудо бы знать, сколько именно надо прибить, например. Или сколько видео с камеры влезет. В общем, как по мне - ты старательно пытаешься спорить с тем, что вода мокрая, приводя в пример Чукотку.
А что до фич - угу, снапшоты. Обычно только они (плюс COW иногда) и нужны во всей этой чехарде. Остальное - для сильно специальных применений. как та же компрессия, подходящая для полутора случаев - большинство объёмных данных, как правило, ни хрена не жмётся, так как уже сжаты.
> От админа зависит, а не от фс, lvm или ещё чего)
> заресервировано для рута. Или например админ квоты выставил.Насколько я помню, это работает только на EXT2/3/4. И управляется специфичным для них образом через tune2fs. Который специфичен для ext-ов. Остальные ФС не умеют такой резерв. Если я прогнал - ок, покажи как это сделать на, допустим, XFS. У меня с ним том под рукой есть - я это дело проверю :).
> Пользовательское ПО должно просто грамотно обрабатывать исключение нехватки ресурсов и всё.
Несомненно. В случае btrfs фокус в том что даже удаление файла требует ... сделать CoW выносок для хотя-бы метаданных. А если места нет - ээээ... как бы это сказать... стереть файл - фигвам! :). Потому что для этого надо записать измененный вариант диры. А поскольку CoW и неразрушающая запись - пропатчить старый вариант диры, как в классике - не вариант.
Да, инженеры иногда могут не подумать о некоторых вещах на краевых условиях и иногда это может смотреться довольно забавно. Против такого обычно помогает ребаланс, т.к. chunk'и могут быть заполнены не 100% идеально и получится отыграть какие-то крохи достаточные для удаления. Начиная с 3.18 нечто подобное в такой ситуации делается автоматически.
> Именно такая логика при разработке ПО для юзер-спейса в многозадачной (и много-пользовательской) среде.
В случае btrfs одного простого сискола недостаточно для понимания поместится ли файл на том что есть. Из-за его умений работать с RAIDами и потенциальной способности столкнуться с произвольной смесью уровней избыточности и на самом фундаментальном уровне - нужде наперед знать в какой схеме будут данные хранить. Даже сейчас это известно не на 100% а план таков что не будет известно совсем - такая структура нормально относится к произвольной смеси. Уже сейчас данные и метаданные могут храниться с разными уровнями избыточности, etc.
> Уровни RAID никак не связаны с числом байт которые в
> данный момент времени система может не использует.Вот только если я записываю 100500 байтов как RAID0 - это один случай. А как RAID1 - другой.
А ответ на вопрос "получится ли записать 100500 байтов с такой-то схемой хранения?" зависит от конкретики в плане девайсов и свободного места на них. И это не ограничивается 1 примитивным сисколом.
>> Уровни RAID никак не связаны с числом байт которые в
>> данный момент времени система может не использует.
> Вот только если я записываю 100500 байтов как RAID0 - это один
> случай. А как RAID1 - другой.Я может чего не знаю, но одна ФС - одна схема RAID.
> А ответ на вопрос "получится ли записать 100500 байтов с такой-то схемой
> хранения?" зависит от конкретики в плане девайсов и свободного места на
> них. И это не ограничивается 1 примитивным сисколом.Как верно подмечено зависит от схемы хранения. Определяемой ФС. И таки да, ограничивается 1 примитивным вызовом.
Это похоже на разговор слепого с глухим. Да, за счет сжатия и дедупликации файл может физически занять меньше места. Но ФС должна быть способна понять способна она записать файл размера X или не способна. И ведь количество копий блоков данных зависит не от имени или атрибутов файла, а от разметки самой ФС.
> Я может чего не знаю, но одна ФС - одна схема RAID.Тут профессионалы продакшенов. У них на каждом из стапятисот серверов свой уникальный ни с чем несравнимый компот. И им нормально не знать что, где, чего и сколько.
>> Я может чего не знаю, но одна ФС - одна схема RAID.
> Тут профессионалы продакшенов.Куяврикам не понять что смесь RAIDов на одной файлухе это гибко и рационально в плане использования площади накопителей. А вот нормальные архитекты и те кто им ставит задачи - догадываются.
При всей крутости такой системы (респект разработчикам, серьёзно) подозреваю, что для 99.99% юзкейсов лучше сгодилась бы пачка отдельно примонтированных томов с разными рейдами. Да, менять размер томов, если что, пришлось бы руками - но на то и LVM, и при разумном планировании вряд ли это составило бы хоть какую-то проблему. Зато софту в таком варианте легко принимать решения - что куда влезет. А вариант "решаем по ходу", как видим, слишком усложняет жизнь.Эх, взять бы эту btrfs, выкинуть всё кроме COW со снапшотами - глядишь, давно была бы полностью готова, протестирована и предсказуема во всех мыслимых ситуациях, уже б, пожалуй, ext4 подвинула. А так... Комбайны - зло.
Софт никогда не принимал решения что и куда влезет. Вот вообще. Как 386 появились, так это точно. Максимум — оценить пытаться или нет.
К примеру, по-умолчанию 5% в extX зарезервированы для рута, потом существуют квоты,... в общем куча механизмов. Полагаться только на df — идиотизм и не профессионализм (в системе куча процессов и ваше ПО конкурирует с ними за ресурсы, включая дисковую память. Вот сейчас она есть, а вот её уже и нет. Кто-то порнушку например поставил на закачку как раз между тем как вы вызвали df и начали что-то записывать на диск)
Серьёзное ПО либо сразу выделяет место (субд например. да даже торренты. Опять же — либо само либо посредством админа/дба/..), либо корректно обрабатывает исключение нехватки места (ну либо и то, и другое сразу). И это всё.
При этом поиметь механизм избыточности на голом месте более чем интересная фишка.
Тем более, что (как вы там сказали?) при разумном планировании вероятность нехватки места в нужный момент стремится к нулю (вы либо расчитали это до такого момента, либо подготовились. купили таки винты/ссд/.. ну или хотя бы прикрыли попу в виде заявки руководству).
Но это при разумном. При не очень разумном получить ситуацию, когда вот на этом вот волуме lvm места уже нет (а нужно именно на этом), а вот на этом его ещё дофига — раз плюнуть.
Оцените вероятность такой ситуации в этом случае и в случае с бтр, когда всё доступное место в системе собственно... доступно.
Всё запланировать можно заранее - в "промышленных" ситуациях. На ПК - некому планировать, но там нет обычно ни квот, ни рейда. Там ситуация простая как пятак - пользователь знает, кто может забить его хомяк - он сам. И он должен знать, что ему поместится, а что - нет. И если он, скажем, распаковывает архив (про тот же .gz софт до распаковки не знает, сколько он займёт, а вот пользователь обычно неплохо это представляет) - он должен иметь возможность оценить, получится распаковать или нет.А в продакшне - насколько я знаю, предсказуемость всегда ценнее, чем колдовство на предмет выгадать место. Лучше я точно буду знать, что мне место для базы через месяц закончится, чем с шансами оно внезапно закончится завтра, хотя должно было протянуть ещё два.
> Всё запланировать можно заранее - в "промышленных" ситуациях. На ПК - некому планироватьДа-да, как же тяжело быть обычным юзером.
Ай-ай. Ай-ай-ай.
Пляча, стирает старую порнушку и заливает новую.Зыж
Только для совсем уж тyпoго тролля эта тема может быть ещё интересна.
Обычным юзером быть хорошо. Особенно когда понимаешь, какой минимум средств тебе нужен и не пытаешься в булочную летать на космическом корабле. И, что характерно, таких случаев - абсолютное большинство. Не серверов с крутыми СХД, а десктопов/планшетов/смартов, плюс облака вроде гугловского, rackspace и прочего, где все понимают преимущества простоты.
> Всё запланировать можно заранее - в "промышленных" ситуациях.Во первых даже там это проблема. Через сколько-то лет эксплуатации резко носиться колбасой, подбирая правильные винты для стоража в правильном количестве - удовольствие здорово ниже среднего. Это сильно нагибает свободу маневра и вообще, требует или тратить деньги и становиться складом запчастей или сталкиваться с нуждой резко подрываться и экстренно что-то предпринимать в не самой удобной позе.
> На ПК - некому планировать, но там нет обычно ни квот, ни рейда.
Во вторых я не вижу почему бы мне не получить просто прибавку места в ФС на моем десктопнике при втыкании к 3 винчам 4-го, без фундаментального перетряса всего содержимого 3 винчей с переносом ... на еще штуки три отдельных винча на это время? :)
В третьих я не понимаю почему мощный домашний десктоп должен быть принципиально недостоин райда.
> А в продакшне - насколько я знаю, предсказуемость всегда ценнее, чем колдовство
> на предмет выгадать место.Если посмотреть на тенденции по оверселлу и оверкоммиту, можно заметить что бизнес выбирает выгоду и в курсе теории массового обслуживания :).
Хинт: никто не строит например сотовую сеть с замахом на одновременное обслуживание ВСЕХ абоннтов. Критичен ли завал сотовой сети? В общем случае еще как. Но как-то так получается что с клином сетей в 00:00 01.01 все как-то смирились и считают неидеальную работу сети в этот период времени, скажем так, приемлимым. Просто потому что идеальная работа сети и в такой период тоже - потребует вбухать в инфраструктуру в несколько раз больше, а потом оно будет в основном простаивать почти весь год. А т.к. бабло побеждает зло...
> место для базы через месяц закончится, чем с шансами оно внезапно
> закончится завтра, хотя должно было протянуть ещё два.Энтерпрайзный админ хранилища должен знать как его файлуха работает и быть в состоянии понять когда пора расширяться. При том задолго до того как жареный петух клюнет. И грубо оценить что влезет на бтрфс - админ по любому обязан, по статистике девайсов и пониманию работы уровня райда.
> юзкейсов лучше сгодилась бы пачка отдельно примонтированных томов с разными рейдами.Это не гибко. Любое изменение конфигурации == боль пониже спины. С факом мозга подбором винтов и их размеров, адскими временами рестрайпа, при том чаще всего оффлайнового и нуждой куда-то на это время деть кучу данных и прочее.
Идея btrfs: доткнуть диск и, может быть, сделать ребаланс чтобы он принял на себя более-менее пропорциональную часть нагрузки/восстановил слетевшее парити (если надо, актуально для degraded RAID), etc. Это просто, круто и логично. И рациональнее в плане расхода места в mixed конфигурациях собранных "по месту", из накопителей разного объема.
Эта конструкция не подразумевает что например RAID1 - группа дисков одинакового объема. Можно скажем воткнуть 1 большой винч и 2 половинной емкости и получить емкость 1 большого винча - парные блоки будут жить на парах накопителей. И критерий возможность выполнить запись в формате RAID1 - есть достаточное место на 2 дисках. Не обязательно одинаковых. Так можно сделать довольно необычные конфиги, типа RAID1 из 3 дисков - с емкостью 1.5 диска (при одинаковых дисках).
Т.е. в целом это все сделано с пониманием со стороны архитекта одной из проблем эксплуатационщиков: довольно сложно и неудобно обеспечивать ФС идентичные девайсы и круто перетрясать все при желании например изменить схему райда. Btrfs сделан так что позволит в общем случае произвольно доткнуть 1 или N дисков в пул. Любых. Которые у вас под рукой есть. И это даст еще эн места. Собственно диск можно и изъять, главное чтобы не стало меньше минимального числа дисков нужных для затребованной схемы и на оставшихся дисках хватало бы места. Ну то-есть из "RAID1 @ 3 диска" можно взять да и вынуть 1 диск. Если на оставшихся 2 места хватит. При этом btrfs уберет блоки с вынимаемого диска. А ребаланс удостоверится что у каждого блока есть пара на другом девайсе. При том в это время все будет работать, данные будут доступны, их не надо будет никуда удвигать на время перекраивания схема райда и прочее.
И я почему-то так считаю что в идеале управление сколь-нибудь заметным сторажем с несколькими дисками должно выглядеть именно как-то вот так.
> на то и LVM, и при разумном планировании вряд ли это
> составило бы хоть какую-то проблему.Распланировать все на века - затея довольно сложная. А в btrfs фича в том что никого не заствляют это делать - можно малой кровью все переиграть. Без того гемора который характерен для райдов работающих целиком на блочном уровне.
> принимать решения - что куда влезет. А вариант "решаем по ходу",
> как видим, слишком усложняет жизнь.Любой дизайн подразумевает некий tradeoff. В классических сисколах о такой крутизне не задумывались и поэтому такое в системных вызовах просто не предусмотрено. Да и классическая семантика POSIX - явно не предел мечтаний для интерфейса к дизайнам на основе CoW. Возможно иногда наступает пора признать что нужно что-то доработать и расширить. В том числе и системные вызовы. Или посчитать что админ должен посмотреть статистику по девайсам и врубить мозг, если он хочет впихнуть еще 1 терабайтный файл на стораж.
> Эх, взять бы эту btrfs, выкинуть всё кроме COW со снапшотами -
> глядишь, давно была бы полностью готова, протестирована и предсказуема...только там не было бы фич ради которых с ней все носятся. Снапшоты - это хорошо. А возможность просто и гибко строить стораж, который потом можно плавно прогибать под фактические реалии - лучше. Энтерпрайзятники, думаю, догадываются и тоже хотят плюшку.
> во всех мыслимых ситуациях, уже б, пожалуй, ext4 подвинула. А так... Комбайны - зло.
И да и нет. Это дает ряд грабель. Но дает и ряд уникальных достоинств которые по иному просто и не получишь. Те же классические блочные райды - идут по пути наименьшего сопротивления и сделали ряд допущений. Удобных разработчикам, но геморных при эксплуатации. А тут - ровно наоборот. Не вижу почему так должно быть нельзя. С точки зрения эксплуатации я предпочту простой и гибкий стораж. Если разработчикам придется попахать - ОК. В моем понимании их цели того стоят.
> Я может чего не знаю, но одна ФС - одна схема RAID.Wrong. В случае btrfs файловая система на уровне своего устройства технически может принимать решение о том как раскладывать файл вообще индивидуально для каждого файла. Все определяется лишь доступными девайсами и местом на них. Реально пока сделана немного упрощенная настройка: уровень RAID выбирается для каждого subvolume отдельно. Что несколько более топорно и менее гранулярно, но тоже позволяет постепенные и плавные restripe путем нехитрых манипуляций с иерархиями. Но технически устройство ФС позволяет и пофайлово указывать желаемую схему размещения.
> Как верно подмечено зависит от схемы хранения. Определяемой ФС. И таки да,
> ограничивается 1 примитивным вызовом.В btrfs может быть произвольная смесь уровней на доступной площади накопителей. Такая вот интересная фигня. Мэйсон не стал утыкаться в архаичные схемы и сделал более гибко. Молодец чувак - мыслит масштабно.
> дедупликации файл может физически занять меньше места. Но ФС должна быть
> способна понять способна она записать файл размера X или не способна.Заранее неизвестно какую схему размещения вы запросите для очередного файла и как это будет согласоваться с реалиями доступными на девайсах.
> И ведь количество копий блоков данных зависит не от имени или
> атрибутов файла, а от разметки самой ФС.У btrfs нет никаких жестких принятий решений при создании файловой системы. Одна из причин по которым я считаю ее шагом вперед. Хоть это и дает некие странности с пониманием сколько места свободно, зато так площадь накопителей можно использовать более рационально. Например если у вас есть 2 диска, например, на терабайт и 2 терабайта - в обычном случае вы можете из них сделать например зеркало на терабайт. А в btrfs при этом терабайт двухтерабайтника будет доступен. Просто зеркально получится разложить не более терабайта. Но еще терабайт вполне можно положить "без RAID" (с хранением на 1 устройстве - 2-терабайтном диске). Профит очевиден - обычный RAID проcpaл бы "лишний" терабайт втупую. А тут можно терабайт некритичных данных без резервирования и терабайт более критичных с резервированием организовать. Но на самом деле с точки зрения btrfs есть 2 девайса. На терабайт и на 2. Как хотите так и пользуйтесь ими в пределах поддерживаемых схем RAID и доступного места на девайсах. И это довольно круто придумано :P. Можно забыть о тряске по поводу размера девайсов, уровни можно переиграть на лету и плавно, в том числе и например файловыми операциями. IMHO это весьма серьезный шаг вперед. Хоть и дающий такие странности в подарок. И нет, одного доисторического сискола не хватит для ответа на вопрос разложится ли вон тот файл по вон той схеме RAID на имеющейся конфигурации девайсов. Для ответа на этот вопрос надо как минимум знать свободное место о каждому девайсу и запрашиваемую схему RAID.
>[оверквотинг удален]
> девайса. На терабайт и на 2. Как хотите так и пользуйтесь
> ими в пределах поддерживаемых схем RAID и доступного места на девайсах.
> И это довольно круто придумано :P. Можно забыть о тряске по
> поводу размера девайсов, уровни можно переиграть на лету и плавно, в
> том числе и например файловыми операциями. IMHO это весьма серьезный шаг
> вперед. Хоть и дающий такие странности в подарок. И нет, одного
> доисторического сискола не хватит для ответа на вопрос разложится ли вон
> тот файл по вон той схеме RAID на имеющейся конфигурации девайсов.
> Для ответа на этот вопрос надо как минимум знать свободное место
> о каждому девайсу и запрашиваемую схему RAID.Ты сам-то такой схемой пользуешься или это просто теоретические измышлизмы?
> Ты сам-то такой схемой пользуешься или это просто теоретические измышлизмы?Да. Вот прямо это сообщение написано с компа с btrfs. И я не рассказываю про преимущества нтфс - потому что я давно забыл этот древний шит как страшный сон. Я никогда не вернусь на винды и нтфс. И наличие бтрфс - одна из причин, если что. Эта штука будет рулить моими накопителями в виде который я считаю разумным, хорошим и правильным. Хоть и не совсем классически.
Я тебя про используемую схему спрашиваю, в частности, а не про Btrfs.Так у тебя эта схема работает или ты излагаешь только лишь что теоретически возможно?
> Wrong. В случае btrfs файловая система на уровне своего устройства технически может принимать решение о том как раскладывать файл вообще индивидуально для каждого файла.Теоретик? Покажите команды для настройки такой схемы "индивидуально для каждого файла".
> Реально пока сделана немного упрощенная настройка: уровень RAID выбирается для каждого subvolume отдельно.Can btrfs handle different RAID levels for different subvolumes?
linux-btrfs@kernel.org : No, not yet. It's planned at some point (probably in the fairly distant future), but hasn't arrived yet.
Для теоретиков: нет, различные уровни RAID для разных subvolume не поддерживаются и возможно будут введены в очень далёком будущем.
RAID выбирается на всю файловую систему целиком. Ну или покажите нам тайные параметры "btrfs subvolume create"
> В btrfs может быть произвольная смесь уровней на доступной площади накопителей. Такая вот интересная фигня. Мэйсон не стал утыкаться в архаичные схемы и сделал более гибко.LVM + любая ФС. ZFS. То о чем вы говорите не является каким-то нововведением.
> Заранее неизвестно какую схему размещения вы запросите для очередного файла и как это будет согласоваться с реалиями доступными на девайсах.Мы же уже определились - одна ФС, одна схема. Она стала известна после создания ФС или изменения с последующей ребалансировкой. Так что известно какую и как это согласовывается с реалиями на девайсах.
> У btrfs нет никаких жестких принятий .... и прочееВы не поверите но все это можно сделать с помощью LVM + ext*/xfs/jfs/raiserjs, zfs, geom, да черт возьми даже в Windows 2000 с помощью динамических дисков и точек повторной обработки!
> И нет, одного доисторического сискола не хватит для ответа на вопрос разложится ли вон тот файл по вон той схеме RAID на имеющейся конфигурации девайсов. Для ответа на этот вопрос надо как минимум знать свободное место о каждому девайсу и запрашиваемую схему RAID.И вот неожиданность именно Btrfs всё это знает. И свободное место и запрашиваемую схему.
Как вы не можете понять, что не важно сколько дисков и уровней RAID, сколько subvolums и снепшотов и df и btrfs fi df выводят информацию по ФАЙЛОВЫМ СИСТЕМАМ а не отдельным файлам.
Только df выводит сколько место используется и сколько свободно для ФС. А btrfs fi df выводит такую хрень, как сколько места заюзано по Data, System, Metadata и не в состоянии сказать, а сколько примерно ещё свободного места есть в системе. Конечно, сколько ФС заюзала под свои метаданные мне знать нужней объема свободного места.Но знаете в чем парадокс? ZFS в отличии от btrfs имеет не только работающий RAID (5/6 в btrfs так и не допилили) но и умеет указанное число раз дублировать данные в том, что вы именуете "subvolums" (вы неверно приписали это свойство btrfs). И почему то ей доисторического сискола хватает. И она в состоянии вывести объем свободного места, причем правильно.
И судя по вашим утверждениям о RAID на файл вы не особо хорошо знакомы не с внутренним устройством btrfs, ни с её практическим применением.
> Теоретик? Покажите команды для настройки такой схемы "индивидуально для каждого файла".Их нет. Пока. Но архитектурно так можно. Если посмотреть на то как btrfs вообще сделан и как он выделяет пространство. Отсюда вытекает ряд, казалось бы, странностей.
> Для теоретиков: нет, различные уровни RAID для разных subvolume не поддерживаются и
> возможно будут введены в очень далёком будущем.Архитектурно - поддерживаются. Реально для этого надо изменения в утилитах настроек и аллокаторе чтобы как-то метить что и в какой схеме раскладывать. Но это заложено в устройстве ФС. А если этого не сделать - так не будет нельзя вообще совсем никогда.
Это выглядит как-то так: в ФС есть некие наборы chunks. Chunks могут быть с разными вариантами избыточности. Даже сейчас, btrfs оперирует несколькими наборами chunks с разными настройками - системные данные, метаданные и данные это группы chunk-ов с отдельными настройками избыточности.
Место на дисках выделяется как правило в юнитах равных chunk-у. На уровне архитектуры ФС нормально относится к тому факту что на дисках будет лежать произвольная смесь chunks с той или иной степенью избыточности. Такая ситуация возможна уже сейчас - при конвертации уровней RAID на ходу будет происходить именно это. При этом данные остаются доступны, etc.
> RAID выбирается на всю файловую систему целиком. Ну или покажите нам тайные
> параметры "btrfs subvolume create"Могу показать balance, который на ходу делает restripe chunk-ов по фильтру, что демонстрирует замашки авторов. И кстати subvolume как таковой - вообще лишь очередная иерархия и не имеет ничего общего с блочным разделом. А так - да, у них пока не все что позволяет их архитектура реализовано в утилитах настройки и отдельных закоулках логики ФС.
Но даже сейчас - см. например как btrfs относится к ситуации когда есть 3 диска одинакового размера и запросили RAID1. Как это с точки зрения ФС? Раз просят RAID1 значит запись должна попасть на 2 разных девайса. В результате заняты будут все 3 девайса, а емкость будет 1.5 емкости девайса. Не очень похоже на то что мог бы сделать с 3-я дисками обычный RAID1, правда?
> LVM + любая ФС. ZFS. То о чем вы говорите не является
> каким-то нововведением.Btrfs удачнее реализует это архитектурно - см. выше, в конечном итоге архитектура позволяет раскидать на площади накопителей произвольную смесь райдов. Не говоря о рестрайпе в иной уровень без ухода в оффлайн, более полном использовании площадей дисков разного размера, рекавери только блоков которые реально выделены подо что-то, а не по всей площади и возможность проверить какая копия с райд правильная по чексуммам из ФС, при необходимости опробовав несколько вариантов чтения, etc.
LVM, ZFS - они сделаны с допущением что схема райда выбирается 1 раз и на века и не может быть разной. Мэйсон низко не летает и решил сделать интереснее. Технически оно вполне может оперировать разными уровнями райда для разных объектов. Пока это не используется в полную силу. Но дизайн позволяет.
> Мы же уже определились - одна ФС, одна схема.
Это не так. Даже прямо сейчас возможны (и практикуются) нарушения этого допущения. Например в однодисковой конфиге данные по дефолт убудут лежать как "no raid" а метаданные и системные области - "DUP" (зеркалирование путем размещения в 2 разных местах накопителя). Уже 2 разные схемы размещения. А при создании райдов и ребалансе можно это переиграть. Это пока очень базово, но это не отменяет того что дизайн может намного больше. И вот такие странности - следствие гибкого дизайна с большим запасом на перспективу.
> Она стала известна после создания ФС или изменения с последующей ребалансировкой.
Это частный субсет возможностей дизайна который реализован прямо сейчас. И даже сейчас оно вполне себе оперирует разными схемами хранения блоков. Данные, метаданные и системные блоки могут лежать в разных схемах хранения уже сейчас.
> Так что известно какую и как это согласовывается с реалиями на девайсах.
Это не так. Даже сейчас.
> Вы не поверите но все это можно сделать с помощью LVM +
> ext*/xfs/jfs/raiserjs, zfs, geom, да черт возьми даже в Windows 2000Можно. Только btrfs сможет все это регулировать пообъектно и не через ж...у. С перспективами гранулярного администрирования и неспешной перебазировки онлайн, с произвольной смесью уровней которая допускается комбинацией девайсов и свободным местом на них. Именно поэтому есть некоторые непонятки с свободным местом - в общем случае заранее неизвестно в какой схеме будут выделены следующие блоки. Поэтому нельзя сказать сколько и чего влезет.
> с помощью динамических дисков и точек повторной обработки!
А еще можно изловчиться правой пяткой почесать левое ухо. А попробуйте хотя-бы копирование с референсом (cp --reflink ...) изобразить по людски? На btrfs так можно сделать пять копий допустим виртуалки, изначально будут занимать места как 1 копия, а дальше - в зависимости от отличий. Этакий дедуп сразу на старте. А покажите такое на нтфс?
> И вот неожиданность именно Btrfs всё это знает. И свободное место и
> запрашиваемую схему.Это не так. Свободное место - знает. Схему - нет. Даже сейчас используется несколько схем которые не обязаны совпадать.
> RAID, сколько subvolums и снепшотов и df и btrfs fi df
> выводят информацию по ФАЙЛОВЫМ СИСТЕМАМ а не отдельным файлам.btrfs fi df выводит видение btrfs'ом групп chunk-ов для которых уже что-то где-то когда-то было выделено. А просто df - выводит <нечто>. Просто потому что должен что-то выводить. Я не понимаю какой физический смысл может нести единая цифирь при такой архитектуре. Легаси подходы просто не заточены на ТАКОЙ подход.
Еще есть btrfs filesystem show. Он как я понимаю показывает как раз состояние дел по девайсам. Как вы понимаете, на девайсе может и не быть chunks по всей площади, что однако не означает что нельзя создать новый chunk и заюзать его.
> Только df выводит сколько место используется и сколько свободно для ФС.
Для btrfs он выводит некую сферическую фигню в вакууме, просто потому что там надо что-то вернуть. Физический смысл этой цифири при таком дизайне мне не очевиден. А еще там между прочим есть сжатие, при том заранее неизвестно на сколько сожмется. И референс блоков (некоторые называют это дедупликацией), которые делают понятие свободного места еще более интересной величиной. Например я могу сделать кучу копий файла через reflink. При этом изначально занимаемое место близко к размеру 1 файла, независимо от числа копий (плюс-минус метаданные). А дальше зависит от фактических отличий (некоторые называют это коэффициентом дедупликации). И даже в обычных ФС есть например sparse файлы, где логическое пространство и физически занимаемое место - 2 большие разницы. По поводу чего рассказы о свободном месте и "влезет ли вон тот файл" на самом деле далеки от тривиальных. Особенно для btrfs.
> А btrfs fi df выводит такую хрень, как сколько места заюзано по
> Data, System, Metadata и не в состоянии сказать, а сколько примерно
> ещё свободного места есть в системе.Он выводит состояние по уже занятым областям накопителей которые btrfs "приватизировал" в chunk-и и расписывает какие группы chunk-ов с какой избыточностью вообще в ФС есть. Это полезно для тех кто понимает как работает btrfs-овская аллокация пространства (ну и смесь уровней избыточности). А вы видимо хотите нечто типа btrfs filesystem show...
> Конечно, сколько ФС заюзала под свои метаданные мне знать нужней
> объема свободного места.Это тоже достаточно актуальные величины для конкретно этого аллокатора. Они позволяют понимать внутреннее состояние аллокатора, чем он по факту оперирует и какое там состояние дел.
> именуете "subvolums" (вы неверно приписали это свойство btrfs).
Технически, subvolume - всего лишь "еще одна иерархия". С рядом индивидуальных настроек. Оно не имеет ничего общего с блочными разделами и прочим.
> И почему то ей доисторического сискола хватает. И она в состоянии вывести
> объем свободного места, причем правильно.Потому что там обычый архаичный подход к райдам, не имеющий ничего общего с btrfs. В btrfs все это архитектурно сделано намного интереснее. Откуда и странности с свободным местом. Потому что оно подразумевает произвольную смесь уровеней избыточности.
> И судя по вашим утверждениям о RAID на файл вы не особо хорошо знакомы
> не с внутренним устройством btrfs, ни с её практическим применением.Скорее слишком много смотрел на ее архитектуру и поэтому грань между тем что оно может архитектурно и тем что уже сделано начала размываться.
Всё красиво, а теперь надо, чтобы df выводил одну крайне простую штуку - свободное место в предположении, что никаких красот нет и всё быдет забито одним большим файлом. Если так сделать - это снимет 99% практических проблем. Потому что те, кто будет поьлзоваться вашими волшебными фичами - разберутся, как им там орудовать. А то подавляющее большинство, что не будет - получит понятное предсказуемое поведение. Опять же - задокументировать просто.Что касается меня - то я восемь раз подумаю, прежде чем закладываться на такую навороченную штуку. Когда рейд отдельно - он нормально ложится в голову, обкатан миллион раз на практике и не тащит гору нетривиального кода. А так - теперь понятно, почему ЭТО столько пишут. Надеюсь, до кого-ниббудь всё же дойдёт сделать btrlite - чтобы никаких рейдов в принципе не умела, а вела бы себя просто как приличная ФС - даже если архитектурно может больше, чтобы в коде этого не было - а значит, он был более простым, надёжным и предсказуемым.
> Всё красиво, а теперь надо...Кому надо, тот пусть и делает
> Если так сделать - это снимет 99% практических проблем.Если количество крэзи увеличится на 99%, то мужет ну его нафик так делать.
> А то подавляющее большинствоНе, точно лучше не надо это делать.
Кому "жмёт", пусть лучше чем-то другим пользуется и плачет в других форумах.
Вон айзену пусть моск канифолит например по всяким пустякам.
> - свободное место в предположении, что никаких красот нет и всё
> быдет забито одним большим файлом.Так он нечто наподобие и выводит вроде. Только это сферическая цифирь в вакууме.
> А то подавляющее большинство, что не будет
...может им проще ext4 поставить будет? Нет фич - нет проблем с ними! :)
> - получит понятное предсказуемое поведение.
Понятное? Предсказуемое? А что насчет сжатия? Заранее неизвестно насколько сожмется, поэтому то что показали и то что влезло по факту - разные вещи. Или sparse файлов? То что там написано что файл 100500 гигз - не значит что он реально занимает на физике столько. Сумма размеров файлов может люто превышать емкость стоража. А как насчет множественных референсов и CoW относительно этого? В примитивном виде нечто подобное даже в обычной ФС линками делается, при том половина софта которое явно не aware про это - норовит линки разобрать до полноценных копий файлов, со всеми вытекающими по части занимаемого ими места.
> Что касается меня - то я восемь раз подумаю, прежде чем закладываться
> на такую навороченную штуку.Я предпочитаю здравый смысл. И он говорит мне что штука обещает быть вкусной. Но для сильно ответственных применений я бы пока юзать не стал. Но в перспективе бы с точки зрения администрирования хотелось бы именно что-то такое. Потому что я не считаю хардкорный гемор присущий администрированию райдов чем-то нормальным и правильным.
> Когда рейд отдельно - он нормально ложится в голову,
В мою голову идея Мэйсона легла весьма нормально. И вообще, такой подход к райдам мне как-то импонирует намного больше. Глюки починят, а вот алгоритмы где сложности перепихнуты с разработчика на админа - так и останутся сложностями админов.
> нетривиального кода. А так - теперь понятно, почему ЭТО столько пишут.
Да, Мэйсон решил сделать настоящий next gen. Я склонен считать что по многим пунктам это у него получилось. Не везде идеально. Не везде без проблем. Но это новый набор tradeoff-ов и лично мне он вполне симпатичен.
> Надеюсь, до кого-ниббудь всё же дойдёт сделать btrlite
Пусть кому надо те и делают. ИМХО делать новый дизайн как-то так и потом кивать на архаичные классические райды - это как выкатить из произвоственного корпуса новый блестящий автомобиль. Аэродинамичный. С ксеноном. И долго матюкаться на то что неудобно пристраивать оглобли к привычной кляче.
есть 2 диска, например, на терабайт и 2 терабайта - в обычном случае вы можете из них сделать например зеркало на терабайтС помощью mdadm всю жизнь можно было сделать зеркало 1ТБ + 1ТБ в любом другом виде.
Вдобавок на надежных ФС, вылизываемых годами.
> С помощью mdadm всю жизнь можно было сделать зеркало 1ТБ + 1ТБ
> в любом другом виде.Вот только проблема в том что все это лоскутное одеяло нарезает админ, а любая реконфигурация - боль. И одномоментная кантовка кучи данных.
И да, btrfs нормально сделает зеркало и если есть например 3 диска: один на 2 Тб и 2 на 1Тб. При этом для 2Тб блоков найдутся парные устройства. А админу надо только девайсы добавить и схему хранения выбрать. Дальше голова будет болеть у аллокатора. А у вас - лоскутное одеяло должен кроить сам админ. А чуть новый девайс добавил и прочее - перекройка.
> Вдобавок на надежных ФС, вылизываемых годами.
Волков бояться - FAT12 FTW. Уж его проверили годами.
Не юзер, а системный администратор.
>если юзер допускает заполнение диска на 100%Если мне не изменяет память, то в btrfs как-раз другая ситуация. Речи о полной забивке диска речи не идет, более того - даже невозможно предсказать количество реально свободного места из-за не вполне адекватного разрастания метаданных (при некоторых видах нагрузки). Поправьте, если проблема уже не актуальна, или где наврал.
OverlayFS тупая, как полено - там ломаться нечему.
> OverlayFS тупая, как полено - там ломаться нечему.Ну так замена самосвала на мопед с аргументом "лучше вписывается в повороты и проще парковать".
Это и есть UNIX way: вместо одного самосвала, используется тысяча человек на мопедах (а лучше - самокатах).
В результате, резко возрастает надежность - поломка отдельного мопеда слабо влияет на работоспособность системы. Ну а что не оптимально немного - так пусть за оптимальностью и быстротой всякие поттеринги гоняются, раз оно им так надо.
> Это и есть UNIX way: вместо одного самосвала, используется тысяча человек на
> мопедах (а лучше - самокатах).Поэтому такие господа сливаются как только вопрос заходит о трансконтинентальных перевозках. Ведь мопеды не плавают и не летают. Ну да, главное правильно задачи под средства подбирать, а не наоборот.
> В результате, резко возрастает надежность -
Угу, изобразите мне множественные снапшоты с записью и динамически выбираемые на ходу уровня райда вашим вэем. Тогда поговорим.
> поломка отдельного мопеда слабо влияет на работоспособность системы.
Как интересно. То-есть, по вашему поломка ext4 или overlayfs мало повлияет на работоспособность системы?
> за оптимальностью и быстротой всякие поттеринги гоняются, раз оно им так надо.
Немного - это когда файлуху дико клинит при наличии снапшота, так что ей пользоваться без слез невозможно? Или когда надо небольшой райд на ...цать терабайтов разобрать? Всего полдня кантования данных - и уровень RAID изменен?
а поттер наоборот хочет все и вся завязать за свои поделки и btrfs
Хм, ведь вменяемые люди ещё 4 года назад выяснили (или, как я, безоговорочно поверили специалистам, например Э.Шишкину), что btrfs архитектурно ущербен. Однако ребята из СoreOS зная, что Btrfs сомнительная поделка, заставляли своих клиентов им пользоваться. Или не знали? Тогда вообще возникает вопрос об их профпригодности и доверию к СoreOS.
Профпригодны. Расчитывают риски и на основе результатов что-то впаривают. И так по кругу.
У инвесторов - не возникает.
> безоговорочно поверили специалистам, например Э.Шишкину),Пользуйся файловыми системами от эксперта Шишкина. Флаг тебе в руки и барабан на шею.
ZFS который не поддался плагиаторам из Linux
точно, все сходится, это бсдшники писали жалобы в CoreOS по поводу btrfs, думали ZFS выберукт и опять облом (
ZFS используют во многих ОС, а не только в BSD...Зато в Linux все как всегда - файловых систем полно, а доведенных до ума - почти ниодной :)
+100500И, что самое интересное, ситуация за 10 лет практически не изменилась.
Сантехники написали опенсорцную схд, похожую на фс, бздуны радуются, что её не включили в линуксовое ядро.
Покажите стабильно работающий аналог в Linux.BTRFS ведь совсем не торт :)
> Покажите стабильно работающий аналог в Linux.BTRFS ведь совсем не торт :)Если сравнивать только с ZFS, то Btrfs торт.
Но так как в Линуксе выбор несколько шире, можно подобрать более подходящий инструмент.
>Если сравнивать только с ZFS, то Btrfs торт.Ну, это неправда.
Насчет широкого выбора - согласен.
> Ну, это неправда.В btrfs можно подыграть базе или файлу виртуалки, отключив CoW. Там не врут про ненадобность дефрагера. И экстенты делают по людски. И памятью управляют нормально. И даже уровни RAID могут делать в произвольной смеси. А не так что 1 раз и на века hardcoded схема, а потом ничего не переделать без перестройки немеряного пула.
> Насчет широкого выбора - согласен.
Кроме всего прочего кому сильно надо - могут и ZFS использовать.
Прекрасно. А теперь прочитайте новость. Не благодарите!
> Прекрасно. А теперь прочитайте новость. Не благодарите!Почитал. И имею заметить что сдуру можно и ... сломать.
Да, ext4 может быть несколько быстрее. Но он не делает полное журналирование, снапшоты можно только где-то сбоку приделать, тормозно и урезанно. Смена уровня RAID потребует ребилдить весь пул. Ну и так далее. А так то да, мопед входит в повороты лучше самосвала.
Перестаньте онанировать на экстенты - переменный размер блока это примерно тоже. Опять же - у экстентов свои проблемы.
Назовите хоть 10 функций btrfs которых нет в zfs :)P.S. zfs отлично работает в продакшн в разных ОС, а btrfs пока еще пытается избавится от детских болезней при работе только в одной ОС :)
Ну назовите 10 ОС, в которых zfs "работает в продакшн".Зыж
Под виртуалки и контейнеры zfs подходит ещё хуже.
Или как минимум — не лучше (как минимум cow можно в бтр отключить по-файлово)
Например вот такой эпиквын — шhttp://habrahabr.ru/company/hostkey/blog/179151/
Ззыж
> которых нет в zfsНапример закрузка со снепшота. одно это 10 заменит.
гружусь со снапшота на zfs, ЧЯДНТ?
> ЧЯДНТ?Э-э-э, врёшь?
Zfs позволяет создать из снэпшота новый boot environment (ручками), но не загрузиться с любого снэпшота корневой фс.
> Назовите хоть 10 функций btrfs которых нет в zfs :)https://www.opennet.ru/openforum/vsluhforumID3/100963.html#67 - может не 10, но вам хватит.
> P.S. zfs отлично работает в продакшн в разных ОС,
Понятия о хорошем у всех разные. И кстати ZFS как-то так заметно постарше будет.
>Если сравнивать только с ZFS, то Btrfs торт.бтрку хоть с чем сравнивай - все одно эпическое она *вно. В чём центосовцы _прямо_ и пишут, мол поддались пиз****лам с форумов - перешли, теперь вылим с неё быстрее собственного визга :)
Ну а по делу ZFS - хорошая СХД, но на песюг - овекилл.
Ранше, давным давно в Линуксе была JFS которая служила верой и правдой, за ~7 лет жёсткой 24х7 експлуатации в продакшене с ней небыло проблем ... ВООБЩЕ! От слова напрочь. Но она скучная - без свисулек и колокольчиков, в линуксах еЯ забыли, там такое больше не живёт ...
>бтрку хоть с чем сравнивай - все одно эпическое она *вно. В чём центосовцы _прямо_ и пишут, мол поддались пиз****лам с форумов - перешли, теперь вылим с неё быстрее собственного визга :)Не надо утрировать. Абсолютно аналогично ZFS, она просто не годится в ФС общего назначения пока, а возможно и не будет годиться. Тем не менее юзкейсы у нее есть.
>Ну а по делу ZFS - хорошая СХД
Не знаю где и с кем ты ее сравнивал как СХД, но глядя на все эти недо-NetApp-ы с ZFS внутри, я категорически в этом сомневаюсь.
> Ранше, давным давно в Линуксе была JFS которая служила верой и правдой, за ~7 лет жёсткой 24х7 експлуатации в продакшене с ней небыло проблем.Хм. Вон xfs рядышком.
С 2007 как раз живёт например.Зыж
> бтрку хоть с чем сравнивай - все одно эпическое она *вно.Да пфу на вас и ваше мнение.
> Хм. Вон xfs рядышком.
> С 2007 как раз живёт например.Только до 2.6.28 данные нулями затирала только в путь. И с тех пор так и осталась ФС где журналятся только метаданные. И которая противно тупит на куче мелочевки (e.g. распаковка ядра линукс).
p.s.докопаться можно к любой ФС - идеальных не бывает ;)
Нули? Вы о продакшне говорите, или о чем? Или у вас на продакшне бесперебойников нет? Это, если что, единственная ситуация, где xfs могла нули нарисовать.Кстати, не тупит на мелочевке она уже с год, если не больше. Но так - да, для мелочевки и не предназаначалась. JFS зато зашибись какая "быстрая".
А полное журналирование, кстати - дурь для подваляющего большинства случаев. Потому что даже если все данные записаны на момент сбоя - это никак не гарантирует их логическую целостность. Целостность метаданных как раз и даёт возможность задействовать высокоуровневые тулзы, которые понимают, что вы там писали, и могут проверить целостность.
> Нули? Вы о продакшне говорите, или о чем? Или у вас на
> продакшне бесперебойников нет?Да-да, в тепличных условиях - любая ФС это образец надежности :). Собственно без упсы я XFS вообще не рискую использовать. Хотя это дело с нулями всех достало и вроде опосля 2.6.28 это более-менее сошло на нет.
> Это, если что, единственная ситуация, где xfs могла нули нарисовать.
А еще оно журналит только метаданные и не парится что с данными случится. Режима полного журнала нет совсем, что как бы намекает.
> Кстати, не тупит на мелочевке она уже с год, если не больше.
Где-то в свежих ядрах ее действительно подтянули в плане интенсивной работы с метаданными. Но стало вместо "уу, как все плохо" всего лишь "да ну его, что тут хорошего?". В смысле, какой-нибудь ext4 довольно сильно воткнет в таких нагрузках. Ну так, по наблюдениям. В общем файлуха под видеомонтаж и есть файлуха под видеомонтаж. Оно ничего так если распихать на несколько дисков да под большие файлы. И только.
> Но так - да, для мелочевки и не предназаначалась. JFS зато зашибись какая "быстрая".JFS слоупочный что так что сяк. По поводу чего я им и перестал пользоваться. Но на слабых машинах, где проц относительно хилый а диск относительно быстрый и все начинает упираться в проц - JFS может быть интересной опцией и даже кого-то обыграть по скорости. Главное чтобы все в проц упиралось ;). Так что не самая плохая опция для всяких малохольных мипсов и армов.
> А полное журналирование, кстати - дурь для подваляющего большинства случаев.
Не знаю кому оно "подваливает", но дурь - это когда у вас в файле оказывается половина новых данных и половина старых. После этого файл обычно напрочь неюзабелен.
> Потому что даже если все данные записаны на момент сбоя - это никак
> не гарантирует их логическую целостность.Зато обрывание записи на середине - почти гарантирует дальнейшую непригодность содержимого файла.
> Целостность метаданных как раз и даёт возможность задействовать высокоуровневые
> тулзы, которые понимают, что вы там писали, и могут проверить целостность.Ну окей, допустим у меня образовался в результате жыпег который наполовину новый и наполовину старый. Декодер жпега в середине файла поймает какую-нибудь ошибку декодирования. И? Нормальной фотографией это уже не будет являться. И никакие высокоуровневые тулзы нормальный вид этому уже не вернут.
Вот например откатить все снапшот (или просто достать из иерархии снапшота нужный файл) - это прокатит. В плане того что все вернется в вид как было на момент его создания. Но это уже не про XFS...
>Да-да, в тепличных условиях - любая ФС это образец надежности :). Собственно без упсы я XFS вообще не рискую использовать. Хотя это дело с нулями всех достало и вроде опосля 2.6.28 это более-менее сошло на нет.Не просто "более-менее сошло на нет", а сошло на нет напрочь. Во всяком случае, после этого жалоб не видел ни в интернете, ни живьём - был случай плотно полюбоваться на xfs, умирающую по причине периодических отказов диска из-за хренового БП.
>Где-то в свежих ядрах ее действительно подтянули в плане интенсивной работы с метаданными. Но стало вместо "уу, как все плохо" всего лишь "да ну его, что тут хорошего?". В смысле, какой-нибудь ext4 довольно сильно воткнет в таких нагрузках. Ну так, по наблюдениям. В общем файлуха под видеомонтаж и есть файлуха под видеомонтаж. Оно ничего так если распихать на несколько дисков да под большие файлы. И только.
Я, если что, её бенчил на этот счёт, могу данные подкинуть. там расхождение в пределах 10-20 процентов с ext4, и не всегда в пользу последней (удаление на xfs быстрее, iirc). И это был далеко не самый комфортный для xfs режим - потому что не на RAID, где она себя показывает круче всего.
>JFS слоупочный что так что сяк. По поводу чего я им и перестал пользоваться. Но на слабых машинах, где проц относительно хилый а диск относительно быстрый и все начинает упираться в проц - JFS может быть интересной опцией и даже кого-то обыграть по скорости. Главное чтобы все в проц упиралось ;). Так что не самая плохая опция для всяких малохольных мипсов и армов.
Экзотика - ну да ладно, может пригодиться. В любом случае не серверная и не десктопная ФС получается.
>Не знаю кому оно "подваливает", но дурь - это когда у вас в файле оказывается половина новых данных и половина старых. После этого файл обычно напрочь неюзабелен.Разумеется, неюзабелен. Ситуация, никак не отличающаяся от той, когда программа-писатель успела пол-файла записать (в смысле вызова write), а потом система умерла. Что, собственно, в большинстве случаев би будет происходить. Попасть в промежуток, когда write() все прошли и файл консистентен, но еще (частично) не записан на диск - это суметь надо. Опять же - на каких-то ворклоадах, может, это и частая ситуация, но так с ходу в голову ничего не приходит.
>Вот например откатить все снапшот (или просто достать из иерархии снапшота нужный файл) - это прокатит. В плане того что все вернется в вид как было на момент его создания. Но это уже не про XFS...Дык. И это не про журналирование вообще. Снапшоты - штука хорошая, не спорю. Хотя, опять же, если софт не закладывается на их существование (а он и не должен) то старого доброго "переименовал - создал новое - прибил старое" достаточно, если, конечно, система каждый час не падает. Но да - согласен, снапшоты на уровне ФС - приятно и удобно.
> Не просто "более-менее сошло на нет", а сошло на нет напрочь.Это отлично, но сколько лет это чинили? Да и из интересного в XFS разве что структура при которой оно хорошо работает на нескольких дисках с большими файлами. В остальном ФС как ФС, без каких-то гигантских преимуществ.
> Во всяком случае, после этого жалоб не видел ни в интернете, ни
> живьём - был случай плотно полюбоваться на xfs, умирающую по причине
> периодических отказов диска из-за хренового БП.Мне тоже после 2.6.28 такое не попадалось - наверное более-менее дожали.
> расхождение в пределах 10-20 процентов с ext4, и не всегда в
> пользу последней (удаление на xfs быстрее, iirc).У меня до сих пор есть несколько томов в XFS и мне в целом не особо нравится как они работают. Если не лениво - попробуй забенчить например получение полной иерархии (обход директорий и получение списка файлов) на холодную для ext4 и xfs.
Это разумеется надо делать на холодную для каждой ФС (записали файлы - ребут - обход иерархии) и никуда не выводить весь список (чтобы IO и рендеринг от большого списка нигде не клинило). Есть ощущение что xfs на холодную как-то довольно неспешно делает обход vs остальные. Очевидный юзкейс где это может анноить - поиск по вилдкардам в mc, например. На горячую конечно все шустро, но это не заслуга ФС.
> RAID, где она себя показывает круче всего.
Ну да, он с его allocation groups заточен на то чтобы его на несколько дисков раскладывали. Если охота работать с большими файлами и на RAID - вариант. Но это как-то не мои типовые юзкейсы. А например как оно выдерживает несколько иерархий линуксного кернела мне не нравится - на холодную оглавление как-то долго обходится.
> Экзотика - ну да ладно, может пригодиться. В любом случае не серверная
> и не десктопная ФС получается.Еще не врут про неубиваемость (насколько это понятие применимо для классики с журналом только метаданных). Но в остальном - серая мышка. Единственное разумное что приходит - ФС для винча прицепленного к роутеру со слабым процом и подобные странноватые применения.
> успела пол-файла записать (в смысле вызова write), а потом система умерла.
Если программа не атомарно пишет файл и потом не может это прочитать - это продолб программы и за это спрос с авторов. А если прога сделала 1 большой write на весь файл и файлуха при этом сделала ни два ни полтора - это уже предъявы к файлухе.
> Что, собственно, в большинстве случаев би будет происходить. Попасть в
> промежуток, когда write() все прошли и файл консистентен, но еще (частично)
> не записан на диск - это суметь надо.По идее достаточно сделать 1 большой write() со стороны программы, переписывающий весь файл или его заметный кусок, а потом нарваться на крах, когда это стало по факту выдавливаться на блины? В результате получится файл который ни туда ни сюда. Хотя программа со своей стороны все нормально сделала. Если не считать нормальным адские костылищи, типа записи в темпарь и ренейм, что почем зря гадит фрагментацией и заметно усложняет код. И является гнусным хаком для компенсации непотребного поведения ФС на уровне приложений. Хотя по идее им бы вообще про журналирование знать не следовало.
> Дык. И это не про журналирование вообще.
Снапшоты как таковые в нормальном виде - некое логическое доразвитие неразрушающего однократного журналирования (CoW и все что подобное по смыслу). Их можно конечно делать и иначе, но получается дрянь. В случае CoW все необходимое для снапшота - уже есть, а сама механика подразумевает легкое и беспроблемное обеспечение сохранности снапшота. Это, в паре с скоростью записи близкой к скорости совсем без журнала, при эффекте близком к полному журналированию настолько жирный и очевидный плюс что большинство новых дизайнов ФС - пытаются делать как-то вот так в основном. Бонусом такие дизайны лучше для флешовых носителей - read-patch-write со стороны фс они не любят, поскольку очень маловероятно что это совпадет с блоками флеша и в результате получится усиление протирания флеша.
> (а он и не должен) то старого доброго "переименовал - создал
> новое - прибил старое" достаточно,Со своей стороны я считаю это у...щным application layer костылем недожурналу. Этот подход должен умереть - программы не должны делать работу ФС без сильной причины. Я знаю только 2 сильные причины: БД и CoW диски виртуалок, которые могут иметь какие-то свои очень кастомные пожелания по поводу того чтобы ФС была для них почти интерфейсом к блочному уровню, с минимумом помех. Чисто блочные девайсы лучше - но их неудобно админить.
> Но да - согласен, снапшоты на уровне ФС - приятно и удобно.
Бонусом я еще считаю крайне у..щным когда программы вынуждены заниматься левым oнaнизмoм усложняющих их код, для компенсации неспособности ФС нормально журналировать.
> Ранше, давным давно в Линуксе была JFS которая служила верой и правдой,Только журнал, как обычно только метаданных. И скорость работы довольно хилая. А так ФС как ФС. Но какой-то смысл имеет только на конфигах с слабым процом - ресурсы кушает очень скромно.
> проблем ... ВООБЩЕ!
А жесткая эксплуатация включала слеты питания, ребуты и кернелпаники? Или в чем жесткость состояла?
> Ну а по делу ZFS - хорошая СХД, но на песюг - овекилл.
А мне вот и btrfs даже на нотике ничего так. Снапшоты штука хорошая. И в отличие от всяких LVM они просто и быстро делаются и потом не тормозят всю файлуху. А некие фичи СХД не так уж плохо смотрятся на десктопнике с кучей хардов. Возможность добавить +1 хард при недостатке места без перетрясок данных терабайтами - очень мило.
btrfs збс пока не начинает рассыпаться
> btrfs збс пока не начинает рассыпатьсяЭто же верно для любой ФС. А у бтрфс на крайний случае есть неразрушающая "читалка" позволяющая цепляться к остаткам структур и выцеплять файлы без риска все испортить еще сильнее. Какие-то аналоги этого я видел разве что в паре коммерческих утилей для фат и нтфс.
А так у меня бтрфс есть на некоторых машинах. Некоторые уже с полгода наверное пользуются оной. Вроде не рассыпается. Не буду утверждать что это хардкорный тест на убиение, с зашкаливащей нагрузкой и тыканием в краевые условия типа окончания места каждые 5 минут или пулы с 100500 дисков, но все-таки.
> А так у меня бтрфс есть на некоторых машинах. Некоторые уже с
> полгода наверное пользуются оной. Вроде не рассыпается.С какой периодичностью вы запускаете утилиту верификации данных на ФС? (по типу scrub)
> С какой периодичностью вы запускаете утилиту верификации данных на ФС? (по типу scrub)Как правило - примерно раз в месяц. И нет, ошибок не обнаруживалось. Но это на грани test flight и неответственного продакшна. В системах с btrfs используются свежие ядра. Наверное поэтому все оки-доки.
Для ext2 такое добро точно есть, в репах дебиана лежит. Даже пользовался как-то. На тот момент (а было это года 4 назад) работало для ext2/3, для ext4 не пахало. дальше не копал, так как вытаскивать надо было с ext3.Ну и из общих соображений - чем сложнее труктуры данных тем больше проблем что-то из них вытащить в нештатной ситуации и тем больше шансов на эту самую ситуацию нарваться. В том числе поэтому там, где можно обойтись простой ФС - надо ей обходиться. Это, если что, безотносительно btrfs - так, общий принцип. Вполне верю, что её в плане востстановления сделали достойно и сам код довели до приличного уровня стабильности.
> вытаскивать надо было с ext3.Я забыл что такое ext3. Его производительность на фоне ext4 - ни о чем.
> проблем что-то из них вытащить в нештатной ситуации и тем больше
> шансов на эту самую ситуацию нарваться.В принципе все это так, но лажа случается везде а спецутиля для этого самого, готовая к такому обороту в явном виде - лучше чем самому в хексэдиторе пыхтеть, знаете ли.
> где можно обойтись простой ФС - надо ей обходиться.
Надо? Обходитесь. Берите FAT и радуйтесь простоте. А я как-то так несколько раз налетал на перезаписывание куска иерархии и терял данные именно по этому поводу. Раскатав относительно старый бэкап при отсутствии более нового, например. Или переписав вон тот файл более старым. Бэкап в целом достаточно длинная и затратная операция и часто ее делать не будешь. А снапшот - можно. В CoW все есть для его создания - снапшот это лишь некая довольно формальная пометка. Это не занимает много времени и ресурсов само по себе. Мне это нравится. Я привык к этому на VM и считаю что настает время сделать мне столь же удобно и на железных хостах.
Как по мне - выбор ФС сложный и многофакторный процесс, без единого универсального критерия. Есть некие задачи и пожелания. Есть разные ФС. И простота ФС - да, это некий плюсик. Но в целом мое время стоит дорого и у меня есть ряд более интересных вещей чем занятие патологоанатомией с хексэдитором в останках ФС. Поэтому мной прото будет предпринят ряд мер которые не требуют много моего времени но позволяют восстановить в случае аварии большинство данных без такого хардкора. Это сэкономит мне кучу времени.
> в плане востстановления сделали достойно и сам код довели до приличного
> уровня стабильности.Просто как-то радует подход. Судя по списку рассылки - те кто доигрывался до совсем убитой ФС как правило отколупывали этими утилитами наиболее ценные данные и при своем все-таки обычно оставались. Что довольно неплохо на мой вкус. И с точки зрения дата рекавери мне недеструктивное чтение наиболее симпатично - при этом надо только дисковую емкость под спасаемые файлы и не надо места под образ и отпадает длительная операция снятия образа. Потому что нет шанса напортачить. Хотя если проблема в самом носителе - там конечно лучше образ сделать штуками типа myrescue, чтобы накопитель не сдох в процессе восстановления. Но тут уж здравый смысл никто не отменял.
Ну, что было (ext3) - то и вытаскивал. Там, где она жила, скорость диска вообще роли не играла, даже не заню, с каких времен она там жила. Я к тому, что не стоит приводить тулзу для btrfs как что-то экстраординарное. Навскидку в сети нашлись проги и для ext4, и для xfs на эту тему. Так что про время и хексэдитор - не надо.И да, если у тебя три десятка файлов, которые пишутся раз в три года - можно и FAT взять, или ext2, которую многие до сих пор любят юзать для /boot. А снапшоты... где они нужны, где нет. Что-то сомнительно мне, что в /tmp нужны снапшоты. Да и в большинстве других случаев "снапшот" делается переименованием изменяемого директория на *.backup, если места хватает, конечно. Но его почти всегда хватает.
Я не спорю, что у btrfs прикольный дизайн и, возможно, крутая реализация. Но в результате имеем сложную штуковину, до сих пор не "благословлённую" для продакшна как те же ext*, xfs или, упаси шайтан, FAT.
> Ну, что было (ext3) - то и вытаскивал.Со своей стороны могу похвалить ext-ы за неплохой fsck - обычно удается догнать до моунтабельного состояния и вынуть данные штатно.
> тулзу для btrfs как что-то экстраординарное.
Таких утилит не слишком много.
> Навскидку в сети нашлись проги и для ext4, и для xfs на эту тему.
И все-таки штатная утилита такого плана прямо от авторов ФС - это очень симпатично придумано и я склонен считать это ощутимым достоинством пакета утилит к ФС.
> Так что про время и хексэдитор - не надо.
Возможно. Но у btrfs такая утиля идет сразу в комплекте и если она даст маху - про нее можно спросить у тех кто делал ФС. Т.е. тех кто в своей ФС лучше всего и разбирается как раз.
> И да, если у тебя три десятка файлов, которые пишутся раз в
> три года - можно и FAT взять,Можно. Но у меня обычно больше файлов, мне не фиолетово с какой скоростью это будет работать, я не считаю что меня устраивают ограничения по иерархиям и размерам и хотелось бы чтобы на случай продолбов был откат. В ряде случаев я бы не отказался от прозрачной расширяемости по принципу доткнул диск - получил место. И возможности гибко переиграть. Понятно что без ряда возможностей можно прожить. Но так в принципе можно прожить и без электричества...
> или ext2, которую многие до сих пор любят юзать для /boot.
Я в общем случае не считаю нужным городить лоскутное одеяло из кучи разделов. Если загрузка с физически отдельного носителя - я еще это понимаю. Но там обычно вся система. А какую самоценность представляет лысый бутлоадер без ОС?
> А снапшоты... где они нужны, где нет. Что-то сомнительно мне, что в /tmp нужны снапшоты.
Ну так необязательно делать /tmp со снапшотами. Хотя тут тоже очень зависит от софта и прочего.
> Да и в большинстве других случаев "снапшот" делается переименованием
> изменяемого директория на *.backup, если места хватает, конечно. Но его почти
> всегда хватает.Вот только копирование разлапистых иерархий может занимать ощутимо времени. Снапшот делается условно-мгновенно, поскольку ничего никуда не копирует. А просто ставит некие метки и потом изменения в этой иерархии будут идти относительно вот этого вот. Мне это как-то кажется разумным и логичным. Я привык к этой механике в виртуализаторах, где cow based диски виртуалок - норма жизни. И считаю что на железках мне это тоже хочется.
> для продакшна как те же ext*, xfs или, упаси шайтан, FAT.
Вообще-то по мнению разработчиков - уже можно юзать со свежими ядрами. Ну кроме RAID5/6. Этому же мнению вторили и фуджики, при том они вообще куда-то в ответственные применения метят и потому явно будут пинать причастных и сами подпрягутся остатки закидонов вылавливать. А так я вижу довольно много интересных заделов на будущее в таком дизайне и склонен считать это еще на поколение опосля ZFS. Этакий CoW сделанный с оглядкой на современные продакшны и их проблемы.
> чём центосовцы _прямо_ и пишут,Какие центосовцы? В новости про CoreOS. Это весьма нишевая и своеобразная операционка с весьма своеобразными задачами.
> мол поддались пиз****лам с форумов -
Пиз****лы с форумов похоже не различают CentOS и CoreOS в своих приступах понoса...
zfs в линуксе достаточно стабильно работает для показывания?
Приемлемо.Есть определённые грабли, но есть и хорошее средство защиты от них: при создании ZFS-пула просто сказать "-o version=28".
> ZFS используют во многих ОС, а не только в BSD...
> Зато в Linux все как всегда - файловых систем полно, а доведенных
> до ума - почти ниодной :)Ну, и покажи что-то надёжнее семейства ext*, особенно ext4!
Ищи во всех ОС и неОС.Из неродных, как родная работают jfs, zfs.
>> ZFS используют во многих ОС, а не только в BSD...
>> Зато в Linux все как всегда - файловых систем полно, а доведенных
>> до ума - почти ниодной :)
> Ну, и покажи что-то надёжнее семейства ext*, особенно ext4!
> Ищи во всех ОС и неОС.
> Из неродных, как родная работают jfs, zfs.ext4 уже научилась хотя-бы делать snapshot`ы?
btrfs начали лепить со стыда перед возможностями zfs )))
Снэпшоты есть в снэпшотных ФС, а не экстентных.
> Снэпшоты есть в снэпшотных ФС, а не экстентных.А бтрфс использует экстенты и умеет снапшоты. Ы?
>>> ZFS используют во многих ОС, а не только в BSD...
>>> Зато в Linux все как всегда - файловых систем полно, а доведенных
>>> до ума - почти ниодной :)
>> Ну, и покажи что-то надёжнее семейства ext*, особенно ext4!
>> Ищи во всех ОС и неОС.
>> Из неродных, как родная работают jfs, zfs.
> ext4 уже научилась хотя-бы делать snapshot`ы?Снапшоты при помощи костылей может делать и ext3 -проект ext3cow .Читал про такой же проект и для ext4 ,вроде в какие то ветку Аллана падчи даже и включены ,почему падчи не принемают в основную ветку не знаю .
> ,почему падчи не принемают в основную ветку не знаю .Потому что нафиг никому не упало делать из запорожца аэроплан, когда под боком есть аэродром с нормальным самолетом.
NTFS. не троллю, серьёзно.
> NTFS. не троллю, серьёзно.Курам на смех, и что характерно - тоэе не троллю, тоэе - серьёзно. :)
> NTFS. не троллю, серьёзно.Дисковые технологии ранних девяностых. С соответствующими скоростями работы и костылями.
В чем разница? Когда у меня на btrfs лежит кучка снапшотов я даже не задумываюсь что они есть. Когда на NTFS делается снапшот - всю систему клинит нафиг.
>> NTFS. не троллю, серьёзно.
> Дисковые технологии ранних девяностых. С соответствующими скоростями работы и костылями.
> В чем разница? Когда у меня на btrfs лежит кучка снапшотов я
> даже не задумываюсь что они есть. Когда на NTFS делается снапшот
> - всю систему клинит нафиг.Сынок, может, ты asyncIO просто не знаешь, где включается?
>Сынок, может, ты asyncIO просто не знаешь, где включается?Сынок а ты не хочешь озвучить с какой форточки это стало доступно ? :-)
И самое главное - насколько это помогло :))))
> Сынок, может, ты asyncIO просто не знаешь, где включается?Не отменяет того факта что в случае нтфс файлуха при снапшотировании истошно тормозит, дяденька. И если файлуха тормозит - там хоть синхронный io, хоть асинхронный. Стоять колом он будет одинаково. И нет, я не считаю что все это должно работать настолько погано...
> ZFS используют во многих ОС, а не только в BSD...
> Зато в Linux все как всегда - файловых систем полно, а доведенных
> до ума - почти ниодной :)и не только файловых систем...
> и не только файловых систем...Только почему-то мегаконцептуальные системы вообще взлететь не могут, академичные бзды отовсюду повылетали, etc. При том заслуженно. Потому что когда господа делают убер-мега-слой журналирования которым потом пользуется аж целый гунявый UFS, который доброго слова не стоит ни так ни эдак - это просаживание кучи времени в унитаз.
> а доведенных до ума - почти ниодной :)jfs, xfs, reiser3, не? я не возражаю, что во фряхе есть и толковая ZFS, и геом прекрасен, но "ни одной" в Линуксе - это перебор, не находишь? и лично я бы не отказался от xfs на фряхе, например.
Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхи (Разве что с ядром не идёт одним тарболом).
И пишут (если можно так назвать процесс без участия ораклп) её уже года 2 совместно. Более того, линуксоиды даже больше остальных.
> Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхи (Разве
> что с ядром не идёт одним тарболом).
> И пишут (если можно так назвать процесс без участия ораклп) её уже
> года 2 совместно. Более того, линуксоиды даже больше остальных.Можно взглянуть на выхлоп линуксового "zpool upgrade -v"?
ровно такой же, как в бзд релиз.
Да, писюн в бзде карент и стэбл длиннее. А поддержка lz4 например в линухе была раньше.
И что? Что ты этим хотел доказать?"Родственность" определяется использованием (и в линухе, и в бзде) spl (Solaris Porting Layer) — эдакий вайн, но вместо вантуза — соляра. Так что, "родственник", гони рубль. Мне Афоня рубль должен. И ещё не факт, в силу тех или иных причин, в какой системе будет работать надёжнее, быстрее и тд.
В линухе работы только чуть больше, потому что начали позже. Поэтому и пилят сейчас больше.
А когда дойдут до предела вываленных ораклом сырцов, так все и встанут.
Вот такой вот вендор-лок'с. (Есть вариант пилить дальше, наплевав на совместимость. Весело короче)
> ровно такой же, как в бзд релиз.
> Да, писюн в бзде карент и стэбл длиннее. А поддержка lz4 например
> в линухе была раньше.Что, есть документальные подтверждения этого?
У FreeBSD есть: http://svnweb.freebsd.org/base?view=revision&sortby=date&rev...
> И что? Что ты этим хотел доказать?
То, что линукс с поддержкой ZFS всё-таки позади.
Тогда повторяю ещё раз фразу, на которую ты выдал этот спич:
> Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхиА какой там актуальный номер стабильной (критерии стабильности где? ещё раз в бсд-релиз точно такая же, что и в лине) версии — не имеет никакого значения.
Всё. Занавес.Зыж
Другое дело, что линуксоиды понимают, что эта фс с вендор-локом — инородное тело. Было, есть и будет. Причём и для линуха, и для бсд.
А бсдишнеги (вернее конкретно ты. чего это я обобщаю то?) делают вид, что не понимают.
> Тогда повторяю ещё раз фразу, на которую ты выдал этот спич:
>> Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхиБолее новая версия ZFS не прочитается в ОС, которая не поддерживает новых фич.
> А какой там актуальный номер стабильной (критерии стабильности где? ещё раз в
> бсд-релиз точно такая же, что и в лине) версии — не
> имеет никакого значения.
> Всё. Занавес.Так какая версия в линуксе? "zpool upgrade -v" что говорит?
> Зыж
> Другое дело, что линуксоиды понимают, что эта фс с вендор-локом — инородное
> тело. Было, есть и будет. Причём и для линуха, и для
> бсд.
> А бсдишнеги (вернее конкретно ты. чего это я обобщаю то?) делают вид,
> что не понимают.Лично я не вижу в ZFS никакого vendor lock-in, так как версии ZFS от Oracle и Illumos давно несовместимы и развиваются параллельными ветками. А тот код ZFS, который используется на FreeBSD, открыт под CDDL - признанной свободной Open Source лицензией.
"CDDL несовместима с лицензией GPL. Это происходит из-за того, что GPL требует удаления всех лицензий и применения GPL вместо них, в то время как CDDL запрещает это."
> Более новая версия ZFS не прочитается в ОС, которая не поддерживает новых фич.Именно. Например с соляры на бзд. На любой бзде. (Что там с шифрацией?) Что на линухе не можешь, что на бзде (о чём я и говорил).
И? Каков диагноз?> Лично я не вижу в ZFS никакого vendor lock-in, так как версии ZFS от Oracle и Illumos давно несовместимы и развиваются параллельными ветками.
Апофиоз мaрaзма. Ты себе так зaсpaл свой мозг своим же фанатизмом, что даже признавая тот факт, что это по существу уже разные фс, продолжаешь гнать пypгу про какую-то исключительную поддержку zfs в бзде.
> А тот код ZFS, который используется на FreeBSD, открыт под CDDL - признанной свободной Open Source лицензией.Да-да. А сша — демократическая страна. И вполне по демократически уничтожила 1,2 миллиона мирных жителей Ирака. А теперь демократически признала, что Ирак к 11 сентября не имел никакого отношения.
Ещё раз — zfs для линукса такая же "родная", как и для бзд. Ну допишут эти фьючерсы рано или поздно (добавят пару мелочей, вида lz4, не более), а дальше — обоим ждать гумманитарных бомбардировок от оракла.
>> Более новая версия ZFS не прочитается в ОС, которая не поддерживает новых фич.
> Именно. Например с соляры на бзд. На любой бзде. (Что там с
> шифрацией?)ZFS поверх GEOM ELI или BDE — отлаженные решения.
> Что на линухе не можешь, что на бзде (о чём я и говорил).
> И? Каков диагноз?Диагноз: на линуксе всё гораздо сложнее, чем на фре.
> Диагноз: на линуксе всё гораздо сложнее, чем на фре.Какой нахальный подгон решения под ответ от пользователя putty.exe. Ишь, шалунишка.
>> А поддержка lz4 например в линухе была раньше.
> Что, есть документальные подтверждения этого?айзен, ты в курсе что это так (отмечался в новости про это тут, на опеннете)
но если твой фанатизм блокирует твой мозк, то могу напомнить:
>illumos Jan 2013
>FreeBSD Feb 2013
>ZFS on Linux Jan 2013
>OpenZFS on OS X Jan 2013
> ZFS который не поддался плагиаторам из LinuxСлова вантузятнега. Эталонные. Сферические и в вакууме.
>> ZFS который не поддался плагиаторам из Linux
> Слова вантузятнега. Эталонные. Сферические и в вакууме.Ух ты! Во это аргумент! А что же с вашей точки зрения случилось с поделкой под названием btrfs которая собиралась догнать и перегнать zfs, а сейчас отправляется на свалку истории?
Батхерт пользователя putty.exe засчитан.
> ZFS который не поддался плагиаторам из LinuxЗато поддается плагиаторами из FreeBSD )))
>> ZFS который не поддался плагиаторам из Linux
> Зато поддается плагиаторами из FreeBSD )))Дык! Resistance is futile, you will be assimilated. :)
> Дык! Resistance is futile, you will be assimilated. :)Да, вы правильно поняли - вам придется мимикрировать под Linux :)
очевидный шаг, поздравляю разработчиков с очередным проявлением здравого смысла в мире обезумевшего от бизнеса микрософта (редхета)
> Выбор в пользу OverlayFSтеперь я знаю за какую ФС будут холиварить линуксоиды, а btrfs который был хорош и давно готов для продакшена, уже не надо
Что-то мне материал по ссылке "низкой производительности" кажется весьма сомнительным. Я такого могу наклепать сколько угодно относительно чего угодно и "доказать" что угодно.Есть другие источники говорящие о низкой производительности btrfs?
Также неплохо бы пруфы относительно "ошибки при исчерпании свободного дискового пространства".
Согласен, нужны тесты и цифры и желательно у себя их еще прогнать, а это так мазня для детей, нарисовали график и рады...
> Согласен, нужны тесты и цифры и желательно у себя их еще прогнать,
> а это так мазня для детей, нарисовали график и рады...Точно! Кто такие эти центосовцы против целого Васи?!?!?
Правду они сказали. Не стали прогибаться как демьяновцы под политический момент, а сказали неприятную праву. Теперь у публики лопнет пердак, а эту команду красношляпые попрут вон из команды. А то ведь неровён час они и подЦeD из системы тоже выкинут :-\
> Точно! Кто такие эти центосовцы против целого Васи?!?!?При чем здесь центос?
> Правду они сказали.
Где факты, доказывающие? Без фактов это и есть политическое решение - вот тебе и неприятная правда.
> Точно! Кто такие эти центосовцы против целого Васи?!?!?Какие центосовцы? В сабже про Core OS, которому без году неделя.
> красношляпые попрут вон из команды.
Вот это я понимаю - честное и совсем не ангажированное мнение. В новости про какой-то CoreOS нам рассказали про редхат, политику и что там еще. Осталось только придумать при чем тут они. И, кстати, редхат никогда и не был основным локомотивом стоящим за btrfs. Там в основном оракл, а потом фуджики и фэйсбук упираются. Еще IBM некое отношение к появлению этой штуки имеет.
Но если хочется полить линуксы гуано (то что анонимаус соплярщик с батхертом по понятному поводу - достаточно известный факт) - на это можно не обращать внимание.
Хаха. Сколько мы слышали хвалебных од про btrfs! И про есть и про будет. А результат то, как говориться - "на лице" :)
Ну как только ZFS допилят на линь, сразу увидим продолжение истории с переездом туда.
год назад поднимал. Убунта и зфс. Работает, доволен. ЧЯДНТ?
FUSE?
Native, даже HOWTO есть.Правда, если на современных платформах, то GRUB надо пересобирать, потому что, например, в openSUSE он не собран с поддержкой ZFS статически, а insmod вырублен, если включен Secure Boot (что логично).
> FUSE?Хотите - можно и фузю, но мена модуль ведра устраивает. Быстрее всё-таки.
> ЧЯДНТ?- Не следишь за используемыми ресурсами и/или не заботишься о скорости работы
- Не думаешь о людях, у которых 32bit система
- Скорее всего (но это ты расскажи) не используешь zfs на рутовой партиции (точнее на той, на которой /boot), или лишний раз усложняешь себе жизнь не получая профита, или поведай какие уникальные фичи zfs ты используешь?
> - Не следишь за используемыми ресурсами и/или не заботишься о скорости работыА зачем? ZFS следит за распределением ОЗУ сама.
> - Не думаешь о людях, у которых 32bit система
А также о людях, у которых 80286. :)
Впрочем, на FreeBSD ZFS работает и на 32-разрядном ядре.
> - Скорее всего (но это ты расскажи) не используешь zfs на рутовой партиции (точнее на
> той, на которой /boot), или лишний раз усложняешь себе жизнь не получая профита, или
> поведай какие уникальные фичи zfs ты используешь?Какой-такой /boot ещё?
host:~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
rpool/BE/openSUSE_13_2 194798592 4621824 190176768 3% /
devtmpfs 1983780 8 1983772 1% /dev
tmpfs 1991156 76 1991080 1% /dev/shm
tmpfs 1991156 1300 1989856 1% /run
tmpfs 1991156 0 1991156 0% /sys/fs/cgroup
/dev/sda2 262144 108904 153240 42% /boot/efi
rpool/home 190176896 128 190176768 1% /home
rpool/home/user 190317440 140672 190176768 1% /home/user
rpool 190176896 128 190176768 1% /rpool
rpool/BE/openSUSE_13_2/var 190392192 215424 190176768 1% /var
rpool/BE/openSUSE_13_2/var/lib 190213760 36992 190176768 1% /var/lib
rpool/BE/openSUSE_13_2/var/log 190255488 78720 190176768 1% /var/log
rpool/BE/openSUSE_13_2/var/tmp 190366080 189312 190176768 1% /var/tmp
host:~ #Зачем он вообще нужен?
P.S: GRUB слегка пропатчен (ибо его мэйнтейнеры не любят тестировать программное обеспечение, которое пишут) и пересобран стандартным rpmbuild -bb в присутствии libzfs.
> А зачем? ZFS следит за распределением ОЗУ сама.Да, особенно в ARC, только это с ядром не интегрировано. Поэтому когда в системе наступает душняк с памятью - совсем не факт что память удастся выкроить за счет кэша.
> Да, особенно в ARC, только это с ядром не интегрировано.Особенно с ядром Соляриса. :)
> Особенно с ядром Соляриса. :)А с ядром соляриса - придется выкраивать чемодан бабла для оракла. И рты для ублажения вендорлокера. Театры одного актера заканчиваются как-то так.
> А зачем? ZFS следит за распределением ОЗУ сама.Сравни потребление памяти при использовании zfs, и с другими ФС. Да, при условии, что ты достигнешь сходной скорости работы.
> А также о людях, у которых 80286. :)
Людей, у которых 32-битная архитектура несравнимо больше, чем тех, у которых 80286.
> Какой-такой /boot ещё?
Обеспечение загрузки с zfs не такое тривиальное, как, скажем, с ext4 или reiserfs. Мне было интересно, грузишься ли ты с zfs или нет. Грузишься. Ок. Теперь ответь на вопрос, ради чего все это было нужно. Какие уникальные фичи zfs ты РЕАЛЬНО используешь на практике.
>> А зачем? ZFS следит за распределением ОЗУ сама.
> Сравни потребление памяти при использовании zfs, и с другими ФС. Да, при условии,
> что ты достигнешь сходной скорости работы.ZFS по скорости работы просто не с чем сравнивать.
BtrFS неработоспособна, а остальные файловые системы просто не умеют того, что умеет ZFS.
Да, и мы, конечно, помним, что one can be arbitrarily fast if data integrity is not a question.
А по ОЗУ -- 0 байт в свопе, 780 Мб физики свободно.KDE.
>> А также о людях, у которых 80286. :)
> Людей, у которых 32-битная архитектура несравнимо больше, чем тех, у которых 80286.Intel Atom, что ли?
Что за последние пять лет было выпущено, что бы не поддерживало 64 бита?>> Какой-такой /boot ещё?
> Обеспечение загрузки с zfs не такое тривиальное, как, скажем, с ext4 или reiserfs.Пересобрать GRUB, запустить mkinitrd. Всё.
Весь код для dracut'а устанавливает ZFS.
> Мне было интересно, грузишься ли ты с zfs или нет. Грузишься. Ок.
> Теперь ответь на вопрос, ради чего все это было нужно.
> Какие уникальные фичи zfs ты РЕАЛЬНО используешь на практике.1. Сквозную проверку целостности данных.
2. copies=3 на домашнюю директорию.Для ноута самое то.
> ZFS по скорости работы просто не с чем сравнивать.Изен уже показал нам чего можно получить в ZFS :)
> BtrFS неработоспособна, а остальные файловые системы просто не умеют того,
> что умеет ZFS.Очередное мнение от эксперта, который этот btrfs в глаза не видел, но мнение имеет.
> А по ОЗУ -- 0 байт в свопе, 780 Мб физики свободно.
> KDE.Шиза косила наши ряды - сферические 780 мегов в вакууме. С кедами.
> 1. Сквозную проверку целостности данных.
> 2. copies=3 на домашнюю директорию.Ты так говоришь как будто это не делается в btrfs :)
> Для ноута самое то.
Странно что мсье не пришло в бошку использовать для начала хотя-бы снапшоты. Чтобы в случае если что-то пошло не так - иметь возможность отмотать назад за несколько секунд.
>> ZFS по скорости работы просто не с чем сравнивать.
> Изен уже показал нам чего можно получить в ZFS :)Throughput 951.964 MB/sec 4 procs
На ноутбучном харде. Мне хватает гигабайта в секунду пока. :)
>> BtrFS неработоспособна, а остальные файловые системы просто не умеют того,
>> что умеет ZFS.
> Очередное мнение от эксперта, который этот btrfs в глаза не видел, но мнение имеет.Очередной бред от "телепата", который почему-то решил, что он знает, кто что в глаза видел.
>> А по ОЗУ -- 0 байт в свопе, 780 Мб физики свободно.
>> KDE.
> Шиза косила наши ряды - сферические 780 мегов в вакууме. С кедами.Вызови себе психиатра, если твои ряды косит шиза.
Свежезагруженные кеды + Firefox на стандартных 4 ГБ ОЗУ.
>> 1. Сквозную проверку целостности данных.
>> 2. copies=3 на домашнюю директорию.
> Ты так говоришь как будто это не делается в btrfs :)Нет, не делается. Поизучай внутреннюю структуру BtrFS.
>> Для ноута самое то.
> Странно что мсье не пришло в бошку использовать для начала хотя-бы снапшоты.
> Чтобы в случае если что-то пошло не так - иметь возможность отмотать назад
> за несколько секунд.Ты, по-моему, не понимаешь, от чего защищают снапшоты, а от чего -- copies.
Это про разное.
> Throughput 951.964 MB/sec 4 procsКруто, к сферическим мегабайтам памяти в вакууме добавился сферический почти гиг в вакууме.
> На ноутбучном харде. Мне хватает гигабайта в секунду пока. :)
Единственная заковывка - ноутбучный хард даже на уровне физики с такой скоростью не пишет. Что показывает что нам втирают очки. Показывая какой-нибудь cache hit, для которого гиг в секунду - не больно то и дофига.
Глядя на такой ...дец - прямо хоть квест-комикс в формате ace attorney делай, с делом zfs vs btrfs :). Наверное могло бы получиться довольно эпично, в свете неаккуратных заявлений.
> Очередной бред от "телепата", который почему-то решил, что он знает, кто что в глаза видел.
Это заметно по уровню понимания работы ФС. Если видел - ну ок, тем хуже - тогда обнаружено махровейшее ламерство. Тоже вариант :)
>> Шиза косила наши ряды - сферические 780 мегов в вакууме. С кедами.
> Вызови себе психиатра, если твои ряды косит шиза.Так это не я шизанулся - писать про какие-то 768 мегов, без указания конфиги и почему-то мнить что это очень хорошо.
> Свежезагруженные кеды + Firefox на стандартных 4 ГБ ОЗУ.
Осталось уточнить про то что если всю память при этом скушать приложениями - мы явно не получим тех 954 Мб в секунду. Особенно на ноутбучном диске. Кого вы пытаетесь на..ть? Меня? А зачем? Я более-менее понимаю как это работает и такой номер не пройдет. Себя? Это вообще бессмысленно и беспощадно.
Правда жизни - в том что дизайн ZFS без подпирания гигазами рамы тормознут. Я не вижу с фига ли этому странному блочному дизайну быть быстрым. А если эти гигазы выкроить - совсем не факт что их потом при нужде сможет забрать ядро когда это понадобится программам, потому что все это живет вообще отдельно от управления памятью ядра. Еще веселее CoW без дефрагера. Не, ну если диски вовремя дотыкать в пул - в продакшновом пуле можно и избежать крутого штопора. Но на ноуте новые диски втыкать некуда - придется трястись как кощею над местом на диске. Ведь если оно начнет зашкаливать за 70% - аллокатор наделает вермишели, а линеризовать эти макароны потом не выйдет - за отсутствием дефрага. Предел мечтаний дисковых технологий, блин.
> Нет, не делается. Поизучай внутреннюю структуру BtrFS.
Поизучал. Да, на 1-дисковой конфиге влобовую пока с этим будет сложновато. Можно придумать костыли, но будет менее эстетично. А сколько копий метаданных твой zfs при этом хранит? А то упор на число копий данных без числа копий метаданных наводит меня на некие подозрения... Что скажете, маэстро?
> Ты, по-моему, не понимаешь, от чего защищают снапшоты, а от чего -- copies.
Я прекрасно понял о чем вы и даже согласен что в случае 1-дисковой конфиги ноута это не так уж плохо, хоть я вижу всего 1 реалистичный сценарий отказа в котором это может помочь - если вылезло несколько бэдов. И то - вероятность что попортятся ценные файлы в /home не особо большая, а как ZFS реагирует на бэды на лисяре уже было, с хексэдитором :).
А тут мне странно то, что про снапшоты не было упомянуто. Ибо тройное копирование не спасет от лажи по типу rm -rf /home/username /somedir. И это как-то сильно более вероятно чем какое-нибудь вылезание бэдов точно под ценными файлами хомяка.
> Это про разное.
Спасибо, Кэп.
>> ZFS по скорости работы просто не с чем сравнивать.
> Изен уже показал нам чего можно получить в ZFS :)"Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%"
https://www.opennet.ru/openforum/vsluhforumID3/100963.html#2У вас, аптгетчиков как всегда - для ZFS другая линейка?
> "Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%"
> https://www.opennet.ru/openforum/vsluhforumID3/100963.html#2
> У вас, аптгетчиков как всегда - для ZFS другая линейка?Странно, мне показалось что это бсдшные кулсисопы поливают btrfs за плохую работу в таком режиме, при этом старательно верещя что на ZFS так ни-ни. При том btrfs после такого еще можно отколупать с асфальта производительности дефрагером, если надо. А в ZFS дефрагера нету - есть только 1 метод: разобрать такой пул на...й или удвинуть с него все данные, что примерно одно и то же по смыслу.
> Странно, мне показалось что это бсдшные кулсисопы поливают btrfs за плохую работуименно поэтому в темы про фряху набигают звёзды аптгета районного масштаба? вообще подсказываю: отказ от наркотиков сильно сократит количество показавшегося.
>> ЧЯДНТ?
> - Не следишь за используемыми ресурсами и/или не заботишься о скорости работы1ГБ ОЗУ для вращения З-пула. Скорость у снэпшотных фс по любому ниже экстентных.
> - Не думаешь о людях, у которых 32bit системаСогласен, ибо в мире х86 они не нужны.
> - Скорее всего (но это ты расскажи) не используешь zfs на рутовой
Корень в сквэше, находящимся в ОЗУ. Файл ЗФС-блоба включен в образ, ибо необходим для старта пула.
> партиции (точнее на той, на которой /boot), или лишний раз усложняешь
> себе жизнь не получая профита, или поведай какие уникальные фичи zfs
> ты используешь?Снэпшоты.
А других усложнений там намного больше.
> 1ГБ ОЗУ для вращения З-пула. Скорость у снэпшотных фс по любому ниже экстентных.yolo, снапшоты и экстенты - разные вещи. Экстенты - всего лишь компактные записи, адресующие большие регионы. Что в большинстве случаев оказывается эффективнее чем если бы регион метился поблочно (что требует дофига метаданных для описания большого региона).
В ZFS сделали некое недоразумение с блоками переменного размера. Получив сложность устройства на уровне близкому к экстентам, но не получив при этом производительности файлух которые могут многомеговые регионы оформлять в один присест. Зачем оно вот так - никто внятно рассказать не может, саночный маркетинговый булшит этот момент тактично упускает :).
А снапшоты - всего лишь состояния ФС в тот или иной момент времени. Btrfs умеет нормальные экстенты и при этом самые разнообразные действия со снапшотами. Одно другому не мешает.
И кстати CoW на записи может быть очень быстрый, почти как нежурналируемая ФС. При свойствах близких к полному журналированию данных и метаданных.
> Корень в сквэше, находящимся в ОЗУ. Файл ЗФС-блоба включен в образ, ибо
> необходим для старта пула.Мсье знает толк в извращениях.
> В ZFS сделали некое недоразумение с блоками переменного размера. Получив сложность устройства
> на уровне близкому к экстентам, но не получив при этом производительности
> файлух которые могут многомеговые регионы оформлять в один присест. Зачем оно
> вот так - никто внятно рассказать не может, саночный маркетинговый булшит
> этот момент тактично упускает :).Ну ты-то лучше Джефа Бонвика разбираешься в устройстве ZFS. Тебе явно верить можно, а разработчику нет доверия никакого. ;)
Ну вот Мэйсону ты регулярно в новостях про бтр "не веришь", почему же тогда от тебя этот "аргумент" должен что-то значить?Зыж
2аноним:
> саночный маркетинговый булшит этот момент тактично упускает :).Почему же? Ещё при Джонатане Шварце они честно признались, что обобсались и решили вопрос в стиле традиционных фс (чтобы не вылезать за сроки).
> Ну вот Мэйсону ты регулярно в новостях про бтр "не веришь"Верить Мэйсону резона уже нет никакого. Он облажался по полной.
На 8-й год жизни в соляре ZFS была rock-stable, добивала последние острые углы в виде введения опций принудительного отката последних транзакций и рассматривалась как безальтернативная. На 8-й год жизни btrfs-а он так никуда и не слез с тестовых сетапов. Epic fail, как говорится.
>> Ну вот Мэйсону ты регулярно в новостях про бтр "не веришь"
> Верить Мэйсону резона уже нет никакого. Он облажался по полной.
> На 8-й год жизни в соляре ZFS была rock-stable, добивала последние острые
> углы в виде введения опций принудительного отката последних транзакций и
> рассматривалась как безальтернативная. На 8-й год жизни btrfs-а он так никуда
> и не слез с тестовых сетапов. Epic fail, как говорится.За 8 лет копипасты WAFL так и не поняли, что копировали СХД, а не ФС общего назначения. Ага, эпично.
> копировали СХДЯ так понимаю, это комплимент авторам ZFS. Делали FS, а получилась СХД! :-)
> 8 лет копипасты WAFL
Там не просто копипаста, а с творческими доработками. RAID-Z супротив WAFL-овского варианта RAID-4 имеет как и плюсы - в виде размазанного checksum, так и минусы в виде невозможности легко менять формат райда. Применение MFU-кеша тоже является хорошим ново?введением. Ну и так далее можно продолжать.
> Ага, эпично.
Эпичны те товарищи, у которых чувство NIH-а заставило игнорировать шишки NetUP-а и Sun-а и пилить свой кукольный театр со своими черепахами тортилами. Результаты 8-ми лет разработки мы все видим в топике.
> Там не просто копипаста, а с творческими доработками. RAID-Z супротив WAFL-овского варианта
> RAID-4 имеет как и плюсы - в виде размазанного checksum, так
> и минусы в виде невозможности легко менять формат райда. Применение MFU-кеша
> тоже является хорошим ново?введением. Ну и так далее можно продолжать._Допустим_ как СХД для бедных сойдет, в конце концов сервер с терабайтом DDR3 сейчас наверно многие могут себе позволить. Но как там в ZFS с масштабированием и распределенным хранением, с кластеризацией в целом?
> Результаты 8-ми лет разработки мы все видим в топике.
Так пишешь, как будто у ZFS нет перечисленных проблем с переполнением, падением производительности и странными багами.
Кстати, даже если допустить полное отсутствие проблем, ZFS по определению не подходит под топиковый юзкейс по причине жора памяти под кэши.
> производительности и странными багами.На лисяре можно найти приключения перца после вылезания пары бэдов на харде. Он там так rock stable хардкорил в хексэдиторе... :)
///---http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../
Был RAID-Z-пул собранный из трёх дисков по 1.5 Тб фирмы X, модели Y. Работал он работал, и изредка стали появляться в логах сообщения о том, что произошла ошибка чтения или ошибка записи на один из дисков пула. ZFS, ругаясь в логи на ошибки контрольных сумм, отлично отрабатывала такие моменты и пул продолжал нормально функционировать со статусом "ONLINE". Ошибки повторялись, но были не систематичными: различные диски, различные сектора, различное время. Назвав ошибки идиопатическими (неизвестной природы) решил, что обязательно разберусь с ними, но не сейчас. Эпик фейл подкрался незаметно, но всё же наступил. В один, не самый удачный момент, после перезагрузки, файловая система не cмонтировалась.
...
Год спустяЕщё весной задал на форуме вопрос о поддержке "отмотки" транзакций. И был направлен тов. Anon Y Mous на путь истинный, т.е. в последние (на тот момент) правки HEAD-ветки. Немного покопавшись в репозитории, нашёл нужную правку[3], в которой была добавлена поддержка той самой "отмотки" транзакций. Но это всё предисловие.
После обновления, в правке за номером 219089 [3], ZFS до версии 28, в zpool(8) появилась возможность откатываться на несколько транзакций назад при передаче параметра -F. Так что описанный в статье приём восстановления стал обычной рутинной задачей. За подробностями по ссылке на правку или в подсказку, выводимую zpool(8).
---///
Изя, мне это можно и не пересказывать - я более менее уловил смысл того фикса. А если бэды порушат что-то еще - тогда, таки, хексэдитор? :)> И был направлен тов. Anon Y Mous на путь истинный,
Удачи вам с вашим комьюнити. Где ламероватые кадры даже центось от кореоси не отличают, хотя это фундаментально разные дистры :)
> На 8-й год жизни в соляре ZFS была rock-stableНа 8 год жизни соляра как была подстилкой под субд оракл, так только ей (особенно после покупки) и осталась.
И под субд оракл zfs как не рекомендовалась, так и не рекомедуется. Прям как бтрфс в линухе (которую оракл также поддерживает в своём унбрикэбл линухе)
> И под субд оракл zfs как не рекомендовалась, так и не рекомедуется.Потому что ее CoW ораклу только мешается, а отключить - никак. Думаешь с фига ли Мэйсон сделал отключение CoW в btrfs даже пофайлово? Не надо быть крутым телепатом чтобы догадаться кто его об этом попросил и почему.
> Верить Мэйсону резона уже нет никакого. Он облажался по полной.Ну а шайка Бонвик и Ко которые невнятно мямлят на вопросы почему они так странно сдлали блоки - это ничего, сойдет? И что у нас там насчет маркетингового булшита что CoW не надо дефрагер? А может они скажут что-то ценное про изъятие дисков из пула? Или про улучшение жизни файлов БД и виртуалок, которым CoW имеет свойство мешать жить в ряде ситуаций?
> На 8-й год жизни в соляре ZFS была rock-stable, добивала последние острые
> углы в виде введения опций принудительного отката последних транзакцийЭто в смысле когда перец на лисяре заметил что после нескольких бэдов на харде файлуха встала в позу и ее штатными тулзами - вообще никак? И надо хэксэдитором номер транзакции подделывать? Интерсное понимание rock stable.
> и рассматривалась как безальтернативная. На 8-й год жизни btrfs-а он так
> никуда и не слез с тестовых сетапов. Epic fail, как говорится.Цыплят по осени считают :).
> Ну ты-то лучше Джефа Бонвика разбираешься в устройстве ZFS.А чего там разбираться? Слепили как умели. Получилось нечто. Местами довольно странное и не сказать что сильно оптимально сделанное. Как-то конечно работает. Если 100500 гигз оперативы подпереть и другие программы на эти гигазы претендовать не будут.
> Тебе явно верить можно, а разработчику нет доверия никакого. ;)
А разработчик лицо заинтересованное, особенно когда работает в коммерческой компании льющей со своего сайта ведра маркетингового булшита.
связка из двух, взаимоподпирающих ФС - как-то это криво
> связка из двух, взаимоподпирающих ФС - как-то это кривоЭто же Linux way!
> Это же Linux way!А bsd way - сделать музейный экспонат и поставить на полочку...
> Это же Linux way!Sun way: компенсирвать технические проблемы громким маркетинговым булшитом.
Использую btrfs уже 4 года на десктопе, и 2 года на файловых и веб серверах, за всё время ФС ни разу не упала, тормозов с ядра 3.14.1 вообще не видел, надо просто думать головой, ставить на её таблицу разделов, и выбирать под задачи компрессию.
Как всегда в Linux: "тщательно обработайте напильником перед использованием".
> Как всегда в Linux: "тщательно обработайте напильником перед использованием".рассуждения гамбургероеда
Ну а почему нельзя просто продолжать использовать ext4 как и раньше?
> Ну а почему нельзя просто продолжать использовать ext4 как и раньше?Можно. Используйте. Я разрешил.
btrfs - ужасная файловая система. Ее присутствие в ядре вообще загадка...
Взятка Торвальдсу за зонд отдали...
> Взятка Торвальдсу за зонд отдали...Пользователей putty.exe всегда так волнуют проблемы Linux... :)
Это не отменяет того, что включение в ванилу было исключительно политическим (наш ответ zfs), как и не включение reiser4
> Это не отменяет того, что включение в ванилу было исключительно политическим (наш
> ответ zfs), как и не включение reiser4Btrfs на момент включения хоть как-то работал и там была какая никакая команда разработчиков. А рейзер не только сырой, но и без внятной команды которая бы его допилить могла. И нет, в майнлайне не приветствуют откровенное решение чужих проблем (в том числе с руками) за их счет.
> команда разработчиков. А рейзер не только сырой, но и без внятной
> команды которая бы его допилить могла. И нет, в майнлайне не
> приветствуют откровенное решение чужих проблем (в том числе с руками) за
> их счет.Все из себя "внятные" команды разработчиков только дерьмо пихают, а хорошую файловую систему по умолчанию им никто не предложит. Давно уже пора понять.
> Все из себя "внятные" команды разработчиков только дерьмо пихают, а хорошую файловую
> систему по умолчанию им никто не предложит. Давно уже пора понять.А лично я посмотрев на архитектуру btrfs я склонен посчитать что его включили не зря - Мэйсон явно целился и в разные юзкейсы, и в всякие перспективные сценарии администрирования с нулевым даунтаймом и возможностью все переиграть прямо по ходу пьесы.
Несомненно, любое решение несет как плюсы так и минусы. И btrfs в этом ничем таким не особенный. Но в целом лично мне многие тамошние идеи нравятся. И я по крайней мере понимаю "а зачем вот тут вот это делали вот так".
Когда говорил, что "btrfs - ужасная файловай система" речь шла как раз о ее реализации.
> Когда говорил, что "btrfs - ужасная файловай система" речь шла как раз
> о ее реализации.У рейзера с реализацией все намного запущеннее и там для начала нет нормальной команды разработчиков.
Шишкин который иногда анонсирует как рейзер героически портирован на новое ядро - это круто. А в майнлайне это надо в реалтайме, с релизом раз в 2-3 месяца. С утрясанием своего кода с кодом соседей по цеху. У Мэйсона на это ресурсы так или иначе найдутся. А вот у Шишкина - врядли. А получать порцию проблем на свои головы в майнлайне не любят. Конечно тех кто завалил майнтенанс могут выпереть и из майнлайна, по ходу пьесы, но обычно предпочитают работать с упреждением: если понятно что с майнтенансом не справятся, т.к. сложившейся команды нет - отфутболят еще на подлете. Никому не надо порцию головняка. А попадание в майнлайн - привилегия а не право.
> А вот у Шишкина - врядли. А получать порцию проблем на
> свои головы в майнлайне не любят....
> порцию головняка. А попадание в майнлайн - привилегия а не право.Скажу тебе по секрету: btrfs - самая большая проблема, которую "кернел-боги" поимели за всю свою историю, и теперь не знают, что им делать с огромной оравой юзеров и "разработчиков", обманутых двумя евреями Мейсоном и Бэсиком.
> Скажу тебе по секретуРазве у дятлов бывают секреты?
>> Скажу тебе по секрету
> Разве у дятлов бывают секреты?Ну, у кернел-разработчиков есть инфа "для публики", и есть "не для публики".
> Ну, у кернел-разработчиков есть инфа "для публики", и есть "не для публики".У них есть LKML, он и для публики и не для публики. Сугубо вопрос интересов того или иного представителя публики. Бывают мыллисты проектов/подсистем. Для них верно то же самое. А сказки про вселенские заговоры в LKML оставьте для бабушек на скамейке.
> Скажу тебе по секрету: btrfs - самая большая проблема, которую "кернел-боги" поимели
> за всю свою историю,Нет никакого смысла мне врать. Reason: я читаю списки рассылки касающиеся линуксного ядра и его подсистем. Поэтому единственное что вы можете достичь таким манером - выставить себя гнусным лжецом. И да, я видел и некоторые нарекания. И похвальбы. А в целом - нормальный рабочий процесс. Не хуже и не лучше остальных подсистем.
> двумя евреями Мейсоном и Бэсиком.
Во первых, если уж на то пошло, евреи как правило умные (по поводу чего и оставляют всяких простофиль в дypaках, за что простофили их предскауемо не любят). А в таких вопросах, определенно, мощный мозг, а лучше несколько - самое оно.
Во вторых, а вон те япы из фуджика и китайцы из оракла в курсе что они оказывается тоже евреи? :)
> btrfs - ужасная файловая система. Ее присутствие в ядре вообще загадка...BTRFS в ядре, так как если бы её там не было бы -- то ни кто бы BTRFS (в серьез) не использовал бы.
только такие дурачки как "пользователи ZFS на Linux" -- позволяли бы себе заиспользовать бы BTRFS (если бы BTRFS ядре не было бы).
разгадка проста:
в Linux-системах -- не удобно (и не надёжно) использовать те файловые системы которые требуют для своей работы кустарный патчинг ядра.
вот именно поэтому -- BTRFS присутствует в ядре (как модуль). и всегда готово к выполнению своей сложной работы!
Тебе надо "заиспользовать" матчасть про проблему "курицы и яйца"
это ты намекаешь про initramfs или что?
Зачем они хотят это сделать?
им нужна контейнерная изоляция.
желательно с расходованием как можно меньше ресурсов цпу на это.
так что вполне логично.
https://coreos.com/about/
"Наша команда состоит из системы экспертов и выпускников из следующих организаций:
SUSE и ещё 7 штук."https://www.opennet.ru/opennews/art.shtml?num=40947
"В тестовом выпуске ядра Linux 3.18-rc2 появилась поддержка файловой системы OverlayFS, разработанной компанией SUSE в качестве более прогрессивной замены UnionFS и AUFS."Недостающий элемент найден.
Клоун говорит: "от г-вна г-вна не ищут."
> Клоун говорит: "от г-вна г-вна не ищут."У клоуна сегодня приступы самокритики.
Он самокритичен
> Клоун говорит: "от г-вна г-вна не ищут."Это ты так просишь, чтобы тебя не банили?