Размер файлов в btrfs

Оно не показывает размер после сжатия а до?

А толку от этого размера, если через минуту файл может быть сжатым, или не сжатым, или где-то появится копия, не занимающая места? Тогда «стандартный» размер файла ни о чем не говорит применительно к месту, которое он занимает.

Толку того, что, раз качество сжатия недетерминированно и размазано во времени, лучший результат даст тупое удаление самых больших файлов.

А как ты найдешь самые большие файлы? Может у меня где-то 2 одинаковых больших файла, и из-за дедупликации удаление одного ничего не даст.

И для этого нет утилит?

Утилит для чего?

Нахождения дедуплицированных файлов же.

А зачем мне их находить? Один из них мне нужен, другой нет. Я удаляю один как самый большой, но ничего не меняется. Смотреть полную картину для всех файлов слишком сложно и долго, если нужно просто освободить место.

А зачем мне их находить?

Чтобы исключить из подсчёта освободившегося места.

слишком сложно и долго

Напиши скрипт.

Напиши скрипт.

Чтобы получать ту же полную картинку автоматически, и все равно в ней вручную разбираться. Потому что нужно выбирать, какие из дубликатов нужны, а какие нет, и в каких каталогах они находятся (может это часть проекта, а может просто файлик завалялся).

Ииии?

И по этой причине нужен другой вариант.

сжимаются же не все файлы, фс тоже не тупая, думаешь оно бд-рипы тебе будет сжимать?

Какой такой причине? Ты уже отсортировал по реально занимаемому на диске размеру, убрал из списка дубликаты и можешь прикрутить в догонку белый/чёрный список, сузив результаты. Дальше нужно больше инфы.

убрал из списка дубликаты

Нельзя так делать. Может там есть 2 дубликата, которые оба мне не нужны, и их можно удалить.

по реально занимаемому на диске размеру

Ага, а завтра он другим будет.

сжимаются же не все файлы

А какие?

Значит помечать, но отображать. Их будет мизерное колиество, в общем случае.

Ага, а завтра он другим будет.

И поэтому это игнорируем.

Получается, что все зависит от масштабов трагедии. Если влияние фич ФС невелико, то все просто. А если велико, то нет способа освободить место достоверно.

compress,compress-force
Enable compression. Starting with kernel 2.6.38 you can choose the algorithm for compression:
compress=zlib - Better compression ratio. It's the default and safe for olders kernels.
compress=lzo - Faster compression.
compress=no - Disables compression (starting with kernel 3.6).
compress-force=<method> - Enable compression even for files that don't compress well, like videos and dd images of disks. The options compress-force=zlib and compress-force=lzo works for kernels >2.6.38.
Note that old (before 2012) btrfs-progs versions will probably fail some operations (e.g. fsck) on filesystems with LZO compression.

Ясно, благодарю.

Странная проблема: ФС вместо нескольких одинаковых файлов хранит фактически только один, только он и занимает место. ФС уже сэкономила место за вас, за вами лишь выбор: нужен файл или нет. Если файл не нужен - удаляйте все дубликаты (размер-то одинаковый), если нужен, но в некоторых местах дубликаты хотите удалить - удаляйте. Только пока последний не удален, файл занимает столько же места, сколько и до их удаления. Для сравнения размеров есть еще Baobab.

Как полагается в подобных системах работать?

Поставить нормальную файловую систему, в которой файл может занимать только определённое количество блоков, в зависимости от его размера.