Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен.

Где-то летал патч, реализующий и снапшоты в Ext4, только это не значит, что сама по себе Ext4 умеет снапшоты.

Тогда расскажи мне, почему опция монтирования Reiser4, снижающая фрагментацию, не считается костылём, маскирующим плохой дизайн, а опция монтирования в Btrfs - считается?

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

Нормальная практика делать разделы в 700 Мб? Лол.

это было для теста.
А вот иметь разделы в 2гб - вполне нормально. Хотя, блин, какая разница какие разделы? У меня может быть куча небольших файлов, которые будут занимать 2гб - что тогда будет?

Ты один из этих клоунов, что ли, которые постят всякую тупую хероту «для поржать»?

pedobear

толсто

Если да, то так и скажи, я не стану тратить время на тебя.

ты пишешь пост на целый экран. Ты тратишь время на меня. Мне это нравится :)

Ещё раз: в man mkfs.btrfs чотко написано:

процитирую анонима:

Опция max_inline - это был первый звонок, что в btrfs серьёзные проблемы с дизайном.

Ну а фигли тогда сравниваешь примитивную ФС с btrfs?
сравниваешь примитивную ФС
примитивную ФС

слишком толсто. Ты знаешь столько труда стоит портировать её под что угодно?

Чтобы пользоваться снапшотами lvm, нужно себя не уважать. Лучше бы удалили эту функциональность из lvm вообще, чтобы не позориться.

кстати, начал работать с lvm, поэтому интересует тема. Расскажи что в снапшотах на lvm плохого? Вдруг потом пригодится инфа.

Я её пробовал, херовая ФС по ряду параметров.

Расскажи, я через полгода планирую на неё перейти, хочу знать что с ней не так. Ну, помимо требования к объему ОЗУ.

Держи меня в курсе своих мнений, они очень ценны.

с удовольствием буду :)

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

омг, так это тот самый фрактал?
ЛООООЛ!
кстати, а как ты эго определил? т.е. на чем он спалился? или он сам сказал?

Школьник и его кумир.

Где-то летал патч, реализующий и снапшоты в Ext4, только это не значит, что сама по себе Ext4 умеет снапшоты

В отличие от снапшотов сжатие впилили в формат ещё ext2.

сама по себе Ext4

Сама по себе любая ФС умеет то, что предусмотрено кодом. В бтр снапшоты тоже не с луны свалились.

это для увеличения уровня вброса

Тогда расскажи мне, почему опция монтирования Reiser4, снижающая фрагментацию, не считается костылём, маскирующим плохой дизайн, а опция монтирования в Btrfs - считается?

B Reiser4 опцией монтирования назначается подходящая транзакционная модель (журналирование, COW, или смашанная техника), а в btrfs теми опциями прикрыли непонимание работы алгоритмов (структуры дазнных слизали c reiserfs, а что с ними дальше делать, Крис Мейсон не знает, как и её внутреннего устройства).

это было для теста

Если я создам раздел с Reiser4 размером в 360 Кб - как думаешь - она будет там работать?

А вот иметь разделы в 2гб - вполне нормально

В 2014-ом году? Это не нормально, это дефект мозга. Впрочем, btrfs на таких разделах чувствует себя нормально, я пробовал с год назад.

толсто

И какая связь?

слишком толсто

В сравнении с Btrfs все остальные апстримовые линуксовые ФС примитивны, потому в сравнении с ней имеют жалкую функциональность.

Расскажи что в снапшотах на lvm плохого?

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

Расскажи

Жрёт раму, вынуждает трахаться с наложением патчей на ядро и сборкой initrd, имеет какую-то ущербную логику работы с клонами-снапшотами, перегружена функциональностью (я так и не понял, зачем в ней нужна подсистема работы с самбой), ну и там ещё по мелочи вроде того что если ты нечаянно включил дедупликацию на корневом томе, то отключить её можно будет только пересозданием ФС целиком. Мне вообще не очень нравится иметь ФС, примотанную сбоку к ядру изолентой, но это кому как.

а нифига вообще пилят это самое прозрачное сжатие?

Экономия места и увеличение скорости i/o. lzo не просто быстр, он реактивен, и рамы кушает всего ничего (десятки килобайт на рапаковку, емнип).

В бтр снапшоты тоже не с луны свалились.

В btrfs снапшоты реализованы изначально, ибо CoW by design.

журналирование, COW, или смашанная техника

То есть, чтобы не было фрагментации, мне нужно отказаться от CoW и, как следствие - снапшотов? А впрочем о чём это я, Reiser4 же до сих пор не умеет снапшоты, лол. Хорошая такая теоретически красивая ФС, которая на практике ничем похвастать не может. Прям как BSD-системы или какой-нибудь Plan9.

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

Дык на _каждую_ распаковку. А сколько распаковок идёт параллельно?

И ещё вопрос (я просто не в теме), а что в бтр файлы пакуются целиком или экстентами/блоками? Какой размер экстента?

Жрёт раму

Стыдно такое писать, при нынешних ценах на RAM.

имеет какую-то ущербную логику работы с клонами-снапшотами

Если ты не понял эту логику, это не означает, что она ущербная.

если ты нечаянно включил дедупликацию

Не надо пьяным админить энтерпрайзные ФС ))

Я тоже не в теме.

Стыдно такое писать, при нынешних ценах на RAM.

На сервере-то оно и не жалко отдать все 32 Гб на нужды ФС, а на десктопе у меня всего 8 Гб, да и те я лучше отдам нужным мне прикладным программам.

Если ты не понял эту логику, это не означает, что она ущербная.

Она ущербная, в сравнении с таковой в btrfs, где всё есть subvolume.

Не надо пьяным админить энтерпрайзные ФС ))

Ну вот в том и дело, что сфера ZFS - это большие и мощные энтерпрайз-машины, а Btrfs разрабатывается как ФС общего назначения.

Возможно, это ответ на твой вопрос:

 Can a file data be compressed with different methods?

Yes. The compression algorithm is stored per-extent. 

А что там, в этом файле?

У btrfs в доке написано — если первый кластер несжимаемый, то сжатие для всего файла отключается.

Она ущербная, в сравнении с таковой в btrfs, где всё есть subvolume.

Нет, она крайне логична. Есть ФС, она rw и parent для снапшотов и клонов, есть снапшот он readonly и это прекрасно, его невозможно испортить, из снапшота можно сделать клон, который rw, но имеет связь с parent и может быть rollback в любой момент. Клону можно сделать promote и сам становиться parent для следующей ветки. Это очень логично.

На btrfs снапшот rw (можно испортить) и не понятно кто parent. А уж как на btrfs делается rollback...я долго смеялся.

А что там, в этом файле?

Обычные образы ВМ, операционные системы там, в начале файла.

Значит, MBR в начале файла. Сомневаюсь, что её можно адекватно сжать.

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

из снапшота можно сделать клон

И только из снапшота. А если я хочу сделать клон сразу из parent, то zfs покажет мне кукиш. Абалдеть.

На btrfs снапшот rw (можно испортить) и не понятно кто parent

Враньё. Ключ -r делает снапшот readonly и кто parent - прекрасно видно тоже:

# btrfs subvolume show /zone/root/August
/zone/root/August
        Name:                   August
        uuid:                   8fde9333-876e-464f-a2b2-b44a2bd03cf7
        Parent uuid:            093ab625-e61d-0c4f-a2e6-fed17eadc0d1
        Creation time:          2014-08-02 00:48:35
        Object ID:              436
        Generation (Gen):       488644
        Gen at creation:        452155
        Parent:                 269
        Top Level:              269
        Flags:                  -
        Snapshot(s):
                                root/August23

А уж как на btrfs делается rollback...я долго смеялся

А толку от zfs rollback, если систему перезагружать всё равно придётся?

Если я создам раздел с Reiser4 размером в 360 Кб - как думаешь - она будет там работать?

прекрати утрировать, выглядит по-детски

В 2014-ом году? Это не нормально, это дефект мозга. Впрочем, btrfs на таких разделах чувствует себя нормально, я пробовал с год назад.

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

И какая связь?

прямая

В сравнении с Btrfs все остальные апстримовые линуксовые ФС примитивны, потому в сравнении с ней имеют жалкую функциональность.

что является критерием примитивности? функциональность можно засунуть себе в задницу, если её можно посчитать на раз-два и она, к тому же, работает нестабильно (не мои слова, кстати)

Нужно заранее выделять том под снапшоты

это да, есть такая тема, она заложена в lvm, и от неё никуда не деться

причём как-то либастрально угадать его размер

о прогнозировании размера для lvm раздела уже много чего написано, если человек захотел пользоваться lvm, то он посмотрит и оценит как следует

после создания снапшота скорость записи падает в разы, если не на порядок

обратная сторона медали за низкий объем занимаемого пространства. С учетом этого - скорее не недостаток, а особенность. Кроме того, вроде как падение производительности почти фиксировано, если только винчестеры не кусок дерьма.

Жрёт раму

насколько сильно?

вынуждает трахаться с наложением патчей на ядро и сборкой initrd...ФС, примотанную сбоку к ядру изолентой

у меня целевая система - freebsd, мне такое не грозит

имеет какую-то ущербную логику работы с клонами-снапшотами

а что там?

ну и там ещё по мелочи вроде того что если ты нечаянно включил дедупликацию на корневом томе, то отключить её можно будет только пересозданием ФС целиком
подсистема работы с самбой

жесть! не знал, спасибо. Надо бы проработать и изучить этот вопрос.

Увы, так везде (и в reiser4 тоже). Впрочем, багзилла открыта, пиши RFE.

Нет, ты не прав. Он пишет о том, что у btrfs неограниченная внутренняя фрагментация. Это означает, что раздел любого объёма можно довести до состояния, при котором файлов на разделе не будет, а место обратно не появится.

А если я хочу сделать клон сразу из parent

Это нелогично, тебе некуда будет делать rollback.

Ключ -r делает снапшот readonly

Снапшот вообще нельзя делать rw, теряется смысл.

кто parent - прекрасно видно тоже:

ок, не знал.

А толку от zfs rollback, если систему перезагружать всё равно придётся?

Ничего не надо перезагружать. Или ты про частный случай, когда откатываем файл(ы) образ ВМ? Тогда ВМ надо перезагрузить, но к хосту с zfs это не имеент отношения.

Reiser4 так до сих пор и не избавилась от катастрофического роста фрагментации с течением времени

4.2, txmod=journal.

Ты можешь и не осваивать, твоё право, но вышеуказанный пункт правил никто не отменял.

прекрати утрировать, выглядит по-детски

А Шишкинские кривляния с 700-метровым разделом не выглядят по-детски? Лол.

массив данных из маленьких файлов, объемом в 2гб - вполне реальная ситуация

И какие проблемы? А никаких.

прямая

Её нет, вот и всё.

функциональность можно засунуть себе в задницу

Засовывай, если любишь совать себе что-то в задницу. Я предпочитаю ею пользоваться по прямому назначению. Btrfs умеет много чего такого, что Reiserfs и не снилось, вывод очевиден - Reiserfs в сравнении с Btrfs примитивна. А примитивные программы разрабатывать и развивать проще, чем сложные.

если человек захотел пользоваться lvm

...то он мазохист.

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

А в Btrfs диффы пишутся на уровне блоков, ниже занимать пространство под снапшоты просто некуда. И со скоростью всё в порядке, не падает почему-то.

у меня целевая система - freebsd

Зачем тогда вообще встрял в обсуждение Btrfs? Её под BSD просто нет.

Это нелогично

Только в головах упоротых разрабов ZFS.

тебе некуда будет делать rollback

С чего ты взял, что я его вообще буду делать?

Снапшот вообще нельзя делать rw

То, что в ZFS называется отдельными словами клон и снапшот, в Btrfs называется просто subvolume с соответствующими свойствами.

Ничего не надо перезагружать

Если я обновил систему, включая, например, glibc, перезагрузился, и оказалось, что новая glibc корячит некоторые программы, я захотел сделать rollback, сделал, и?

Поговори мне тут ещё -))

Только в головах упоротых разрабов ZFS.

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

С чего ты взял, что я его вообще буду делать?

Значит будешь вытвскивать из бэкапа, если он есть.

Если я обновил систему, включая, например, glibc, перезагрузился, и оказалось, что новая glibc корячит некоторые программы, я захотел сделать rollback, сделал, и?

Я не исполюзую zfs на системном разделе.

Потому что если не указать txmod, то лишь упадёт производительность, причём это будет закономерно следовать из принципов работы ФС (другими словами, not a bug).

А вот если не указать max_inline, то при определённых типах нагрузки ФС превратится в тыкву. И это уже баг.

ты истина в последней инстанции

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

Поработай с zfs на производстве

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

Значит будешь вытвскивать из бэкапа

Не буду. На Btrfs всё отлично работает и с её удобной логикой, а если мне нужен зацементированный неизменяемый снимок - я сделаю btrfs subvolume snapshot -r blablabla

Я не исполюзую zfs на системном разделе

Крутой ответ.

Этот твой rollback - всего лишь удобный памперс. И btrfs откат делается примонтированием нужного снимка, и причём без уничтожения всех последующих состояний ФС, лол.

Как же я жил почти год без max_inline? Я его только месяц назад выставил на всякий случай.

Поговорю. А что? По ойпи вычислишь?

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

То, что ты не сталкивался с каким-то багом, не означает его отсутствия — а означает лишь, что тебе повезло. А баг есть, причём идейный, и поэтому ФС дерьмо.

Ядро 3.17.1 x86_64. Монтируем btrfs

Сильно сомневаюсь, что в каком-то стабильном дистрибутиве уже есть 3.17.1

Арч или самосборное ядро? Тогда ССЗБ

Про работу btrfs в стабильных дистрибутивах сказать ничего не могу - не пользуюсь btrfs

Адепт systemd вещает про идейные баги. Оборжаться.

Арч или самосборное ядро? Тогда ССЗБ

От самосборности ядра Btrfs резко ломается?

Это не мои слова. Или ты умнее Шишкина (отдел разработки ФС в редхате)?

Это не мои слова

А ты всегда повторяешь мнимых авторитетов?

Или ты умнее Шишкина (отдел разработки ФС в редхате)?

После его пассажа с 700-метровым разделом я уже не знаю что и думать.

Я сказал лишь, что на мой взгляд

Кажется наметился колоссальный прогресс в нашей дискуссии )

Да не хочу я с ней работать на производстве

Да тебе и не надо, просто именно на производстве становится понятно что к чему, на локалхостах просто многие мегаполезные вещи зачастую неочевидны.

если мне нужен зацементированный неизменяемый снимок - я сделаю btrfs subvolume snapshot -r blablabla

Опять же, на локалхосте это приемлемо. Знаешь почему на zfs snapshot readinly? Чтобы low-level-админы и другие стихийные бедствия не наделали глупостей, у них просто нет такой возможности.

Этот твой rollback - всего лишь удобный памперс.

Используемый практически ежедневно.

причём без уничтожения всех последующих состояний ФС, лол.

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

Никаких авторитетов. Если есть что противопоставить по существу — вещай (лучше сразу ему). Иначе... ну ты понял.

Сильно сомневаюсь, что в каком-то стабильном дистрибутиве уже есть 3.17.1. Арч или самосборное ядро? Тогда ССЗБ

Ubuntu 14.10, обычное ядро, релиз вот отсюда http://kernel.ubuntu.com/~kernel-ppa/mainline/

Без понятия, не использовал.

Но пионерия «у меня последняя версия ядра из SVN и вообще весь софт самый новый!!111» ловит все возможные баги первыми, и на основе баттхерта судить о стабильности ПО было бы опрометчиво.

Кажется наметился колоссальный прогресс в нашей дискуссии )

Капец, я с самого начала, ещё даже не в этом треде, обозначил, что это моя личная позиция.

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

Или просто не нужны.

Чтобы low-level-админы и другие стихийные бедствия не наделали глупостей

А я вот не люблю системы с защитой от дурака. Меня это оскорбляет, как пытливого дурака.

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

Нет, не логично. Я могу откатиться потому, что у меня в настоящий момент нет желания разбираться с ломающим систему glibc, но потом в свободное время оно может возникнуть. А снапшот уже тю-тю.