ничего себе на btrfs перешел

Откуда такая уверенность?

Потому что вся прогрессивная линукс-тусовка ждёт Bcachefs.

т.е. ты весь из себя такой бывалый, а таких элементарных вещей не знаешь/понимаешь и свести в голове 2+2 не можешь? ну ок. я уже молчу про то, что гугелем, видимо, тоже не умеешь пользоваться.

Тю, я два раза пробовал btrfs, один раз на генте, один на арчике, и оба раза она безвозвратно умирала на следующий день.

Потому что вся прогрессивная линукс-тусовка ждёт Bcachefs.

Интересно, спасибо за информацию.

Посмотрел по диагонали http://bcachefs.org и честно говоря, не понял, чем данная fs превосходит btrfs. Вроде точно такой же набор возможностей. А степень готовности очевидно ниже.

Так что было бы интересно узнать, почему Вы прогнозируете победу именно bcachefs?

победу

Победу чего над чем? При чем здесь победа? Что Линусу его «советники» на ушко нашепчут, так и будет.

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

Победу чего над чем? При чем здесь победа?

Есть две FS с практически идентичными наборами свойств. Реализовывать обе нерационально - лишнее распыление сил. Следовательно, логично выбрать по каким-то критериям одну из двух и развивать именно ее. Это я и назвал победой ;).

Что Линусу его «советники» на ушко нашепчут, так и будет.

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

btrfs очень тормознутая, и это факт.

Не знаю, почему Вы так решили. Я сам не экспериментировал с btrfs, но в той же википедии другие данные о производительности.

А эти парни говорят, что с их архитектурой получится сделать быстрее

Сразу вспоминается анекдот:

- Доктор, у меня проблема, мне 90 лет и нам с женой не удается заниматься любовью чаще двух раз в неделю.
- Позвольте, но это же отличный результат.
- Но мой 95-летний сосед говорит, что они с женой занимаются любовью ежедневно.
- Ну так и Вы говорите.

А если серьезно, то судя по описанию там очень похожа архитектура (и там, и там B-деревья). Так что мне непонятно, почему стоит ожидать существенной разницы в производительности.

Не говоря уж о том, что вклад именно FS в общую задержку IO-операций, IMHO, минимален (проценты, а то и дол процента). Стоит ли за эти сопли бороться?

По btrfs накопилось куча наработок, просто так отказываться от них в пользу неведомой хрени, которая находится на начальных стадиях реализации, как-то странно, не находите?

Мое мнение - это ловля блох. Если действительно не хватает IOPS, стоит подумать о SSD, или даже массиве из SSD.

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

то-то производители дисковых массивов встраивают компрессию в свои ящики, а некоторые, о боже, прямо в контроллер ssd

А мне представляется, что поумнеть стоит именно Вам, если Вы не видите разницу между компрессией средствами контроллера ssd/массива и за счет CPU ;).

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

А мне представляется

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

разницу между компрессией средствами контроллера ssd/массива и за счет CPU

с удовольствием послушаю иксперда.

накладные расходы цпу на компрессию, были ничтожно малы по сравнению с профитом уже году так в 2006.

Дело не в накладных расходах. Дело в том, что будет с Вашей компрессией и, следовательно, со скоростью IO, когда очередной(ные) javascript(s) полностью займут Ваш CPU.

Это как с аппаратными RAID-контроллерами - любой из них в разы, а то и на порядки уступает по производительности CPU, но в серьезных системах их по-прежнему предпочитают программному RAID как раз из соображений полной безопасности IO-операций от непредсказуемого поведения CPU.

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

Спасибо за информацию, действительно не знал об этом. Осталось только понять, какое отношение имеют спарки к нашей дискуссии? ;)

Не знаю, почему Вы так решили. Я сам не экспериментировал с btrfs, но в той же википедии другие данные о производительности.

Ну, наверно, это потому, что туда пишут такие же, как ты, которые «не экспериментировали, но прочитали, что на заборе написано».

Ну, наверно, это потому, что туда пишут такие же, как ты, которые «не экспериментировали, но прочитали, что на заборе написано».

А у Вас, конечно же, есть объективные тесты производительности, я Вас правильно понял? И где же в таком случае ссылки на них?

Не говоря уж о том, что вклад именно FS в общую задержку IO-операций, IMHO, минимален (проценты, а то и дол процента). Стоит ли за эти сопли бороться?

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

уже составляет гораздо большую долю, чем дцать лет назад

С этим утверждением согласен. Только вот какую именно долю, можете озвучить? Хотя бы примерно? На мой взгляд, это все равно проценты от общей задержки. Пусть и не доли процентов, как раньше.

А у Вас, конечно же, есть объективные тесты производительности

Извините, а где Вы в природе видели объективные тесты производительности? Можете привести пример? Особенно интересует тест, по которому можно определить, что через месяц мой раздел с btrfs не станет жутко тормозить и не превратится в тыкву.

а где Вы в природе видели объективные тесты производительности?

Видел множество. На сайтах http://forum.ixbt.com/?id=66, или http://www.3nity.ru, например. Вообще-то, технологии тестирования производительности IO довольно хорошо разработаны.

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

Хм, а не кажется ли Вам, что Вы смешиваете разные понятия? Мы сейчас говорим о влиянии FS на общую производительность IO. А Вы просите тест на надежность. Это отдельный параметр, гораздо более важный, чем производительность, на мой взгляд, и обсуждать его надо отдельно.

Дело в том, что будет с Вашей компрессией и, следовательно, со скоростью IO, когда очередной(ные) javascript(s) полностью займут Ваш CPU.

и что же будет?

Это как с аппаратными RAID-контроллерами - любой из них в разы, а то и на порядки уступает по производительности CPU

иксперда видно за версту.

но в серьезных системах их по-прежнему предпочитают программному RAID

ты точно их видел?

Осталось только понять, какое отношение имеют спарки к нашей дискуссии? ;)

то, что ты не понимаешь очевидных вещей мы уже поняли.

как раз из соображений полной безопасности IO-операций от непредсказуемого поведения CPU.

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

ты точно их видел?

Угу, видел. Хотя что называть серьезными системами, вопрос сложный ;).

Впрочем, в контексте нашего с Вами разговора речь шла о внутренних аппаратных RAID-контроллерах, как Вы бы могли догадаться из контекста ;).

Как Вы думаете, почему их до сих пор используют, хотя уже очень давно CPU на порядок превышают по производительности процессоры контроллеров? Казалось бы, давно пора переходить на программный RAID. Но этого не происходит ;). И не происходит по той же самой причине - обслуживание дисковой системы не должно зависеть от загруженности CPU. Иначе это чревато серьезными проблемами вплоть до развала массива/fs.

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

Что-то Вас в крайности бросает ;). Нет, внешние массивы - это здорово (хотя fc сегодня выглядит несколько архаично ;)), но не всегда имеет смысл из пушки по воробьям стрелять ;).

и что же будет?

А вот тут уж как повезет. В лучшем случае у Вас машина впадет в ступор почище чем при баге 12309 - CPU будет занят процессами, ждущими IO, а система IO будет ждать освобождения процессора. Ну а если не повезет, то возможны и потери данных вплоть до полного развала fs.

потери данных вплоть до полного развала fs.

и кто ж её развалит в процессе ожидания несчастного CPU?

и кто ж её развалит в процессе ожидания несчастного CPU?

Запись по тайм-ауту прервется. Или пользователь перезагрузит машину от безысходности. Все, что угодно случиться может.

Только вот какую именно долю, можете озвучить? Хотя бы примерно? На мой взгляд, это все равно проценты от общей задержки. Пусть и не доли процентов, как раньше.

Может ты, для начала, свои доли процентов приведешь в виде конкретного числа и конкретной конфигурации?

Если грубо крутящийся диск дает 100 IOPs, а SSD 10000, то это уже сокращение времени на непосредственно I/O в 100 раз. Пусть, согласно тебе, софтверный стек забирает 0.5% от времени I/O на жесткий диск, тогда грубо это будет 50 микросекунд (исходя из 100 IOPS на жесткий диск). Если мы теперь этот жесткий диск заменим на SSD, выдающий 10000 IOPS), то время одного I/O получится порядка 100 микросекунд, и предполагая, что для обработки одной операции ввода/вывода в том же самом программном стеке по-прежнему требуется приблизительно же самое время, их этих 100 микросекунд 50% будет приходиться на софтверный стек.

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

Как Вы думаете, почему их до сих пор используют

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

Казалось бы, давно пора переходить на программный RAID. Но этого не происходит ;).

Кто тебе сказал? Программные зеркала используются достаточно широко последние лет 20 как минимум, а то и больше. Целые компании даже на этом поприще выросли.

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

Если под «это» ты имеешь ввиду переход на программный RAID5/6, то не происходит это по совершенно другой причине, а именно родовой травме RAID5/6, известной как «write hole», то есть сложности программным образом атомарно обновить два или более дисков с приемлемой производительностью, плюс дополнительных чтений старого содержимого диска с данными и четности и записи новой четности, которые очень негативно влияют на производительность. Поэтому и лепят аппаратные RAID-контроллеры с энергонезависимым кэшем, чтобы добиться этой самой пресловутой атомарности и спрятать задержки дополнительных операций I/O за кэшем.

Иначе это чревато серьезными проблемами вплоть до развала массива/fs.

Я что-то не понимаю. Не пытаешься ли ты сказать, что из-за аппаратного RAID-контроллера такого произойти не может? Тогда у меня для тебя плохие новости. Или ты намекаешь, что так дело обстоит в ляликсе? Ну так это неудивительно. Тут недавно на SDC презентацию показывали с очень интересной табличкой, иллюстрирующей печальное положение дел с файловыми системами в этом самом ляликсе. Слайд 18. Самое смешное, что вместо того, чтобы предложить собраться всем миром и исправить проблемы, товарищ предложил новый велосипед. А еще смешнее то, что и новый велосипед оказался не без проблем, о чем он сам и сообщил на слайде 36 оной презентации.

CPU будет занят процессами, ждущими IO, а система IO будет ждать освобождения процессора.

В нормальных системах процессы, ждущие I/O, CPU не занимают. Даже если они работают в режиме толлинга (что особенно характерно для разных высокопроизводительных NVM), все равно стараются не занимать все процессоры одновременно, да и на одном процессоре стараются не занимать его целиком, а подстраиваться под ожидаемое время ответа и начинать поллинг незадолго до ожидаемого завершения операции.

иллюстрирующей печальное положение дел с файловыми системами в этом самом ляликсе.

У них модель развития такая. Линуксовый социум устраивает.

Спасибо за приведенные расчеты. Должен признать, Вы меня убедили, действительно, с приходом SSD ситуация коренным образом изменилась и теперь влияние FS на производительность заметно. У меня, видимо, до сих пор в голове штампы эпохи HDD :(.

Тем не менее, остаются вопросы к целесообразности обслуживания IOPs средствами CPU.

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

Угу, а никогда не задумывались, почему из всех вариантов RAID при программной реализации используются именно зеркала?

Могу Вам ответить - причиной является как раз устойчивость зеркала к развалу. Точнее, данные остаются доступными даже после развала зеркального массива. В отличие от других уровней RAID. А развал возможен как раз в силу непредсказуемости поведения CPU - при создании массива мы не знаем, что за код будет он выполнять.

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

Хм, точно также можно это обеспечить и на CPU. В качестве кеша тут кусок RAM будет использован. Хотите энергонезависимость, ставите UPS ;). И потом, десятый RAID тоже не собирают, как правило, программно.

Так что дело тут не в атомарности операций, а именно в необходимости предсказуемости процессора, обслуживающего массив.

А предсказуемость можно обеспечить только одним способом - изоляцией обсчета массива от всех остальных задач. Не случайно ведь ряд СХД используют в качестве контроллеров обычные серверы с x86_64 процессорами и программной реализацией RAID. Все отличие от CPU обычной машины только в том, что там нет других задач и весь процессор занят исключительно обслуживанием массива.

Не пытаешься ли ты сказать, что из-за аппаратного RAID-контроллера такого произойти не может?

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

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

Или ты намекаешь, что так дело обстоит в ляликсе? Ну так это неудивительно.

Вы в самом деле считаете, что FS в других системах лишены перечисленных в приведенной Вами презентации проблем?

Кстати, большое спасибо за саму презентацию.

В нормальных системах процессы, ждущие I/O, CPU не занимают.

А речь и не идет о нормальных системах. Я говорю о багах в коде, который крутится на CPU и не имеет отношения к обслуживанию RAID.

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

Что и достигается их вынесением на отдельный процессор в составе RAID-контроллера.

да и на одном процессоре стараются не занимать его целиком, а подстраиваться под ожидаемое время ответа и начинать поллинг незадолго до ожидаемого завершения операции.

Вы сейчас пишете о том, как это должно работать в идеале. К сожалению, кода без багов не бывает, так что реальное поведение может сильно отличаться от идеального :(.

Вы сейчас пишете о том, как это должно работать в идеале. К сожалению, кода без багов не бывает, так что реальное поведение может сильно отличаться от идеального :(.

Все исходят из того, что багов нет. Закладываться на баги в системе изначально некорректо. Что вы собираетесь вывести из начального условия «возьмём систему, которая не работает»?

Все исходят из того, что багов нет. Закладываться на баги в системе изначально некорректо. Что вы собираетесь вывести из начального условия «возьмём систему, которая не работает»?

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

Мы можем вылизать код, отвечающий за RAID, и считать, что багов в нем нет.

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

Решение простое - мы выносим все, что связано с обслуживанием массива, на отдельный контроллер со своими процессором и памятью. И теперь нам все равно, что там пользователь на CPU крутит, на работу массива это никак не влияет.

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

«Решение» тут - громко сказано. Вы перенесли проблему на другой уровень, но не избавились от неё.

Вы перенесли проблему на другой уровень, но не избавились от неё.

Как это не избавился? У меня процессор, ответственный за обслуживание массива, выполняет только код, реализующий алгоритмы RAID. Есть возможность полностью вычистить данный код от багов.

И главное, функционирование массива больше не зависит от того софта, который пользователь гоняет на CPU. Любые ошибки в нем, вплоть до полного зависания компьютера, никак не повлияют на целостность массива (именно массива, не данных).

детский сад какой-то :)

детский сад какой-то :)

Очень аргументированное сообщение :).

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

В принципе рациональные зёрна у него прослеживаются, но еле-еле и тонут в большом количестве воды, в то же время он уверен, что остальные занимаются «ловлей блох». Требует аргументации, а сам сплошь и рядом манипулирует понятиями «мое мнение, мне представляется». Придирается к смешиванию разных понятий, а у самого «btrfs по таймауту пишет», и т.д.

он уверен, что остальные занимаются «ловлей блох».

Ошибку про ловлю блох я уже признал. Слишком уж радикально SSD все поменяли ;).

мое мнение, мне представляется

Не люблю говорить за всех ;).

ssd ничего не поменяли в этом плане.

ssd ничего не поменяли в этом плане.

Смотрите выше вот это сообщение - здесь все очень грамотно расписано.

и как это относится к компрессии и ловле блох?

и как это относится к компрессии и ловле блох?

Это говорит о том, что я был не прав - ловлей блох компрессия является при размещении файловой системы на массивах из HDD. При переходе на SSD ситуация меняется просто за счет того, что разница производительности между HDD и SSD около двух порядков...

Остается, правда, второе возражение по поводу зависимости файловой системы от CPU (см. выше).

райзер можно, конечно, попробовать. Но ntfs-3g — это тормоз, а раскошеливаться парагону на нативный я пока не готов.

Я какбэ припоминаю, что по тестам ntfs-3g очень и очень крут. Но могу ошибаться

Я так понял, что btrfs пытался на свободных местах в ext4 создать свои структуры данных и где-то потерпел фейл. Исходные данные он не тронул.

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

Если действительно не хватает IOPS, стоит подумать о SSD

может лучше RAID?

ловлей блох компрессия является при размещении файловой системы на массивах из HDD.

да ты совсем тугой. система с hdd точно также получает выигрыш в виде уменьшения io (если данные сжимаются), как и с ssd. в тех же базах данных компрессия давно применяется.

Остается, правда, второе возражение по поводу зависимости файловой системы от CPU (см. выше).

это которое про порчу фс от iowait? да, поржал.

ловлей блох компрессия является при размещении файловой системы на массивах из HDD

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

может лучше RAID?

См. выше расчеты производительности. Грубо говоря, чтобы догнать средний SSD, Вам потребуется массив на сотню дисков.

Так что если и RAID, то на SSD ;).

система с hdd точно также получает выигрыш в виде уменьшения io (если данные сжимаются), как и с ssd.

Конечно. Только там выигрыш меряется долями процента ;). Что и называется ловлей блох.

да, поржал.

Говорят, полезно для здоровья, только вряд ли поможет Вам, когда придется поднимать данные из бекапа ;).

Сэкономить на вращении дисков и дергании головок - это блохи?

Угу, можете сами посчитать. Вклад FS в общее время IO практически незаметен на массивах HDD (если, конечно, в массиве не сотни дисков).

Только там выигрыш меряется долями процента

ты совсем дебил?

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

вечер_очешуительных_историй.jpg

Вклад FS в общее время IO практически незаметен на массивах HDD

ещё раз, каким боком вклад fs к компрессии?

См. выше расчеты производительности. Грубо говоря, чтобы догнать средний SSD, Вам потребуется массив на сотню дисков.

И процессор размером в шкаф %)

Вообще, чтобы дисковая система не была бутылочным горлышком достаточно нескольких дисков, имхо.