Исправление i-rinat, (текущая версия) :
https://lkml.org/lkml/2010/6/3/313 — кажется, это оно.
Почитал тред. Первое сообщение пропустили мимо, а когда через 15 дней poweruser о нём напомнил, Шишкин был первый, кто толкнул дискуссию в флейм:
It must be a highly unexpected and difficult question for file system developers: «how efficiently does your file system manage disk space»?
Решение о включении в дерево всего, что размером меньше свободного места в листе было изначально глупым, но об этом мало кто думал. Кстати, в тот момент, когда я первый раз попробовал создать том btrfs, max_inline уже было ограничено значением 256. По вопросу больших xattr я не в курсе. Если они до сих пор включаются вне зависимости от размера, а не выносятся в отдельный блок, тогда то письмо всё ещё актуально. Если же xattr тоже исправили, хватит бередить флейм четырёхлетней давности.
А, да, чтобы прояснить свою позицию в споре reiser4 vs. btrfs. Мне не нравятся ФС с CoW из-за непоняток со свободным местом. Может в промышленном применении это даёт какие-то преимущества, но мне это фиолетово. Я хочу точно знать, смогу ли я записать файл на ФС, в которой кончается место.
Исходная версия i-rinat, :
https://lkml.org/lkml/2010/6/3/313 — кажется, это оно.
Почитал тред. Первое сообщение пропустили мимо, а когда через 15 дней poweruser о нём напомнил, Шишкин был первый, кто толкнул дискуссию в флейм:
It must be a highly unexpected and difficult question for file system developers: «how efficiently does your file system manage disk space»?
Решение о включении в дерево всего, что размером меньше свободного места в листе было изначально глупым, но об этом мало кто думал. Кстати, в тот момент, когда я первый раз попробовал создать том btrfs, max_inline уже было ограничено значением 256. По вопросу больших xattr я не в курсе. Если они до сих пор включаются вне зависимости от размера, а не выносятся в отдельный блок, тогда то письмо всё ещё актуально. Если же xattr тоже исправили, хватит бередить флейм четырёхлетней давности.