>>Ничего. Минимальной единицей выделения у них все равно является блок, на x86
>>- чаще всего 4К (по размеру страницы).
>
>И что дальше? ZFS тоже может юзать мелкие блоки. И? :) ZFS может использовать блоки размером от 512 байт. И?
>>Так что при определенных условиях ext4 может ничем принципиально не отличаться от ext3.
>
>Ну так то же самое можно сказать и про ZFS вероятно. Грубо
>говоря если хочется распихать 128К данных а непрерывных 128К областей найти
>вдруг не удалось (а иначе какие проблемы то пхнуть 128К областью?)
Просто если выделение места осуществляется все время блоками по 128К - то есть неплохие шансы, что среди вновь освобожденных блоков будут нужные размеры, и их можно будет использовать.
>- вариантов вижу два. Вариант номер раз - разбить на более
>мелкие куски и распихать хоть куда-нибудь, раз уж том так засран
>- тут уже не до крутых оптимизаций, хоть куда бы распихать
>и разрулить запрос. Вариант два - совсем завернуть запись как технически
>невозможную. И хотя оба варианта хреновы, первый имхо предпочтительнее.
В некоторых случаях может быть и наоборот, но в больщинстве случаев первый вариант предпочтительнее.
>А ZFS что при этом сделает? Внезапно родит из вакуума свободного местечка чтобы
>разложить непрерывный блок? Или чего? Ну или чем таким его поведение
>в таких ситуациях будет отличаться в лучшую сторону? И собственно а
>из-за чего?
ZFS соберет блок нужного размера из блоков меньшего размера, при этом этом уровни выше SPA даже не будут об этом подозревать. Так что не переживайте, все будет в порядке. Кстати, политику выбора блоков в таких ситуациях можно легко поменять - можно не пытаться искать размеры побольше, а просто идти последовательно, пока не наберется нужный размер.
>>Может. ext4, да и даже UFS2 в FreeBSD это собственно и делают.
>
>А что, в UFS2 уже родили экстенты, чтобы такие фокусы были более-менее
>эффективны?
Для этого не нужны экстенты - нужно просто выделять блоки последовательно, если есть такая возможность. UFS2 делает именно так. При этом уже даже блока в 128K достаточно для работы с современными дисками на скорости пластин диска.
>Они ж вроде заломались переделывать классическую структуру ФС чтобы сэкономить
>на кодинге? Как я понимаю, затея с экстентами по физическому смыслу
>в принципе похожа на те же самые блоки переменной длины но
>с очень крутыми диапазонами длин (в EXT4 до 128 мегов на
>экстент, если не глючу)
Похоже, да.
> и достаточно компактной записью в метаданные по
Да, если экстентов мало и они большие. Если их много и они маленькие, метаданных может понадобиться много.
>этому поводу, с весьма хорошим соотношением между размером данных и метаданных
>в большинстве случаев, и обработка таких структур достаточно быстрая.
Ага, пока не понадобится,например, сжатие. Как только понадобится сжатие, лучше оперировать логическими блоками фиксированного размера, сжимая их по одному - это позволяет просто реализовывать seek по сжатому файлу. В случае же одного большого последовательного сжатого экстента перемещение в конец файла будет ну очень небыстрой операцией.
>А попробуйте объяснить мне глобальную физическую/логическую разницу между блоками переменной длины и
>записи в виде экстента, например? Собственно а что если рассмотреть экстент
>как этакий блок переменной длины с очень широким диапазоном размеров? При
>том в допущении что ФС должна стараться пихать данные не очень
>фрагментированно - с экстентами получается заметно эффективнее по метаданным и скорости
>их педалинга как правило :)
Да я уже запарился тебе объяснять. С экстентами получается эффективнее до тех пор, пока не начнутся сжатие и/или снимки/клоны. Про сжатие я уже сказал. Давай про снимки. Пусть у тебя есть один большой файл из 1 экстента в 128МБ и ты сделал снимок. Вначале снимок не отличается от состояния файловой системы. Предоложим, что ты захотел записать 1 байт в середину файла. Тебе нужно будет начать изгаляться, чтобы отразить сей факт - разбить один экстент на 3. При следующей записи еще раз и так далее и далее и даллее.
В итоге ты можешь получить херову уйму небольших экстентов. Не, можно конечно делать CoW эсктентами по 128МБ, то про пропускную способность при этом можно забыть.
>>Классической, жестко завязанной на кэш VM - да, не заслуга. Но кто
>>сказал, что не может быть других путей?
>
>Может быть и могут быть
Да не может быть, а есть. L2ARC например.
> Однако кардинально перекроить лэйаут ФС и избавиться
>от некоторых его странностей и упущений - несколько проблематично когда ФС
>уже вышла и юзается оравой народа.
Знаешь, какой сейчас текущий номер версии формата? 26, ЕМНИП. Так что не надо тут про проблематично. Очень многие вещи можно менять без особых проблем. А все, что касается политик - так вообще и без изменения форматов.
>>Начни с себя - перестань употреблять словечки вроде "обсирон" и им подобные.
>
>Собственно, я назвал ситуацию так как пришло в голову и отражает суть.
Если оно и отражает суть, то главным образом того, что ты не вполне в теме, поэтому недостаток аргументов компенсируешь цветистостью выражений.
>Это не является каким-то специальным наездом, просто не придумалось более емкого
>и меткого термина отражающего суть явления. Кстати это даже не наезд
>на конкретную ФС а всего лишь скорее описание некоей ситуации.
Мне уже изрядно набило оскомину. Можешь продолжать в том же духе конечно, но рискуешь оказаться в игноре. Так что хозяин - барин.
>Поэтому зря вы так нервно реагируете, имхо. Особенно учтя что неудобные ситуации
>можно создать практически любой ФС, идеальных то - не бывает ;)
Уж это то, поверь, я знаю и без тебя.
>>Есть вопросы - спрашивай, есть возражения - аргументируй, только по делу,
>>а не так чтобы потроллить
>
>Да, собственно, троллинг самоцелью не является. Как максимум иногда в процессе не
>сдерживаюсь и перегибаю с едкостью коментов. Вы тоже не паинька. Ваши
>симпатии видно невооруженным глазом ;).
Да я их и не скрываю, что не мешает мне трезво смотреть на другие вещи.
