LINUX.ORG.RU

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

 


0

2

Ядро 3.17.1 x86_64. Монтируем btrfs с опцией compress-force=lzo и пишем в 2-3 потока всего лишь на скорости гигабитной сетки. Через 10-30 минут (как повезёт), система наглухо виснет вот с таким выхлопом:


Call Trace:
Nov 3 03:21:49 DRIVE kernel: [ 859.630880] [<ffffffff817a3e05>] _raw_write_lock+0x25/0x30
Nov 3 03:21:49 DRIVE kernel: [ 859.630888] [<ffffffffc01be3a9>] btrfs_tree_lock+0xc9/0x1d0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630891] [<ffffffff810b3eb0>] ? add_wait_queue+0x60/0x60
Nov 3 03:21:49 DRIVE kernel: [ 859.630896] [<ffffffffc015b92b>] btrfs_lock_root_node+0x3b/0x50 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630901] [<ffffffffc0160dd7>] btrfs_search_slot+0x787/0x880 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630907] [<ffffffffc0178048>] btrfs_lookup_file_extent+0x38/0x40 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630914] [<ffffffffc01983f1>] __btrfs_drop_extents+0x151/0xdf0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630915] [<ffffffff8109da1c>] ? ttwu_do_wakeup+0x2c/0x100
Nov 3 03:21:49 DRIVE kernel: [ 859.630917] [<ffffffff811cd773>] ? kmem_cache_alloc+0x1b3/0x1f0
Nov 3 03:21:49 DRIVE kernel: [ 859.630922] [<ffffffffc015b3ba>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630926] [<ffffffffc015b3ba>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630932] [<ffffffffc018867b>] insert_reserved_file_extent.constprop.64+0xab/0x310 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630938] [<ffffffffc0185880>] ? start_transaction.part.35+0x80/0x530 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630944] [<ffffffffc018ee35>] btrfs_finish_ordered_io+0x475/0x580 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630951] [<ffffffffc01cd6d1>] ? end_compressed_bio_write+0x31/0xf0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630957] [<ffffffffc018ef55>] finish_ordered_fn+0x15/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630964] [<ffffffffc01b49ae>] normal_work_helper+0x7e/0x1b0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630971] [<ffffffffc01b4c52>] btrfs_endio_write_helper+0x12/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630972] [<ffffffff8108ce2e>] process_one_work+0x14e/0x460
Nov 3 03:21:49 DRIVE kernel: [ 859.630973] [<ffffffff8108d7ab>] worker_thread+0x11b/0x3f0
Nov 3 03:21:49 DRIVE kernel: [ 859.630975] [<ffffffff8108d690>] ? create_worker+0x1e0/0x1e0
Nov 3 03:21:49 DRIVE kernel: [ 859.630976] [<ffffffff810932b9>] kthread+0xc9/0xe0
Nov 3 03:21:49 DRIVE kernel: [ 859.630977] [<ffffffff810931f0>] ? flush_kthread_worker+0x90/0x90
Nov 3 03:21:49 DRIVE kernel: [ 859.630978] [<ffffffff817a46fc>] ret_from_fork+0x7c/0xb0
Nov 3 03:21:49 DRIVE kernel: [ 859.630979] [<ffffffff810931f0>] ? flush_kthread_worker+0x90/0x90
Nov 3 03:21:49 DRIVE kernel: [ 859.630980] Code: 90 8b 0a 84 c9 66 90 75 f6 89 ce 89 c8 83 ce 01 f0 0f b1 32 39 c8 75 e7 b9 ff 00 00 00 eb 0a 0f 1f 84 00 00 00 00 00 f3 90 8b 02 <83> f8 01 75 f7 f0 0f b1 0a 83
f8 01 75 ee eb b3 0f 1f 40 00 8b


Это просто сама стабильность.

★★★★★

Ядро 3.17.1 x86_64

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

emulek
()

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

[...]

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)

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

Deleted
()

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

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

pedobear
()
Ответ на: комментарий от pedobear

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

варианты:

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

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

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

...

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

user_id_68054 ★★★★★
()
Ответ на: комментарий от pedobear

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

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

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

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от pedobear

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

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

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

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

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

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

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

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

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

emulek
()
Ответ на: комментарий от user_id_68054

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

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

emulek
()
Ответ на: комментарий от user_id_68054

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

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

pedobear
()
Ответ на: комментарий от user_id_68054

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

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

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

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

emulek
()
Ответ на: комментарий от emulek

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

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

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

user_id_68054 ★★★★★
()
Ответ на: комментарий от pedobear

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

erzent ☆☆
()
Ответ на: комментарий от greenman

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

pedobear
()
Ответ на: комментарий от user_id_68054

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

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

tar (GNU tar) 1.26

emulek
()
Ответ на: комментарий от derlafff

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

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

emulek
()
Ответ на: комментарий от pedobear

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

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

emulek
()
Ответ на: комментарий от emulek

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

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

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

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

pedobear
()

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

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

Bad_ptr ★★★★★
()

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

$ uname -r
3.17-1-amd64

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

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

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

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от pedobear

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

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

emulek
()
Ответ на: комментарий от emulek

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

Кому должно?

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

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

pedobear
()
Ответ на: комментарий от pedobear

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

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

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

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

pedobear
()
Ответ на: комментарий от pedobear

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

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

anonymous
()
Ответ на: комментарий от pedobear

Объясни:

# 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 ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от pedobear

sdio

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от pedobear

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

sdio ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

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

sdio ★★★★★
()
Ответ на: комментарий от pedobear

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

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

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

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

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

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

du - estimate file space usage

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

emulek
()
Ответ на: комментарий от sdio

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

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

intelfx ★★★★★
()
Ответ на: комментарий от YLoS

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

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.