LINUX.ORG.RU
Форум — General  

Проскакивала новсть, что 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


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

★★★★★

 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 →
Ответ на: комментарий от sdio

а теперь покажи что выдаст про него `du', вангую что «размер директории» считается аналогично du -s, а вовсе не суммируя размер всех файлов

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

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

Решил я скинуть на эту вашу btrfs несколько разреженных файлов с виртуалками, расширение файлов .img (нравится мне так), с опцией монтирования compress=lzo не жмёт вообще, с compress-force=lzo жмёт, но всё равно не очень, ZFS делает это гораздо эффективнее. Жать или не жать исходя из типа файла - маразм и разжижение мозга у разработчиков.

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

Предлагаешь ФС на каждый файл хранить инфу сколько он занимает в несжатом виде? А зачем нужен такой бессмысленный оверхед?

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

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

это наверное недоделанный аналог команды du.

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

Дай угадаю, для файлов .gz гуй тоже должен показывать размер внутренностей, а не архива?

для файлов gz гуй должен показывать размер gz, даеже если gz был сжат с опцией -0, а потом пережат ФС в 10 раз.

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

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

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

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

А мне - нет.

ясно. Когда будешь в след. раз тестировать, показывай пожалуйста и тот и другой размер. Или хотя-бы предупреждай, что твоя утилита показывает _занимаемый_ объём.

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

Продолжай держать меня в курсе.

Не, я пас, потрогал btrfs, через пол часа оно упало - это стабильность. Теперь год-два я даже новости про это читать не буду, а лучше чтоб это дерьмо вообще убрали из ядра и не позорились.
P.S. Интересно что будет, если попробую systemd?

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

Напишешь гневный пост в толксы, конечно же.

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

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

pedobear
()

BTRFS

А почему латинскими буквами? По-английски же "бронетранспортер" несколько иначе...

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

скинуть на эту вашу btrfs несколько разреженных файлов

разреженных == sparse? Они должны сжаться? Ты ничего не путаешь?

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

тебе сложно было посчитать в консоли размер каталога(с файлами) и место, которое он занимает? Научить? 

$ du -shx dirname/

Ну и тоже самое с опцией

--apparent-size print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like

А скрины засунь себе в ж…

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

Они должны сжаться? Ты ничего не путаешь?

С опцией монтирования compress=lzo не жмёт, с compress-force=lzo жмёт.

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

что это всего лишь баг в btrfs.

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

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

разреженных == sparse? Они должны сжаться? Ты ничего не путаешь?

по идее обязаны. LZO отлично сжимает последовательности нулей, обычно даже лучше, чем sparse(например если куски с нулями меньше блока ФС).

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

Ты не ответил на вопрос. Как SPARSE файлы могут сжиматься?

Судя по этому: 

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

начало файла плохо жмется и btrfs решил не сжимать весь файл.

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

Я думаю в рейзер просто сделали так же как в бтрфс (ядро же не должно ломать юзерспейс), а раньше делали так, как идеологически правильнее. Насколько я вижу в интернетиках - в zfsonlinux со сжатием du тоже показывает на реальный размер на диске, а вовсе не до сжатия, хотя может в нем это уже тоже «пофиксили», а во фре так вообще у du есть отдельный флаг, чтобы правильно считать сжатые файлы.

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

Это есть в доке на btrfs или кто-то по телефону напел?

Это откровение мне явилось среди ночи. Как ещё объяснить, что файл с расширением .img не сжимается с compress, но сжимается с compress_force?

King_Carlo ★★★★★
() автор топика
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от emulek 
# du -shx /repo
802M    /repo

# du -shx /media/mix/tmp
913M    /media/mix/tmp

Видимо, разница всё-таки в упаковке хвостов, как и сказал sdio.

А скрины засунь себе в ж…

Не, я лучше тебя в игнор занесу, истеричка

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

sparse != нули, это "дыры" вместо которых драйвер ФС возвращает нули, реально их там нет, иначе это не sparse

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

какими средствами btrfs? в линуксе уже есть два поля: место на диске и размер файла, но в btrfs ради глючного юзерспейса во второе пишут то же самое, что и в первое.

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

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

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

начало файла плохо жмется и btrfs решил не сжимать весь файл.

Очень может быть, в начале файла ОС. Но это инвалидская логика.

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

Судя по этому:

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

начало файла плохо жмется и btrfs решил не сжимать весь файл.

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

Если сжатие прозрачное, то это не баг, в таком случае степень сжатия (место на диске) нужно смотреть средствами самого btrfs.

а доделать du не судьба?

ЗЫЖ почитал мануалы к btrfs, такого не нашёл.

только вот что:

filesystem defragment -c[zlib|lzo] [-l len] [-s start] [-t size] -[vf] <file>|<dir> [<file>|<dir>...]

Defragment file data and/or directory metadata. To defragment all files in a directory you have to specify each one on its own or use your shell wildcards.

The start position and the number of bytes to defragment can be specified by start and len. Any extent bigger than threshold will be considered already defragged. Use 0 to take the kernel default, and use 1 to say every single extent must be rewritten. You can also turn on compression in defragment operations.

-v be verbose

-c compress file contents while defragmenting

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

начало файла плохо жмется и btrfs решил не сжимать весь файл.

Я уже понял. Такое сжатие бессмысленно на моих задачах.

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

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

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

но в btrfs ради глючного юзерспейса во второе пишут то же самое, что и в первое.

Считай что это поле занято для sparse файлов. Для сжатых надо свое поле, а пока пусть btrfs выдает инфу о файле.

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

потому что постишь свои домыслы, не утруждая себя чтением комментариев в своём же треде.

Комментарии появляются пока я пишу домыслы, очевидно.

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

Средний диск в лучшем случае сожмется в два раза. Я не сделаю этого ни для btrfs, ни zfs, ни super-druper-compress-fs.

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

sparse != нули, это «дыры»

я это не хуже тебя знаю. Речь о том, что драйвер вернёт нули, а LZO их свернёт практически до нулевого размера. Т.ч. вместо «дырявого» файла будет не дырявый, но маленький файлик. Теоретически, его размер должен показываться как у оригинального, не сжатого, а размер на диске будет примерно как у sparse, или даже меньше(да, читаться писаться он конечно может намного медленнее разряжённого).

И как я понял по ходу дискусса, btrfs почему-то пишет размер того, что она посжимала, а не того, что я писал. Не очень понятно, на кой ляд?

PS: напомню, что прозрачное сжатие на лету есть и в EXT4, только оно отключено по дефолту.

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

du не получится доделать, сам btrfs выдает одинаковые значения du и du --apparent-size

ну это не фича, а баг.

emulek ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 →
General