> При желании можно и свинью заставить летать. Речь не о том, как
> заставить ФС встать колом, а о том, насколько вероятно, что она
> встанет в повседневной жизни.У меня в повседневной жизни дофига btrfs-а и он колом не встает. Меня устраивает.
И даже немного сабжа есть. Колом он тоже на мое счастье не встает, пару багов я видал, но ничего реально фатального. Но своими замашками с фс утилсами требующими "скачайте ночнушку!!111" кент сделал мою жизнь неудобной, и с учетом дропа ФС утилсов в моем дистро (которому тоже неудобна такая полися апстрима) - я склонен считать эксперимент интересным, но в целом - скорее неудачным, а с учетом ситуации с ядром все что юзало сабжа - отмигрирует на btrfs постепенно, там ничего ценного или критичного, обычные сервисные виртуалки, их легко отреспинить.
Видите, ALL не обязан жрать кактус ЛЮБОЙ ценой. И тут Кент как-то перегнул палку. Да, у него хорошая штука. Но это не делает его пупом земли, которому простят все и вся. Если он это не понимает - печально, но тогда зачем мне делать из этого свои проблемы?
> И в повседневной жизни я не создаю миллионы файлов в директории,
А я вот иногда могу от 50 до 300К забацать. С фига я должен ограничиваться хомячковыми сценариями при эксплуатации ФС я не знаю. Поэтому хорошую работу в моих сценариях я буду считать за фичу.
> и большинство файлов имеют ненулевой размер.
Пойнт в том что вычисления свободного места в ФС - в целом просто некая достаточно абстрактная цифра. Чем эта цифра в btrfs так уж хуже чем в других - я не придумал. Ну да, т.к. фич больше - больше причин чтобы эта абстрактная цифра разошлась с ожиданиями. Но я уже дал пару примеров как эти ожидания полностью обломать даже и на классике. Т.е. никаких качественных отличий нет, количественные - может быть, но эту историю начал точно не btrfs.
> Даже если бы проблемы с inode возникли, решаются они довольно просто и
> очевидно - удалением или перемещением файлов.
Вау круто, а если файлы нужны, мне наверное в ООН тогда писать петицию? Де факто статическая аллокация инодов - это визитка АРХАИЧНЫХ дизайнов. Это дурное наследие, никто более не будет новые дизайны по тем лекалам лепить.
> А с btrfs и ее филосовским отношением к свободному месту проблема может возникнуть
> именно при повседневном использовании.
По состоянию на здесь и сейчас, с более-менее современными дистрами и ядрами - это все бред сивой кобылы. Там на совсем пиковые случаи с неких пор сделали небольшой global reserve. В случае когда "everything failed" юзается место из него, так что даже откровенно провальная операция типа дописать для удаления файла - успешно завершится.
А еще - они сделали авто-GC блочных групп, по типу того что кент с buckets делает. И проблемы с резким изменением data/metadata ratio тоже в целом ушли. Понятно что предвидеть ВСЕ в сложном продвинутом дизайне было нереально, и какие-то траблы лезли. Но ваши знания 2010 года уже не особо актуальны. Да и тогда оно лезло лишь в специфичных случаях в которые ФС вообще не надо загонять, если перфоманс минимально интересовал. Т.е. забивка ФС более чем на 85-90% это создание кучи проблем аллокатору, дикая фрагментация и проч. В случае XFS при этом, вроде, нет никакого плана действий, кстати, а? У ext4 и btrfs есть какой-никакой дефраг.
>> Рефлинки... возможность референсить экстент более 1 раза.
> Рефлинк - этот тот же хардлинк, но с автоматическим COW.
Хардлинк по сути просто +1 имя у файла. Файл - inode, у которого есть 0 или более имен. Если имен 0 то по нормальной семантике файл unlinked и деллаоцируется (когда его все закрыли). O_TMPFILE может немного поспорить с этим но это мало чем отличается от случая с inode где все имена отвязали но файл все же еще не закрыли и в ФС он еще держится, невидимый.
Рефлинк это довольно абстрактная штука. Он не существует как некая конкретная сущность и как это ФС делает - implementation defined. Все крутится вокруг 2 вызовов (ioctl):
1) "same extent" - хинт дедупликации, утверждиющий энной ФС что вот этот и этот экстенты - дубликаты и можно заменить вон того - референсом на первого. Получив такой запрос на вход ФС должна проверить что это и правда так - и заменить одну копию референсом на вторую копию. Заметьте - имена файлов тут никак не фигурируют, и это могут быть разные никак не связанные файлы, все что критично - чтобы это были 2 идентичные регионы. Тогда 1 из них может быть деаллоцирован и превращен в референс. Этот рефенерс внутреннее дело ФС и его нигде наружу никак не видно.
2) "clone range" - мы просим создать типа-копию региона файла с содержимым "как вот тут". Де факто ФС повесит +1 референс на экстент(ы) а если туда что-то потом запишут, обыграет сплит этого cow.
Это добро работает в режиме "best effort", у ФС могут быть свои идеи что она (не)может выполнить и то что запрос будет выполнен 1 в 1 как его программа выставила ниоткуда не следует, программе не видно внутреннюю механику произвольной ФС с этим и-фейсом, ФС лучше знает что она (не)способна обеспечить и как это будет выглядеть.
И получается забавно: запустив прогу дедупа у меня ... формальный размер суммы аллокаций файлов не меняется, а свободное место - растет. Потому что часть дубликатов заменили референсами.
> А то, что вы описываете - это как работает COW в btrfs.
Я описываю как работают 2 характерных ioctl, которые с btrfs'а потом содрали, видите ли, XFS (которого для этого каким-то чудом расперли на лимтированный и кривоватый cow) и bcachefs. И рефлинки в zfs вероятно тоже через них же сделаны. Потому что кто же будет кодить софт "спецом под 1 фс" когда 3 другие юзают вон тот ифейс.
В сорцах ядра эти ioctl у всей троицы явно деланы копипастой с btrfs'а. И устаканился такой вот интерфейс вызовов. К хардлинкам это все никак не относится, ибо ничего с именами файлоов не делает и в общем случае - "same extent" может вообще принадлежать совсем разным файлам. Которые никогда не имели ничего общего, но потом заимели, дедуп прога нашла это - и вывесила запрос замены 1 из копий _экстента_ +1 референсом. Заметьте, это не про _файлы_ или _имена_. Это довольно принципиальное отличие, реализация этих и-фейсов подразумевает некую форму CoW ибо иначе - а как при записи разбивать то клона, чтобы поддержать абстракцию независимости файлов?
>> Он хранит имена файлов и проч в астрале? Не аллоцируя под это место?
> Сами сказали, сами посмеялись? Вопрос в том, как хранятся inode.
Вы не понимаете. На XFS можно создать дофига файлов 0 размера - выжрав все место одними только метаданными. Суммарно размер файлов будет - ноль. Да, это несколько экстремальный случай, для иллюстрации на тему того что цифирь свободного места - еще ничего не гарантирует. Видите, суммарно файлы 0 байтов а места - почему-то нет. Все ушло на метаданные.
> диску, поэтому если ты забьешь его весь inod'ами, то свободного места
> у тебя будет 0.
И вот чего стоит цифря свободного места? Если она варьируется в широких пределах в зависимости от наполнения ФС и при no space left все равно sum(file sizes) != sizeof(dev size). Так что в лучшем случае это какой-то очень приблизительный ballpark даже в ext4 и xfs. В btrfs оно еще более приблизительное. И чего? Да, с RAID может стать еще чуть хитрее. Но если кто полез в продвинутости, ему придется понять азы работы продвинутого дизайна, чтобы избегать глупых обломов. А вы можете юзать хоть FAT16 если вам так хочется.
> Но еще раз повторюсь, чтобы на это нарваться, надо специально постараться.
Предсатвяляете, btrfs для меня тоже в целом - просто работает. Под сказки всяких сказочников. Может, "дело мастера боится" потому что я умею решать свои проблемы - и знаю девов этой штуки, так что "в случае чего" я ессно разберусь. Но пока этот скилл ни разу не пригодился, а страшилки с опеннета - приелись. Скажем прямо.
> снес к такой-то матери полуразваленную btrfs и заменил на xfs, а
> данные восстановил из копии.
Какая типичная для опеннета история. С учетом вышеописанного вы уж простите мне мой здоровый скепсис, и ремарку что я все же буду ездить на поездах. И буду за поезда. С полным пофигом на ваши увещевания что куры перестанут нестись. Потому что я уже цать лет езжу на поездах а куры никуда не делись.
Вариант для распечатки
