Ох BTRFS, ну сколько можно - продолжение

Не всегда а когда растет.

У btrfs проблема не в снапшотах а из его постоянного cow. Поэтому cow на месте под виртуалку вырубают.

Извините я хз что такое pvesm. Как это выглядит через virsh?

А разработчики файловых систем за какую-то логическую фрагментацию переживают.

Какая логическая фрагментация ФС в контексте SSD? Окстись.

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

У btrfs проблема не в снапшотах а из его постоянного cow. Поэтому cow на месте под виртуалку вырубают.

Нет cow - нет снапшотов. Btrfs одна большая проблема, которую давно уже нужно дропнуть и не засорять ядро.

Какая логическая фрагментация ФС в контексте SSD? Окстись.

Она логическая. Какая разница, SSD это или что другое? Она не физическая, она логическая.

Дальше можно уже не читать то, что ты там понаписал - это всё отношения уже к теме не имеет. Загугли хоть чтоли.

Эээ… Как раз таки если под виртуалку - CoW никто в здравом уме не вырубает. Или не использует на гипервизоре эту ФС или понимает, зачем она ему и использует эти преимущества.

Вам стоит почитать про размер страниц SSD.

Ты про write amplification что ли? Какое отношение WA имеет к фрагментации?

Никакого. Это у тебя клоун на аватарке.

Размер блока чтения или записи очень редко кратен размеру страницы в физической памяти. Именно поэтому скорость случайного и последовательного доступа так отличается на любом SSD.

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

Чушь с точки зрения архитектуры SSD. На аппаратном уровне всё наоборот.

В nand-памяти операции чтения и записи выполняются на уровне страницы, а стирание на уровне блока. Блок всегда состоит из целого числа страниц. То есть размер блока всегда кратен размеру страницы.

Никакого. Это у тебя клоун на аватарке.

Ты же писал именно о WA, о несоответствии между логическим блоком файловой системы (например, 4 КБ в NTFS/ext4) и физической страницей nand. Это несоответствие существует и является причиной write amplification, но оно не означает, что блоки внутри SSD не кратны страницам.

Именно поэтому скорость случайного и последовательного доступа так отличается на любом SSD.

Неверно. Реальная причина в алгоритмах работы контроллера (предварительное чтение, сборка мусора) и накладных расходах на обработку команд, а не в физическом несоответствии размеров внутри чипа NAND.

Реальная причина в алгоритмах работы контроллера (предварительное чтение, сборка мусора) и накладных расходах на обработку команд, а не в физическом несоответствии размеров внутри чипа NAND.

Вот ты и согласен, что размещение физических данных влияет на скорость доступа. Дальше про фрагментацию — уже сам.

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

Нет. Нету read ahead при случайном доступе и это не связано с физическим размещением данных.

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

Нет. Нету read ahead при случайном доступе и это не связано с физическим размещением данных.

Я говорю: скорость случайного и последовательного доступа с переменным блоком отличается на любом SSD. Фрагментация имеет значение.

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

Я говорю: скорость случайного и последовательного доступа с переменным блоком отличается на любом SSD.

Отличается.

Фрагментация имеет значение.

Абсолютно никакого значения, ибо её, в контексте ssd, не существует.

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

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

Есть фрагментация внутри SSD и влияет ли она на скорость доступа и делает ли SSD дефрагментацию там у себя внутри, можно узнать только косвенно, с помощью тестов. Более того - это ещё зависит от модели диска. На промышленных дисках минимум алгоритмов, на десктопных делают всё, чтобы в тестах всё летало, а в реальности при непрерывной записи на диск скорость падает до 500-100 Мб/s. Этот вопрос достоин глубокого исследования, но мы его похоже не увидим.

а в реальности при непрерывной записи на диск скорость падает до 500-100 Мб/s.

SLC-кэш заканчивается и скорость падает.

Отличается.

Абсолютно никакого значения, ибо её, в контексте ssd, не существует.

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

, а в реальности при непрерывной записи на диск скорость падает до 500-100 Мб/s.

То есть ты просто не знаешь, как оно работает. И да, серверные тоже есть с SLC-кэшем. А есть с большим DRAM-кэшем. Есть с маленьким. И т.д.

но ты, похоже, не понимаешь, как оно работает вообще

Так, достал блокнотик, готов записывать. Излагай истину.

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

почему так.

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

Фак мой мозг. Почитай, как Read Ahead работает. А потом отключи у накопителя RA и попробуй протестировать ещё раз. У SSD, кстати, ReadAhead не применяется.

Фак мой мозг.

Это заметно.

У SSD, кстати, ReadAhead не применяется.

Применяется и даёт нехилый буст.

и даёт нехилый буст.

Применение Read Ahead на SSD приводит к избыточной нагрузке на его кеш и увеличении задержек при операциях случайного доступа. Буст оно дает только на последовательном чтении небольших блоков. Поэтому когда ты линейно читаешь данные с накопителя минуя ФС - прибыльности от Read Ahead нет. А вот если ты раз в полчаса читаешь по 4к последовательно - там таки задержка снизится на порядок. Уж очень специфичный случай ).

«царь», про что вещаешь? Про OS-level readahead или Device-level read-ahead? Мы тут за устройство разговариваем, а не про кривые механизмы linux. Расскажи лучше про фрагментацию на SSD, хочу свежий анекдот.

Про OS-level readahead или Device-level read-ahead?

У тебя мозгов так мало, что ты нить разговора уже потерял, да?

Вон судя по выходу Fedora 45, шапка заканчивает баловаться с btrfs и укрепляют lvm+xfs (читай стратис), так что как вариант btrfs скоро может захиреть.

P.S. надеюсь все помнят, btrfs получил скачок после того как его в федору запихали.

btrfs скоро может захиреть.

Ну те, кому нужен его функционал пойдут снова обмазываться ZFS. Bcachefs (которая мне безумно нравилась) теперь альтернативой не считаю. Ладно его из ядра выкинули, но после этого Кент каким-то говном начал обмазываться.

обмазываться ZFS.

Вот именно что обмазываться, пока ZFS в ядро не запихают в его сторону глядеть такое себе …

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

В ZFS так можно?

пока ZFS в ядро не запихают

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

В ZFS так можно?

Вполне. С той лишь разницей, что крупные линейные записи в кэш не полетят - они полетят сразу на харды.

Уже никогда не запихают.

Ну из этого на ZFS можно ставить крест, ну по крайне мере на серьезных серверах.

Вполне. С той лишь разницей, что крупные линейные записи в кэш не полетят - они полетят сразу на харды.

Ну тут я хз, в стратис просто берешь:

stratis pool add-cache mypool  /dev/nvme0n1

и этот ссд сразу становится кешам для этого пула (в котором уже хдд намешано) а что там куда летит я хз ;)

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

Вот ты не можешь без помочей настроить dm-cache, не то что примерно понять его работу. Но уже рассуждаешь о применимости ZFS в промышленных системах. L в LOR — localhost.

Вот ты не можешь без помочей настроить dm-cache, не то что примерно понять его работу. Но уже рассуждаешь о применимости ZFS в промышленных системах. L в LOR — localhost.

Ну это нормально, когда человеку нечего ответить он скатывается в личку.

Какую нить? Ты абсолютно не в теме и дуешь тут щёки. Это забавно, продолжай.