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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программные зеркала используются достаточно широко последние лет 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 (см. выше).

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

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

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

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

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

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

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

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

да, поржал.

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

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

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

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

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

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

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

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

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

Прямо, интересная какая-то бухгалтерия получается. Итак, если ФС издаст в 2 раза меньше I/O запросов, то никто этого не заметит? Где же такому учат, неужто в СПбГУ?

Итак, если ФС издаст в 2 раза меньше I/O запросов

Как Вы себе это представляете? Считаете, что при компрессии в два раза во столько же раз сократится потребность в IOPs?

во столько же раз сократится потребность в IOPs

Что за потребность такая? Кто требует?

У вас получается, что если диск не догрузили IO-запросами до какой-то его «потребности», он будет продолжать вращаться?

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

Это с чего, если сильно уменьшается объём записи ? Как раз на SSD это меньше заметно будет.

У вас получается, что если диск не догрузили IO-запросами до какой-то его «потребности», он будет продолжать вращаться?

Извините, не понял, о чем Вы. Что за потребность диска? И как он может перестать вращаться? Просьба по-человечески переформулировать вопрос.

Это с чего, если сильно уменьшается объём записи ? Как раз на SSD это меньше заметно будет.

В реальном мире многозадачных и многопользовательских систем мы имеем дело практически исключительно со случайным доступом к данным (куча приложений постоянно дергают диск). А при случайном доступе IOPs слабо коррелируют с объемом записи. Т. е., скажем, двукратная компрессия не приведет к двукратному же сокращению IOPs что при записи, что при чтении...

А при случайном доступе IOPs слабо коррелируют с объемом записи. Т. е., скажем, двукратная компрессия не приведет к двукратному же сокращению IOPs что при записи, что при чтении...

пипец ты всё-таки дэбил. во-первых, напрямую коррелирует и зависит от размера блока и кол-ва этих самых iops. во-вторых, приведёт - надо системе записать 80кб, при размере блока 4кб надо сделать 20 операций io, но система пожала это в джва раза до 40кб и, о чудо, теперь надо сделать только 10 io. потребность в io сократилась в ДЖВАБЛЕАТЬРАЗА.

приведёт - надо системе записать 80кб, при размере блока 4кб надо сделать 20 операций io, но система пожала это в джва раза до 40кб и, о чудо, теперь надо сделать только 10 io. потребность в io сократилась в ДЖВАБЛЕАТЬРАЗА.

Вы неправильно считаете. FS жмет данные на уровне файлов. Рассмотрим два варианта. Первый - Ваш пример, когда есть файл размером 80 kB, FS сжала его до 40 kB. Запись будет последовательной, здесь Ваша арифметика имеет смысл. И то только в том случае, если параллельные запросы диск не дергают (файл за один заход пишется).

И вариант, более близкий к реальности - большой файл с таблицами БД. Модификации таблиц требуют случайной записи в разные области файла. При этом для каждой модификации файл надо сначала расжать, потом снова сжать перед записью. Здесь никакой корреляции между IOPs и степенью сжатия не будет.

Ваш спор напомнил мне одну известную присказку — «я ему про Ивана, он мне про болвана».

И вариант, более близкий к реальности - большой файл с таблицами БД. Модификации таблиц требуют случайной записи в разные области файла. При этом для каждой модификации файл надо сначала расжать, потом снова сжать перед записью. Здесь никакой корреляции между IOPs и степенью сжатия не будет.

Т.е. Вы утверждаете что при апдейте скажем миллиарда записей, после каждой модификации файл БД будет разжиматься и снова сжиматься?

Ваш спор напомнил мне одну известную присказку — «я ему про Ивана, он мне про болвана».

Угу, у меня точно такое же ощущение - все аргументы уже по третьему кругу идут...

Т.е. Вы утверждаете что при апдейте скажем миллиарда записей, после каждой модификации файл БД будет разжиматься и снова сжиматься?

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

все аргументы уже по третьему кругу идут

нет у тебя никаких аргументов. приведи хоть одно обоснование своего бреда.

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

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

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

Приоритет ядерных тредов выше же.

откуда этот дебил может это знать?

Это потому, что вы не понимаете аргументов друг друга и доказываете вполне очевидные вещи, но разные!

Возьмём, для примера, файл размером 1 МБ и некий девайс с такими параметрами: размер блока - 1 КБ, скорость записи - 1 МБ/с, скорость операций в/в - 1К io/с.

Пишем файл без сжатия:

(1) время записи 1/1=1 сек

(2) кол-во операций 1М/1К=1К

(3) кол-во операций в сек = 1К

Пишем с сжатием 2:1:

(1) = 0,5 сек

(2) = 0,5 К

(3) = 1 К

Вы доказываете пункт (3) и Вы правы, а аноним пункт (2) и он тоже прав! :)

Спасибо, похоже, Вы правы ;).

Это потому, что вы не понимаете аргументов друг друга

Это потому, что оппонент мягко говоря не в теме.

Вы доказываете пункт (3) и Вы правы

что тут доказывать? что при неизменном размере блока максимальное кол-во iops тоже неизменно? так это к делу и не относится и только полный профан будет пытаться это доказывать, особенно в свете изначального тезиса об уменьшении io в случае применения компрессии. зы специально для одарённых Serge10 - в первом случае ты за 1000iops передашь 1мб, во втором за те же самые 1000 iops ты передашь 2мб, если ты и этого не понимаешь и это по твоему не сокращение потребности в io, то тебе самое место в начальной школе.