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


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

★★★★★
← Cario Dock - Ubuntu 14.10 - GNOME нет меню приложений
Подскажите и посоветуйте по поводу вёрстки/шрифтов →
  1 2 3 4 5 6 7 8 9 10 11 12 13
Ответ на: комментарий от emulek

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

Откуда это? Я показал сжатый файл и ls -l, du, du --apparent-size. Показываются реальные (несжатые) размеры файла. df показывает реальное (сжатое) место.

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

Считай что это поле занято для sparse файлов.

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

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

Какая то особая, уличная магия.

Реально интересно. Какая степень сжатия на zfs и перенеси этот файл на пустую btrfs с compress-force и покажи df?

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

ZFS так тормозит без огромного кэша.

Вот опять ты вбрасываешь. Не тормозит она, либо понятие «огромный» у нас сильно различается.

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

инвалидская логика в действии

Не инвалидская — "Весь мир ... мы разрушим, до основания, а затем ..." так надо, да? Проходили уже, разрушали, строили, херня получалась.

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

Только об этом никто не подозревает, включая саму Ext4.

man chattr

A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk. Note: please make sure to read the bugs and limitations section at the end of this document.

BUGS AND LIMITATIONS The `c', 's', and `u' attributes are not honored by the ext2, ext3, and ext4 filesystems as implemented in the current mainline Linux kernels.

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

Показываются реальные (несжатые) размеры файла.

du должна показывать _занимаемое_ место

du --apparent-size должна показывать исходный(не сжатый) размер.

всякие ls должны показывать несжатый размер (user space)

stat должна показывать размер(не сжатый) и число блоков(сжатых).

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

Ext2/3/4 не поддерживают сжатие через атрибуты и это значит, что Ext4 умеет прозрачное сжатие.

Походу, кого-то в детстве били головой об батарею.

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

Реально интересно. Какая степень сжатия

степень сжатия от алгоритма сжатия зависит, а не от FS.

Вот что действительно интересно: что будет, если btrfs погонять с годик со снапшотами и сжатием, и потом скорость померить и сравнить с другим боевым сервером на EXT4.

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

я не тебя спрашивал. или ты и.о.К.О.?

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

Ext2/3/4 не поддерживают сжатие через атрибуты и это значит, что Ext4 умеет прозрачное сжатие.

а по твоему chattr это не атрибуты?

Походу, кого-то в детстве били головой об батарею.

да? Сочувствую.

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

а по твоему chattr это не атрибуты?

Да ты реально болен, лол. Ты сказал, что Ext4 умеет сжатие на лету и в доказательство привёл кусок мана, где внятным английским написано, что Ext* не поддерживают сжатие через атрибуты.

Феерическое слабоумие - не мочь разобраться в трёх с половиною мыслях, причём собственных же, и одной строчке из мана.

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

я это не хуже тебя знаю. Твой ответ не адекватен, тому на что ты отвечаешь.

а я и не говорил, что знаю, что показывает du на btrfs, я говорил, как оно _должно_ быть. И судя по твоему посту Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен. (комментарий) du всегда показывает оно и то же. Это очевидно баг.

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

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

Да ты реально болен, лол. Ты сказал, что Ext4 умеет сжатие на лету и в доказательство привёл кусок мана, где внятным английским написано, что Ext* не поддерживают сжатие через атрибуты.

у тебя какое-то своё понимание слов «через атрибуты», да?

Т.е. chattr - change file attributes on a Linux file system

это НЕ через атрибуты?

Может ты считаешь «атрибутами» опции монтирования и/или параметры ФС?

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

Не инвалидская — «Весь мир ... мы разрушим, до основания, а затем ...» так надо, да?

Нет конечно, нужно использовать поля по назначению, а не вкладывать в них выдуманное значение, т.е. поле st_blksize - не нужно интерпретировать как-то иначе, чем «размер файла на диске». Если хочется узнать что файл sparce - для этого есть другие механизмы.

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

ты свой кусок мана-то перевел? там же черным по белому написано - в ext2/ext3/ext4 эти аттрибуты не имеют никакого значения

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

Реально интересно. Какая степень сжатия на zfs и перенеси этот файл на пустую btrfs с compress-force и покажи df?

С 3-го раза получилось, да и то с небольшим файлом. Исходный файл 10Гб.
ZFS:


zstorage/vm/minecraft      3,1T         5,3G  3,1T            1% /zstorage/vm/minecraft


BTRFS (compress-force=lzo):

/dev/sdc                1,4T         4,2G  1,4T            1% /mnt/btrfs

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

А зачем нужен такой бессмысленный оверхед?

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

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

я правильно понял, на zfs файл сжался до 5.3гб, а на btrfs до 4.2гб

и где здесь преимущества zfs? я вижу обратное

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

я правильно понял, на zfs файл сжался до 5.3гб, а на btrfs до 4.2гб

Правильно.

и где здесь преимущества zfs?

На zfs сжатие работает всегда, а на btrfs только при определенных условиях. compress-force, который изображает работу схожую с zfs, неработоспособен вовсе.

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

Юлишь, весь тред ты говорил иное.

Как тебе верить в других тредах, если ты врешь.

Считай что на zfs всегда включен compress-force, зато в btrfs больше гибкости, хочешь всегда, хочешь автоматически, ...

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

нужно использовать поля по назначению, а не вкладывать в них выдуманное значение

Легаси. Примеров таких масса и не только в IT.

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

Юлишь, весь тред ты говорил иное. Как тебе верить в других тредах, если ты врешь.

Что за припадок паранои? Я весь тред говорил, что разреженный файл на btrfs c compress=lzo не жмётся вовсе, а на zfs жмется. Так оно и есть. Где я вру?

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

Ты так говоришь, будто это что-то хорошее.

Для хранения образов ВМ это очень-очень хорошо. На zfs, кстати, включить и выключить сжатие я могу на любой ФС, а на subvolume btrfs нет.

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

Ты хотел чтобы было как в zfs, для этого в btrfs нужно compress-force, тут только тебя можно мокнуть в незнание мат.части. Кроме того ты утверждал что в zfs еще и жмется лучше. Соврал.

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

ты читаешь вообще то что пишешь, или ты исключительно писатель?

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

Для хранения образов ВМ это очень-очень хорошо

А для кинопомойки или музыкальной коллекции это только бессмысленная трата проца и памяти на попытки сжать несжимаемое.

На zfs, кстати, включить и выключить сжатие я могу на любой ФС, а на subvolume btrfs нет

Я в курсе. Будет запилено в будущих версиях.

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

я и не говорил, что примеров таких нет, я говорил что это костылестроение для инвалидов.

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

для этого в btrfs нужно compress-force, тут только тебя можно мокнуть в незнание мат.части

Ты начало треда читал? Я включил compress-force, чтобы сжимало, но это не работает, потому что btrfs бажная и валит систему.

ты утверждал что в zfs еще и жмется лучше. Соврал.

Не соврал, на zfs жмётся, на btrfs нет. compress-force не работает )

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

А для кинопомойки или музыкальной коллекции это только бессмысленная трата проца и памяти на попытки сжать несжимаемое.

zfs set compress=off zpool/fs и заметьте, без всякого перемонтрования, на лету.

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

разложить файлопомойку по томам в зависимости от типов файлов

У тебя, надо полагать, образы ВМ, порнуха, музон, доклады майору и письма любовницам лежат в одной папке?

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

Зачастую так и получается. А ещё у меня текстовые файлы (исходники) вперемешку с архивами их же. Потому что в современных DE есть средства поиска и фильтрации, позволяющие забить на педантичное раскладывание файликов по каталогам.

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

Это почему? Если тебе зачем-то надо видеть размер до сжатия, то и для gz должно показывать размер контента, а не архива. А если надо видеть размер файла в ФС, то должен показываться размер в ФС.

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

Ну вообще довольно странно, что я не могу вдруг этого захотеть.

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

ещё есть, например git, который в .git/objects хранит сжатые файлы, а в working tree - очень даже несжатые

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

Зачастую так и получается.

Можно и так конечно, бардак это лично дело каждого. Я включаю компрессию на весь пул и очень редко выключаю сжатие на отдельной ФС, крайне редко. Сжатие не жрёт современый процессор, как ограничить потребление памяти всем известно. Не вижу проблем.

King_Carlo ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10 11 12 13
← Cario Dock - Ubuntu 14.10 - GNOME нет меню приложений
General
Подскажите и посоветуйте по поводу вёрстки/шрифтов →