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

ничего себе на btrfs перешел

 ,


0

1

Конвертирую, значит, ext4 в btrfs, а оно падает (sys-fs/btrfs-progs-4.10.2, sys-libs/glibc-2.23-r4, ядро 4.11.7):

localhost ~ # btrfs-convert /dev/disk/by-label/Storage      
create btrfs filesystem:
        blocksize: 4096
        nodesize:  16384
        features:  extref, skinny-metadata (default)
creating ext2 image file
Unable to find block group for 0
extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
btrfs-convert(btrfs_reserve_extent+0x7ba)[0x422dca]
btrfs-convert(btrfs_alloc_free_block+0x5f)[0x42327f]
btrfs-convert[0x413317]
btrfs-convert(btrfs_search_slot+0x400)[0x414780]
btrfs-convert(btrfs_csum_file_block+0x4b7)[0x429ae7]
btrfs-convert(main+0x189b)[0x40af7b]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f64bca99670]
btrfs-convert(_start+0x29)[0x40bce9]
Unable to find block group for 0
extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
btrfs-convert(btrfs_reserve_extent+0x7ba)[0x422dca]
btrfs-convert(btrfs_alloc_free_block+0x5f)[0x42327f]
btrfs-convert[0x413317]
btrfs-convert(btrfs_search_slot+0x400)[0x414780]
btrfs-convert(btrfs_csum_file_block+0x4b7)[0x429ae7]
btrfs-convert(main+0x189b)[0x40af7b]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f64bca99670]
btrfs-convert(_start+0x29)[0x40bce9]
Unable to find block group for 0
extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
btrfs-convert(btrfs_reserve_extent+0x7ba)[0x422dca]
btrfs-convert(btrfs_alloc_free_block+0x5f)[0x42327f]
btrfs-convert[0x413317]
btrfs-convert(btrfs_search_slot+0x400)[0x414780]
btrfs-convert(btrfs_csum_file_block+0x4b7)[0x429ae7]
btrfs-convert(main+0x189b)[0x40af7b]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f64bca99670]
btrfs-convert(_start+0x29)[0x40bce9]
extent-tree.c:2696: btrfs_reserve_extent: BUG_ON `ret` triggered, value -28
btrfs-convert[0x41cd46]
btrfs-convert(btrfs_reserve_extent+0x98c)[0x422f9c]
btrfs-convert(btrfs_alloc_free_block+0x5f)[0x42327f]
btrfs-convert[0x413317]
btrfs-convert(btrfs_search_slot+0x400)[0x414780]
btrfs-convert(btrfs_csum_file_block+0x4b7)[0x429ae7]
btrfs-convert(main+0x189b)[0x40af7b]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f64bca99670]
btrfs-convert(_start+0x29)[0x40bce9]
Аварийный останов

что бы это могло означать?

★★★★★

 ← 1 2 3 →
Ответ на: комментарий от Serge10

Прямо, интересная какая-то бухгалтерия получается. Итак, если ФС издаст в 2 раза меньше I/O запросов, то никто этого не заметит? Где же такому учат, неужто в СПбГУ?

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

Итак, если ФС издаст в 2 раза меньше I/O запросов

Как Вы себе это представляете? Считаете, что при компрессии в два раза во столько же раз сократится потребность в IOPs?

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

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

Это от задач зависит. Многие базы данных в OLTP режиме потребляют тысячи и десятки тысяч IOPs. При этом обходятся 2-8 ядрами CPU. Тут у SSD альтернатив практически нет, если не считать HiEnd СХД на несколько сотен дисков...

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

во столько же раз сократится потребность в IOPs

Что за потребность такая? Кто требует?

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

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

Мда. Расскажи принципиальную разницу между внутренним аппаратным RAID и внешним. А я послушаю с интересом.

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

У вас получается, что если диск не догрузили IO-запросами до какой-то его «потребности», он будет продолжать вращаться?

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

Конечно. Только там выигрыш меряется долями процента ;). Что и называется ловлей блох.

Это с чего, если сильно уменьшается объём записи ? Как раз на SSD это меньше заметно будет.

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

У вас получается, что если диск не догрузили IO-запросами до какой-то его «потребности», он будет продолжать вращаться?

Извините, не понял, о чем Вы. Что за потребность диска? И как он может перестать вращаться? Просьба по-человечески переформулировать вопрос.

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

Это с чего, если сильно уменьшается объём записи ? Как раз на SSD это меньше заметно будет.

В реальном мире многозадачных и многопользовательских систем мы имеем дело практически исключительно со случайным доступом к данным (куча приложений постоянно дергают диск). А при случайном доступе IOPs слабо коррелируют с объемом записи. Т. е., скажем, двукратная компрессия не приведет к двукратному же сокращению IOPs что при записи, что при чтении...

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

Прошу прощения, не на то сообщение ответил :(.

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

А при случайном доступе IOPs слабо коррелируют с объемом записи. Т. е., скажем, двукратная компрессия не приведет к двукратному же сокращению IOPs что при записи, что при чтении...

пипец ты всё-таки дэбил. во-первых, напрямую коррелирует и зависит от размера блока и кол-ва этих самых iops. во-вторых, приведёт - надо системе записать 80кб, при размере блока 4кб надо сделать 20 операций io, но система пожала это в джва раза до 40кб и, о чудо, теперь надо сделать только 10 io. потребность в io сократилась в ДЖВАБЛЕАТЬРАЗА.

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

приведёт - надо системе записать 80кб, при размере блока 4кб надо сделать 20 операций io, но система пожала это в джва раза до 40кб и, о чудо, теперь надо сделать только 10 io. потребность в io сократилась в ДЖВАБЛЕАТЬРАЗА.

Вы неправильно считаете. FS жмет данные на уровне файлов. Рассмотрим два варианта. Первый - Ваш пример, когда есть файл размером 80 kB, FS сжала его до 40 kB. Запись будет последовательной, здесь Ваша арифметика имеет смысл. И то только в том случае, если параллельные запросы диск не дергают (файл за один заход пишется).

И вариант, более близкий к реальности - большой файл с таблицами БД. Модификации таблиц требуют случайной записи в разные области файла. При этом для каждой модификации файл надо сначала расжать, потом снова сжать перед записью. Здесь никакой корреляции между IOPs и степенью сжатия не будет.

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

За что же вы так опустили админов мордокниги :)

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

Ваш спор напомнил мне одну известную присказку — «я ему про Ивана, он мне про болвана».

И вариант, более близкий к реальности - большой файл с таблицами БД. Модификации таблиц требуют случайной записи в разные области файла. При этом для каждой модификации файл надо сначала расжать, потом снова сжать перед записью. Здесь никакой корреляции между IOPs и степенью сжатия не будет.

Т.е. Вы утверждаете что при апдейте скажем миллиарда записей, после каждой модификации файл БД будет разжиматься и снова сжиматься?

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

Ваш спор напомнил мне одну известную присказку — «я ему про Ивана, он мне про болвана».

Угу, у меня точно такое же ощущение - все аргументы уже по третьему кругу идут...

Т.е. Вы утверждаете что при апдейте скажем миллиарда записей, после каждой модификации файл БД будет разжиматься и снова сжиматься?

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

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

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

С той же целью сжимал диски на thinkpade с первым пеньком и медленным винтом. Реально тащило (грузился быстрее, например). Кстати проц не заметил что бы грузился сильно.

КМК на современных машинах уже не критично.

Создай эту твою brtfs в разделе внутри файла. И рядом положи такой же раздел-в-файле с ext4. И, после перезагрузки залей туда тестовые файлики. Сразу увидишь есть ли разница.

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

все аргументы уже по третьему кругу идут

нет у тебя никаких аргументов. приведи хоть одно обоснование своего бреда.

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

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

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

во-первых, это было в контексте безопасности io, а во-вторых, не тебе на тему хранения данных вещать.

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

А вот тут уж как повезет. В лучшем случае у Вас машина впадет в ступор почище чем при баге 12309 - CPU будет занят процессами, ждущими IO, а система IO будет ждать освобождения процессора.

Приоритет ядерных тредов выше же.

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

откуда этот дебил может это знать?

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

Это потому, что вы не понимаете аргументов друг друга и доказываете вполне очевидные вещи, но разные!

Возьмём, для примера, файл размером 1 МБ и некий девайс с такими параметрами: размер блока - 1 КБ, скорость записи - 1 МБ/с, скорость операций в/в - 1К io/с.

Пишем файл без сжатия:

(1) время записи 1/1=1 сек

(2) кол-во операций 1М/1К=1К

(3) кол-во операций в сек = 1К

Пишем с сжатием 2:1:

(1) = 0,5 сек

(2) = 0,5 К

(3) = 1 К

Вы доказываете пункт (3) и Вы правы, а аноним пункт (2) и он тоже прав! :)

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

во-первых, это было в контексте безопасности io

Именно так. Но со сноской, что речь идёт о производительности.

а во-вторых, не тебе на тему хранения данных вещать.

Правда ? А тебе что ли ?

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

Это потому, что вы не понимаете аргументов друг друга

Это потому, что оппонент мягко говоря не в теме.

Вы доказываете пункт (3) и Вы правы

что тут доказывать? что при неизменном размере блока максимальное кол-во iops тоже неизменно? так это к делу и не относится и только полный профан будет пытаться это доказывать, особенно в свете изначального тезиса об уменьшении io в случае применения компрессии. зы специально для одарённых Serge10 - в первом случае ты за 1000iops передашь 1мб, во втором за те же самые 1000 iops ты передашь 2мб, если ты и этого не понимаешь и это по твоему не сокращение потребности в io, то тебе самое место в начальной школе.

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

тогда откуда вопрос?

Мне показалось, что утверждается существование отличий при записи на внешнюю корзинку и на аппаратный RAID в слоте материнки.

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

Видимо, мне тоже что-то показалось, был дерзок.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 →
General