> Ну вот и поставь Btrfs в аналогичные условия.Аналогичные кому? Чему? Цель измерений? Вы вообще понимаете как это работает?
> Создай том из нескольких дисков, на нём большой файл и замерь скорость удаления диска.
По такому описанию я могу замерять что угодно. В любую сторону. Например, результат основательно зависит от числа дисков в конфигурации и % использования емкости.
Как простой пример, жил был системный диск. Механический. На 2 Тб. В пару ему такой же добавили, собрав в результате RAID1 порядка 2 Тб. Всего там несколько гигз было и рестрайп из single -> RAID1 занял жалкие считанные минуты. Потом диск захотелось утащить под другие нужды и RAID был превращен в single. Это тоже заняло несколько минут. Ну и вот за считанные минуты 2-терабайтный диск был вынут, просто потому что реальное использование было ессно и близко не 2 Тб.
А могу совсем наглый чит, с коэффициентом уделывания близким к бесконечности. В btrfs можно рестрайп делать не "жестко", а "мягко" - запросив тип для НОВЫХ чанков. Так все новые данные которые записывают с этого момента - будут в новом формате, а старые - останутся как есть. При этом в пуле будет смесь разных схем RAID. На самом деле это могло бы быть чуть не пофайловым решением - какую схему хранения тем блокам давать, дизайн так может, просто алгоритма таких решений для аллокатора нет. При вон той "конверсии типа RAID" - время операции крайне близко к нолю, так что win относительно более классических схем по времени приближается чуть ли не к бесконечности. На самом деле это конечно лишь доразвитие стиля CoW чуть дальше, но так можно было. И это может быть очень драматическим отличием от более классических схем по временам операций. Разумеется, есть нюансы. Скажем на полностью забитом диске никакого выигрыша относительно блочного райда не наступит. Если понимать вот эти фичи дизайна, можно ими пользоваться себе во благо. А еще, в дизайне где может быть смесь уровней RAID (данные и метаданные совершенно штатно могут иметь разную схему хранения даже без вон тех фокусов), сжатие, мульти-референстутые экстенты снапшотов и рефлинков, файлы с "дырками", и все такое - ответ на вопрос "сколько места свободно?" становится довольно интересным аспектом.
> От файлух требуется эффективно управлять дисковым пространством.
В случае RAID вынос его на файловый уровень основательно поднимает эффективность ряда операций, когда вместо жевания вон тех 2 терабайт от и до по всей площади оно удвинуло с диска несколько гигз которые есть за считанные минуты - и отдало мне диск из пула. Ну а на более классическом райде рестрайп 2-терабайтного пула на механических дисках будет оооооочень неспешной операцией. Если так вообще получится без разбора пула и сноса данных. Вон то видите ли нонстоп, при этом система работает, данные доступны.
> То есть, компактно хранить данные и быстро проводить файловые операции,
> а также операции над томами.
Ну и вот в части операций над томами, а точнее, пулом, в плане его увеличения, уменьшения, смены схемы хранения и проч btrfs может дать мастеркласс любой другой вундервафле. Это менеджмент как он должен быть, простой, ненапряжный, позволяющий использовать то что по факту есть без камасутр с выравниванием. А основанность на именно ФСовском уровне позволяет этому всему знать какое место используется а какие регионы можно совсем не трогать, что в случае частичной занятости зачастую крайне радикально ускоряет операции менеджмента с пулом.
И еще снапшоты. В итоге железный хост можно менеджить почти как VM - с множественными снапшотами состояний (даже writeable!), увеличить-уменьшить стораж когда надо, без особых напрягов, или даже рестрайпнуть в другую схему хранения. Без останова.
> Остальное - это соревнования балерин по метанию молота.
Не, вот извините! Пожив с снапшотами я уже на меньшее как-то не согласен. Всегда мечтал менеджить мои железки в стиле виртуалок. Или вот DUP на однодисковых конфигах мне очень нравится. Одно дело - кончина ОС, от 1 бэда, когда системная либа не прочлась и даже не грузится, и совсем иное - "csum failed .... corrected" при том же самом эвенте под той же либой - когда оно проблемный блок просто вынет из 2 копии в другом месте девайса, вероятность что и он тоже порушен - крайне маргинальная в реалистичных ситуациях типа 1 бэда раз в сколько-то (час..год). А еще как приятный бонус - отлично обнаруиживает сбойный хардвар, от гнилых SATA шнурков до глюкавых процов и чипсетов. Вопли "csum failed" извещают меня что проблема - есть. Очень на пользу безотказной работе систем.
Ну и еще я иногда data recovery балуюсь. Очень круто делать "копию" рефлинком чтобы какой-нить fsck гонять на нем. "Копия" чушки в пару терабайт делается за секунды. И ессно реально занимает только те блоки которые изменились. Примерно как CoW диски в VM по смыслу. Это конечно "thin provisioning" и реально там может и не быть места на полную копию, но мне и не надо, fsck какой не так уж и много блоков образа меняет. А если не получилось - окей, я сотру "провальную копию", сделаю новую, и попробую на ней другие подходы. Иными методами это все очень сильно медлленнее и требует супер-дофига места в сторажах, видите ли.
> Ненужно. См. выше.
Да им и снапшоты кажется не нужны. Остается только вопрос нафига рейзер нужен. Оверинженерии во, а бенефиты с этого - вообще какие? У btrfs понятно какие. Менеджмент хоста радикально улучшается и начинает по комфорту напоминать виртуалки, а если с умом пользоваться еще и выживаемость ОС улучшается, сбойное железо обнаруживается, и можно эффектные трюки рефлинками откалывать, типа "копирования" терабайтных чушек за секунды (для всех практических целей это ведет себя как независимая копия файла, хоть изначально и ссылается на блоки оригинала).
