Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен.

Ядро 3.17.1 x86_64

ванильное без всяких патчей? Или?

Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен.

[...]

King_Carlo ★  очень ярый ZFS-воин — https://goo.gl/UbXE5Y | кризисный менеджер — https://goo.gl/U8F30Q
03.11.2014 3:44:50

Ты написал багрепорт?

compress-force? а ты умён, лол

Впрочем, это всё равно баг, который должен быть исправлен. Хорошо, что у меня карма бела и блестяща - ни разу не сталкивался с багами btrfs, с которыми почему-то сталкиваются всякие шлимазлы.

кстати, если уж затронули эту тему — как btrfs определяет способость файла на предмет сжатия?

варианты:

1. btrfs сначало пробует сжимать, но сжатие не идёт. в этом случае записывается несжатая версия.

2. btrfs пытается эмпирически ванговать, типа например если в названии файла есть слово «porn», значит это скорее всего видео, а следовательно сжимать смысла нет.

3. другой вариант (какой и как работает?).

...

не знаешь случайно?

Понятия не имею. Может, просто по mime?

Может, просто по mime?

то есть.. это же вариант — «2. вангование...» :-)

сам я пробовал ставить расширение avi для невидео-файла.. сжатие работало (без -force)

проверял работу сжатия — по количеству оставшегося свободного места. после всех sync разумеется..

Определение mime не по расширению работает, это ж не винда -))

Определение mime не по расширению работает, это ж не винда -))

ну наверное в разных программах по разному.. (это же не ядро определяет mime — да?)

вот например возьмём образцовый GNOME :-) ..

Nautilus — показывают тип файла (и в скобочках mime указывается) — в зависимости от расширения...

не... я разумеется понимаю(!), что если удалить у файла расшерение, то Наутилус попытается «догадаться» и без расширения... но когда расширение-то есть — то алгоритм выбирает расширение :)

вот например возьмём образцовый GNOME

в наутилусе есть настройки, типа «если _имя_ файла попадает под шаблон *.avi…»

Ещё в ls есть(LS_COLORS, man dircolors). Остальным программам плевать на это твоё «расширение».

другой вариант

вот это, если я не ошибаюсь. Работает очень просто: тупо сжимает всегда. Почему нет? Даже на третьем пне lzo копейки жрёт.

Гадать нечего: на официальной вики написано:

if the first portion of data being compressed is not smaller than the original, the compression of the file is disabled — unless the filesystem is mounted with compress-force

спасибо!

а я вот не смог найти... эх..

Ещё в ls есть(LS_COLORS, man dircolors)

интересная эта твоя штука dircolors .. очень даже!

тут опять эти расшерения!

это не «расширения», а суффиксы.

Да, забыл ещё сказать, что «расширения» юзают программы сжатия. Точнее некоторые программы распаковки. Вот в слаке less к примеру определяет по имени программу сжатия, и если переименовать *.xz→*.bz2, то less не сможет открыть файл, а если переименовать как надо, то сможет. А вот xzless по любому откроет xz.

Также tar определяет тип архива как MIME тип, а не по имени.

Также tar определяет тип архива как MIME тип, а не по имени.

я в tar обычно использую -a что бы по расширению^Wсуффиксу сжимать\расжимать..

а уже не надо? можно без -a ?

Не, сжатие плохо работает.

И медленно.

Четыре-два, четыре-дваааа

lzo, конечно, не шибко жмёт данные, но экономия всё равно налицо: каталог с репозиториями на Btrfs+lzo, и тот же каталог на Ext4

если нужно сильно сжать данные надо просто поставить ZLIB,а если нужно быстро то LZ4.

почитай про ZLIB и LZ4, а то 5 звёзд а ересь несёте.

btrfs & 3.17: https://archlinux.org.ru/forum/topic/14149/

Есть инфа (на уровне догадок), что это связано с аллокатором. Вроде бы с используемым ныне по дефолту SLUB какие-то проблемы возникают.

а уже не надо? можно без -a ?

в моём man tar такой опции вообще нет.

tar (GNU tar) 1.26

Не, сжатие плохо работает. И медленно.

а что ты сжимал? У меня вообще никакого результата. Но у меня всё что можно сжать уже и так сжато(или мелочь всякая).

lzo, конечно, не шибко жмёт данные, но экономия всё равно налицо: каталог с репозиториями на Btrfs+lzo, и тот же каталог на Ext4

что-то ты врёшь мне кажется. С какого херу у тебя Size разный? Как я понимаю, файл в 1Гб имеет размер в 1Гб (а сжатый занимает на диске меньше места, скажем 700Мб).

Иди мозги себе новые купи уже, задрал маразматировать по всем линуксовым форумам.

С какого хера сжатый до 700 Мб файл будет размером в 1 Гб, если он сжат до 700 Мб? Ты вообще понимаешь, как работает сжатие?

что-то ты врёшь

Да вот мне больше делать нечего, бугога.

Проскакивала новсть, что btrfs уже стабильна.

мало ли что у кого проскакивало. Нашёл с кем спорить. Если людям нравится жрать кактус, ну пусть жрут.

Не повторяется.

$ uname -r
3.17-1-amd64

Единственное что вылезло в dmesg

perf interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

И я не считаю что btrfs готова для продакшен.

Новость была от создателя или главного инженера btrfs.

С какого хера сжатый до 700 Мб файл будет размером в 1 Гб, если он сжат до 700 Мб? Ты вообще понимаешь, как работает сжатие?

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

если у меня файл в 1Гб, то так и должно быть написано «1Гб»

Кому должно?

Это _число_ _байт_ _в_ _файле_

Бгг. В файле 700 миллионов байт, потому что он сжат. Будешь продолжать тупить?

в завтрашнем релизе сузи она будет по умолчанию.

Там вроде поотключали все опасные опции из дефолта.

Бгг. В файле 700 миллионов байт, потому что он сжат. Будешь продолжать тупить?

Это прозрачное сжатие, о нем никто знать не должен, за исключением внутренней структуры *FS

всё равно сменю на ext4

о нем никто знать не должен

Опять: кто вам чего должен? Откуда вы это взяли?

Кедовская утилка (или не кедовская, смотря что она там дёргает под капотом) подсчитывает количество байт в файле. В сжатом файле их, очевидно, меньше. Предлагаешь ФС на каждый файл хранить инфу сколько он занимает в несжатом виде? А зачем нужен такой бессмысленный оверхед?

Тебе всё правильно говорят. У меня корень на btrfs со сжатием LZO. du показывает, что использовано 18 ГиБ, а btrfs fi df / показывает 12 ГиБ.

Можно провести эксперимент - создать файл, забить нулями до 1 ГиБ, а потом дефрагментировать. du все равно будет показывать 1 ГиБ.

Объясни:

# mount | grep btrfs
/dev/sda1 on /mnt/test type btrfs (rw,relatime,compress=lzo,space_cache)

# dd if=/dev/zero of=zerofilled.128m bs=1024k count=128
134217728 bytes (134 MB) copied, 0.051922 s, 2.6 GB/s

/mnt/test/1# ls -lh
-rw-r--r-- 1 root root 128M Nov  3 11:01 zerofilled.128m

# df -h /mnt/test
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   12M   18G   1% /mnt/test

Файл сжат? Сжат. По твоим утверждениям я не должен по ls -l видеть 128М, а должен видеть реальный размер на диске.

Объясни тогда поведение кедовской утилиты со скриншотов выше.

sdio

Есть два способа определить размер файла. Первый — st_size (du --apparent-size), второй — st_blksize * st_blocks (du). Очевидно, что в первом случае нам сообщается размер файла, а во втором — занимаемое на диске место с точностью до размера блока.

Вот filelight смотрит на второй размер, а ls — на первый.

просто офигеный тэст на сжатие дев нула.

471mb bs 365mb могу объяснить разной упаковкой файлов (хвостов), там 162,5 тысячи файлов, вот и набралось.

Пожалуйста не 4.2 для фс с прозрачным сжатием. То что ты сказал применимо к спарс-файлам.

Это применимо и к sparse-файлам, и к ФС с прозрачным сжатием.

Ё, нужно тыкать носом в каждую лужу?

/mnt/test/1# du zerofilled.128m 
131072	zerofilled.128m

/mnt/test/1# du --apparent-size zerofilled.128m 
131072	zerofilled.128m

оправдывайся!

Это /dev/urandom

Возможно.

Бгг. В файле 700 миллионов байт, потому что он сжат. Будешь продолжать тупить?

тупишь только ты: у меня есть ПЯТИМЕТРОВАЯ рулетка, она занимает семь сантиметров. Но она ПЯТИМЕТРОВАЯ, хотя и свёрнута сейчас.

Атрибут «сжатый» меня, как пользователя, вообще не волнует, меня волнует две вещи:

1. сколько в файле байт.

2. сколько файл занимает на носителе.

на первый вопрос отвечает любая утилита/гуй, на второй вопрос отвечает специальная команда

du - estimate file space usage

И да, а почему разряжённые(sparse) файлы размер не меняют с виду?

*проверил на тестовом reiser4*

Офигеть. Ок, был не прав. Тогда как объяснить то, что месяц назад на том же самом reiser4 мой хомяк, судя по отчёту du, занимал ~3GiB, хотя по факту там было >4GiB? reiser4 не умеет в разреженные файлы.

Как будто в ней не могут занести баг в свежее ядро.