> При этом наиболее часто запрашиваемые блоки данных будут находиться или в ARC в памятиВнезапно, в линухе тоже есть дисковый кэш. И он тоже кэширует. Хоть и не часть ФС.
> или в L2ARC на SSD, где эта фрагментированность проблем не создает.
Внезапно, это - костыли тормозной файлухе. И какие-то кастомные применения. С туевой хучей допущений (что SSD - есть, что доступ к данным - существенно неравномерный, что SSD не протрется в 2 счета, etc).
А от ФС более-менее общего назначения хотелось бы чтобы она прилично работала и без столь феерического костылирования. Намного лучше когда администрирование не превращается в истошную борьбу с костылированием технических дефектов и слабых мест ФС, а применение ФС не требует ...цать пунктов в допущениях.
Например: у меня на ноуте - нет дюжины дисков и сотен рамы, их там просто некуда пристроить. Но это не значит что сжатие, снапшоты и т.п. мне там не пригодятся, например. Btrfs там если что - смотрится не сильно хуже EXT4 в общем виде.
> А ZIL значительно ускоряет sync writes, что обычно является проблемой для других FS.
Опять же - это не "фича", а всего лишь костыль, поскольку CoW в чистом виде оказывается тормознее классических ФС.
>> Зато когда наступит момент эти данные читать, нас будут ждать неприятные сюрпризы.
> Вас - да, потому что в BTRFS нет L2ARC.
А какие-то законы природы обязывают чтение всегда попадать в кэш? Обычно кэши сильно меньше чем стораж в целом (по причине дороговизны этого начинания) и поэтому половина операций всяко будет мимо кэша. И вот там мы знакомимся с нативной непрокостыленной скорстью ФС. И вот тут ZFS совершенно нечего нам показать. Достаточно посмотреть бенчмарки хоть против доисторической версии btrfs 4+ летней древности, чтобы понять WTF. С тех пор btrfs сильно оптимизнули, если что.
А так то да, теоретически можно собрать стораж из одних SSD а лучше оперативы. Он будет быстрый как ракета. И стоить будет тоже как ракета...
> Но в общем случае, если данные пишутся рандомно,
> они потом и читаются тоже рандомно, так что фрагментация файла
> на это сильно не влияет.
Фокус в том что они будут читаться "рандомно" даже при линейном чтении (e.g. бэкап базы). Поэтому в вашем случае - линейное чтение вообще никогда не наступает. Здорово придумано.
>> Вот с этим у Reiser4 не задалось.
> Да и с BTRFS тоже не все так однозначно.
Вот сановских фанатов ZFS забыли про однозначность спросить. Поэтому они нам тут вещают какую-то лапшу на уши, полученную от экспертов Шишкиных. Пользуйтесь ФС от эксперта Шишкина тогда, раз вам он такой авторитет ФСостроения. И затыкайте технические недостатки маркетинговым булшитом, как сани завещали. А мне почему-то так не нравится. И хочется универсальную ФС с приличными свойствами, чтоб не надо было адово костылить все продолбы архитектов постоянно, да еще с кучей левых допущений, зарубающих половину сценриев использования.
> Файловая система получилась система сложнее чем ZFS.
Где-то сложнее. Где-то проще. Мэйсон посмотрел на то как делают другие и выбрал свой набор решений и компромиссов, учтя типовые проблемы. Мне в целом его ход мыслей понравился. Он пытается сделать настоящий next gen, где типовые грабли администрирования - превратятся в простые, удобные и логичные процессы. Это очень хорошее мышление архитекта. Это не какие-то абстрактные 128 битов, "потому что маркетологи сказли что 128 лучше чем 64", которые мне в обозримое время некуда прикрутить. А фичи и перспективы которые мне пригодятся и которые я понимаю как и где применить. И понимаю что то что раньше было гемором с разбором пула и тасованием терабайтов данных - теперь будет тривиальным простым процессом. Без остановки работы завязанных на это систем вообще. Возможность плавной, фоновой реконфигурации более-менее большой хранилки на ходу, без остановки - это круто и актуально, будь то добавление или изъятие девайса, изменение схемы хранения или что там еще. Я имею наглость полагать что Мэйсон в курсе основных проблем администрировния таких вещей и изволил учесть наиболее назойливые проблемы, в отличие от остальных.
> В BTRFS сделали экстенты и это привело к большому количеству сложных проблем.
Вот что-что а по линии экстентов - никаких чрезмерных проблем там не было вроде. Да и в целом - проблем там не больше чем у всех остальных. А производительность при прочих равных заметно втыкает ZFS'у. Потому что меньше операций с метаданными в ряде случаев. На то и экстент чтобы одним махом адресовать большой регион как хотелось, а не колупать его отдельными мелкими блоками. При более-менее типовых сценариях экстенты ощутимо втыкают блочным аллокаторам. По поводу чего все новые дизайны ими и пользуются. Несомненно, можно подобрать краевые случаи, когда экстентная механика будет работать плохо. Но это обычно чистая синтетика. Синтетическими извратами можно поставить в позу любую ФС.
> Снапшот - это бекап.
У, как все запущено. Снапшот - это ни в одном глазу не бэкап. Это совсем иная технология (в плане рабочей механики) и кроме всего прочего - НИ РАЗУ НЕ ЗАМЕНА БЭКАПА.
> Если "откате снапшота процессы базы по дефолту
> никто не перезапускает" - Вы не понимаете как работает база данных.
Я понимаю как работают снапшоты. И в курсе что руление снапшотами само по себе вообще никак не связано с базами, ФС сильно пофигу: базы там или что-то еще. И что снапшоты не бэкапы и ни разу не замена бэкапов - я тоже в курсе. В отличие от некоторых. Которые кажется не понимают базовые основы всей этой механики и достаточно глупы чтобы считать снапшот бэкапом. Которым он ни разу не является.
Если кто не понял: при повреждении по той или иной причине блоков на диске, снапшот может чудесно развалиться. Вместе с файлом-оригиналом. И другими снапшотами. Развалится все что совместно использовало порушенные блоки, вся цепочка. По этой причине снапшоты не являются заменой бэкапов ни в одном глазу - это доступ к множественым состояниям ("истории") ФС. Снапшоты и "оригинал" от которого они произошли совместно юзают ряд блоков. Разрушение shared блоков сделает бесполезной всю цепочку. А дедуп, если что - всего лишь очень частный случай этой механики с множесвенным референсом блоков. Поскольку оно по любому есть для того чтобы снапшоты делать, до кучи можно "почти халявно" дедупликацию прикрутить (вся механика для этого уже есть, остается только обнаруживать дупы и заменять их ссылками, точно так же как снапшоты референсятся на неизменные блоки по нескольку раз).
> Лучше они себя ведут в ext4 и XFS, где нет CoW и можно переписывать данные in-place.
В случае перезаписи in place в классике - аллокатор по идее не делает чуть менее чем ничего: размещение файла вообще не меняется.
> В BTRFS экстенты выглядят как попытка скрестить ужа и ежа,
> в результате чего - получается три метра колючей проволки.
В btrfs во первых, экстенты делают что и должны - позволяют адресовать большой регион компактной записью в метаданных. Что как и обычно повышает скорость работы ФС при прочих равных в более-менее типовых условиях. Так что когда ZFS проcacывает на очередном бенчмарке в одинаковой конфигурации - это является одной из причин.
Во вторых, если CoW какой-то из нагрузок мешает жить - его можно выключить и получить этот самый in-place patching. Базы данных будут рады. И приветы ZFS, ага :)
>> YOLO! Вы не поняли как CoW в ФСах обычно работает :).
> Нет, я спрашиваю как CoW будет работать в конкретной FS
> по имени BTRFS при использовании там экстентов большого размера.
Именно так как это было бы логично и ожидаемо. Нет, КОПИРОВАНИЯ большого блока там не будет.
> Чтобы вопрос был более понятным: экстент - это такой достаточно большой блок данных,
> который адресуется одним куском.
Спасибо, капитан.
> если надо переписать небольшой блок внутри большого экстента - копировать весь экстент?
Зачем? CoW может делать то же что и обычно: вписать *изменения* в область *свободного места*. И поправить *метаданные* описывающие все это. Так, чтобы новый вид файла - строится с учетом того что вон ту часть теперь надо брать в вон том новом месте, а не где-нибудь еще. В каком месте тут должна быть bulk-операция с данными? И кто сказал что старый вид файла (и экстент который вы хотите порушить) перестал требоваться? Это весьма зависит от наличия снапшотов и чего там еще и по умолчанию в CoW нет такого понятия как "переписать конкретный экстент/блок" в том плане что это внутреннее дело ФС и может референситься несколько раз (из разных снапшотов или чего там еще) и поэтому у вас логическая ошибка сразу на старте - в некорректной формулировке пожелания. Вы не хотите переписать экстент. Вы хотите переписать эн данных в файле таком-то по смещению такому-то. Для CoW это сигнал: сделай выносок размером эн и поправь метаданные так чтобы текущий вид файла строился с учетом этого выноска.
Сишники которые любят механику с указателями и эффектные фокусы типа перекидывания указателей с zero copy - должны бы заметить что идея подменить работу с блоками/экстентами на манипуляцию метаданными им что-то напоминает и является подвидом той же оптимизации, непонятной более высокоуровневым существам. Внезапно, вместо кантовки дофига данных можно исправить лишь описание адресации :)
> А в метаданных у BTRFS всего одна ссылка на экстент размером в
> 128 мегабайт. Каким образом в такой ситуации BTRFS сделает CoW операцию модификации блока?
По логике вещей запишет изменения в пустое место и отапдейтит метаданные так что новый вариант файла будет браться с учетом этого выноска. При этом есть только операции с метаданными, но никакие уймы данных не лопатятся. И в общем случае все это очень прилично работает. Но как и у любого дизайна ФС есть некоторые частности когда все это работает не очень хорошо. Базы данных и СoW диски виртуалок, имеющие свои понятия о журналах и желающие видеть in-place patching - один из таких частных случаев.
> Будет делать перебалансировку дерева и начнет разбивать один большой экстент
> на несколько мелких? Тогда понятно почему при обычной записи данных там вдруг
> начинают расти в объеме и метаданные и все это в конечном итоге очень сильно тормозит.
Поздравляю, вы наконец начинаете понимать tradeoff стоящий за алгоритмами на основе CoW. У CoW всегда растут метаданные при перезаписях. Выносков становится больше, описание этих выносков неизбежно занимает место. Получается избыточный оверхед + фрагментация. Поэтому CoW как дизайн и не дружит с нагрузками ориентированными на частый быстрый in-place patching типа БД и CoW-дисков виртуалок.
А блочные аллокаторы, если что, тормозят вообще всегда из-за колупания с блоками вообще независимо от того как идет аллокация. Они всегда колупаются с всеми затронутыми блоками. А экстенты - вариант как "сжулить" и отметить большой регион более компактно и быстро, не помечая вообще каждый блок региона. При очень большом числе очень мелких фрагментов экстентную механику можно ушатать до уровня блочного аллокатора, а может и хуже. Но чаще всего оно работает сильно лучше.
И да, в btrfs на случай неудачных ворклоадов есть отключение CoW. В отличие от ZFS. Где такой ворклоад получит свой in place patching, просто и быстро, а ФС не будет давиться кучей выносков. Оракл не зря БД занимается и явно попросил архитекта учесть проблему, наевшись счастья с ZFS. Тот учел.
> В результате - имеем громадный оверхед или по данным, если копируется весь экстент
Не вижу смысла копировать весь экстент. Это зачем? Он и так уже есть и на него можно референситься. Более того - на него может уповать какой-нибудь снапшот, etc.
> придется хранить две копии метаданных, которые достаточно сильно отличаются,
> для снапшота и для модифицированного файла.
Если это частая интенсивная операция, как в БД и дисках виртуалок - CoW в btrfs отключаем, пофайлово. У CoW есть неудобные ворклоады. Куча выносков - это в любом случае плохо по оверхеду и скорости. Ну вот оракл и попросил. А в ZFS такой рукоятки нет.
Так понятнее почему оракль скорее всего пошлет ZFS в пешее эротическое? Не друг оно их базам, на уровне дизайна, за что и пострадает ;).
> Если экстент не копируется - тогда будет очень много возни с метаданными.
Вы начинаете догадываться о том что любой tradeoff имеет сильные и слабые стороны. CoW плохо относится к нагрузкам типа БД, это в любом случае куча выносков и их описание. Если выносков огромное количество - работать все это будет не ахти.
Сани... рассказали что в пул надо вовремя дотыкать диски (когда пул занят на >80%, CoW механика может откровенно сколлапсировать, не имея возможноть размещать выноски непрерывно и испытывая чуть ли не экспоненциальный рост числа фрагментов). Без возможности вынуть диски, хе-хе. А деградацию производительности от кучи выносков при долговременной эксплуатации - замяли тихой сапой, предпочтя ничего не говорить про это.
Был тут кадр - Изен. Он догнал свой ZFSный пул до 20Мб/сек с 3 дисков путем забития в ноль. Ну то-есть около 6Мб/сек на диск. Что довольно х..во даже для ноутбучных дисков которые он взял.
В btrfs - сделали дефрагер который может попытаться линеаризовать размещение (а потом можно и адресацию оптимизировать, линейные регионы адресовать легко).
Вот как-то так и получается что саночники подло молчат о невкусностях дизайна. А Мэйсон вместо впаривания фуфла тихой сапой - идет и решает сложные инженерные проблемы. Даже если для этого и надо попахать. Мне так больше нравится.
> На всего лишь одну операцию модификации одного блока данных. Неоптимально.
CoW вообще неоптимален для нагрузок хотевших in place patching. И оракл похоже очень хорошо это понимает, в отличие от фанов впаривающих ZFS лохам.
> и нет большого количества проблем с ними связанных,
Ога, конечно, там все инженерные проблемы компенсируют громким маркетинговым булшитом. Сперва маркетологи, потом подхватившие волну фанаты марки. Ну а вот лично я - не понимаю зачем бы мне себя обманывать относительно свойств дизайна.
> так что ZFS выглядит как более простая и более надежная FS.
ZFS выглядит как ФС где по жизни вместо решения сложных инженерных проблем (типа деградации от фрагментации при долговременном использовании) - лишь громкий маркетинговый булшит. И можно или долго прыгать, пытаясь обкостылить проблемный дизайн до состояния когда он сносно работает или получить результат а-ля изен, если не париться, после чего истошно убеждать себя что "мне хватает!" :)
>> Ога, тут весь форум забит радостями от аппетитов дедупа :)
> Если в компе мало памяти или слабый процессор - тогда zfs_dedup будет тормозить.
Спасибо, капитан.
> Я ж говорю, ZFS - это система из будущего.
ZFS - это первая серьезная попытка сделать CoW-based. В процессе наломали немало дров и сделали довольно спорный пепелац. Будущее у такого дизайна - на кладбище космических кораблей, имхо.
> На мощных сановских серверах это будущее уже наступило
Маркетинговый булшит - это как-то так :). Не говоря о том что фирмы Сан уже несколько лет как нет с нами.
> и там zfs_dedup работает наиболее оптимальным способом.
Вы случайно не маркетолог из сана? :)
> Для дедупликации 1 терабайта данных необходимо всего 1 гигабайт памяти. И процесор.
Ога. Всего. Если это файлсервер - может куда ни шло. И то - многие вырубают фичу, т.к. выигрыш не компенсируется потреблением ресурсов. А для остальных применений...
> быстрее, чем скорость ввода/вывода
Расскажете это вон тем NVM Express-ам, да? ;)
> Даже если это делается путем переусложнения кода
> и как разультат - наличия трудноуловимых багов ?
А санки просто положили на ряд сложных инженерных проблем. Сделав из проблем инженеров проблемы пользователя. А мне это надо? Сановские врунишки так забавно юлят на вопросы о деградации производительности при долговременной работе пула, стесняясь уточнить что в их кульной ФС просто нет решения этой проблемы и это - проблемы обладателя пула, влопавшегося в это :)
> и с этим ZFS справляется очень хорошо.
Понятия о хорошем - бывают разные. По большому счету ZFS - файлуха для выделенных файлопомоек. Для всего остального она выглядит довольно субоптимально.
> В BTRFS - акцент смещен в сторону добавления
> большого количества различных возможностей, из-за чего надежность хранения страдает.
В btrfs акцент смещен на то чтобы это была универсальная ФС с более-менее адекватными параметрами. Не перепихивающая сложные инженерные проблемы с програмеров на админов.
> А в ZFS стало хуже работать и новые возможности стали недоступны?
Появился duplicate (для многих систем) код, а новые возможности ... какие там новые возможности по части RAID? Весь традиционный гимор с нуждой все разбирать и конвертить пул целиком вроде никуда не делась. А вот у Мэйсона вся архитектура заточена на плавный фоновый майнтенанс, который можно делать без ущерба всему остальному и не превращая это в гемор для администратора.
> ZFS начали делать в 2001 году, менеджер томов появился в SunOS в 1991 году.
Тогда еще менее понятно в чем пойнт. А что этот встроеный менеджер собственно такого уникального дает, чего нельзя было сделать системным? В btrfs понимаю что - пообъектные уровни RAID в перспективе, разные уровни RAID для данных и метаданных уже сейчас, гибкость в конверсии уровней и конверсия на ходу.
> При том что там нет L2ARC и придется использовать сторонние решения, например, LVM Cache.
Не вижу очевидных технических недостатков этого решения. Если оставить субъективизм за бортом - вроде решение как решение.
> Все с точностью до наоборот.
> В ZFS используется RAID-Z: http://www.stableit.ru/2010/08/raid-z.html
> В BTRFS используется обычный RAID5/6: https://btrfs.wiki.kernel.org/index.php/RAID56
В btrfs в принципе можно использовать любые схемы хранения. И со временем скорее всего сделают и иные. И нет, они не "обычные". Например, ширина stripe (в плане количества затронутых девайсов) как таковая там не обязана быть фиксированной. Это "variable-width RAID".
Например, место на некоторых девайсах может кончиться раньше чем на остальных. А кто сказал что все девайсы одинаковой емкости? Это опять какое-то левое допущение? К которому вы привыкли с эпохи царя гороха? А можно ведь сузить группу stripe-ов и записать очередную группу блоков на менее широкий набор девайсов. У btrfs есть потенциал рациональнее использовать доступное свободное место, когда носители - разного объема. И вообще не фачить админу мозг дурными ограничениями вида "все девайсы одного размера".
Скажем если есть 2 диска по 1Тб и 1 диск на 2Тб - btrfs может это рассмотреть как зеркало на 2Тб. У всех блоков будет по дополнительной копии на другом диске, но дискам совершенно не обязательно выравниваться друг на друга - btrfs плевать на все это хотел.
Btrfs не использует упрощенный маппинг 1 в 1 и hardcoded решения о том какой это будет уровень RAID. Вместо этого используя chunks и run-time решение о том как размещать вот эти данные. С архитектурной точки зрения - это совсем иной подход. Когда есть девайсы и свободное место на них. И есть запрошенная схема размещения. Если есть достаточно девайсов с свободным местом - происходит запись с запрошенной схемой хранения.
Пока не все из этого сделано полностью. Но вот это - выглядит как настоящий next gen в организации RAID. И вот в этом случае я еще могу понять зачем надо менеджер томов в ФС - выигрыш говорит за себя сам. А "просто очередную схему хранения" можно и в системный менеджер томов прикрутить, если что.
> Ключевое отличие ZFS от BTRFS - это наличие/отсутствие уязвимости "write hole".
Ключевое отличие ZFS от BTRFS - это громкий маркетинговый булшит, с игнорированием технической составляющей и перспектив дизайна.
> В результате, используя BTRFS и RAID 5/6 - невозможно получить надежное хранение данных.
Это откуда такой вывод? oO
Вариант для распечатки
(??) on 22-Апр-15, 14:17 
