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