> От админа зависит, а не от фс, lvm или ещё чего)
> заресервировано для рута. Или например админ квоты выставил.

Насколько я помню, это работает только на EXT2/3/4. И управляется специфичным для них образом через tune2fs. Который специфичен для ext-ов. Остальные ФС не умеют такой резерв. Если я прогнал - ок, покажи как это сделать на, допустим, XFS. У меня с ним том под рукой есть - я это дело проверю :).

> Пользовательское ПО должно просто грамотно обрабатывать исключение нехватки ресурсов и всё.

Несомненно. В случае btrfs фокус в том что даже удаление файла требует ... сделать CoW выносок для хотя-бы метаданных. А если места нет - ээээ... как бы это сказать... стереть файл - фигвам! :). Потому что для этого надо записать измененный вариант диры. А поскольку CoW и неразрушающая запись - пропатчить старый вариант диры, как в классике - не вариант.

Да, инженеры иногда могут не подумать о некоторых вещах на краевых условиях и иногда это может смотреться довольно забавно. Против такого обычно помогает ребаланс, т.к. chunk'и могут быть заполнены не 100% идеально и получится отыграть какие-то крохи достаточные для удаления. Начиная с 3.18 нечто подобное в такой ситуации делается автоматически.

> Именно такая логика при разработке ПО для юзер-спейса в многозадачной (и много-пользовательской) среде.

В случае btrfs одного простого сискола недостаточно для понимания поместится ли файл на том что есть. Из-за его умений работать с RAIDами и потенциальной способности столкнуться с произвольной смесью уровней избыточности и на самом фундаментальном уровне - нужде наперед знать в какой схеме будут данные хранить. Даже сейчас это известно не на 100% а план таков что не будет известно совсем - такая структура нормально относится к произвольной смеси. Уже сейчас данные и метаданные могут храниться с разными уровнями избыточности, etc.