Краш NTFS-3G с последующим transport endpoint is not connected до ребута

Когда-то проходил через стадию дуалбута и все пользовательские данные держал на NTFS-разделе. Так вот, виндовый checkdisk периодически ругался на ошибки ФС. Изредка с раздела пропадали отдельные файлы. Поэтому, как только я освоился в Linux, так сразу переразбил диск, затерев винду. Старые данные залил на вновь созданный хомяк на XFS (сейчас везде использую ext4, но тогда мне это казалось разумным). Файлы пропадать перестали. Сейчас даже для флешек почти не использую NTFS-3G, потому как свои форматирую в ExFAT.

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

NTFS-3G работает, говорили они…

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

Изредка с раздела пропадали отдельные файлы

Не при хибернации?

зачем-то 7 лет использовали в продакшене

Да ещё и под приличной нагрузкой!

А не громко ли домашнюю машинку продакшном обзывать? Ещё и с Debian Testing?

Если не добьешься исправления бага

Так есть ли баг, вот в чём вопрос. Мало ли чего оно упало. Там вон libc старый использовался, это уже фактор UB (при том, что обновляли его месяц назад где-то, и так и не перезагрузились). Аллокация мог сфейлиться. Собственно, это само по себе не странно, вопрос скорее в том, какого хрена оно зависло до ребута и не давало читать даже ядрёному драйверу. Надо было, прежде чем грузиться в оффтопик, проверить из-под онтопика ещё раз, вдруг таки ФС сломалась, а оффтопик при загрузке молча починил.

старый использовался

а как же работет нитрожь?

Ваш prelockd может быть к этому причастен? OOM killer в dmesg не было точно

Хз каким образом. prelockd работает от юзера prelockd и всего-лишь аккуратно мемлочит файлы на чтение, никуда особо не вмешивается.

На дебиан у меня работает, проблем с ним не было.

Кроме одной:

как известно, прелокд ускоряет приход ядерного киллера и способствует пропуску фазы предоомного дедлока. Иногда при запуске множества tail /dev/zero падали иксы после оом. Но в основном все ок. У вас же оом не было, так что хз.

вообще-то прелокд няшка.

из-за нехватки памяти сам завалиться мог, жручий же.

кто жручий?

Testing

Ну тут все понятно, надо репортить.

(deleted)[7feb2fdd0000+14a000]

Это норма? куда либу дели?

А не громко ли домашнюю машинку продакшном обзывать? Ещё и с Debian Testing?

Про Debian Testing и домашнюю машинку в открывающем посте не было ни слова. А вот от «мы» так и веет продакшном – поэтому так громко получилось. В принципе, я тебя понял и сам сказал всё, что хотел сказать.

Так тем более — значит, три года один и тот же билд работал штабильно!

У вас же оом не было, так что хз

А с учётом настроек оверкоммита есть предположения?

root@localhost:~# cat /proc/sys/vm/overcommit_memory 
1
root@localhost:~# cat /proc/sys/vm/overcommit_ratio
200

Compiz при этом вот иногда падает на аллокации, когда своп забит (но не переполнен!)

кто жручий?

NTFS-3G. К тому моменту около 120 МБ жрал. А непосредственно перед крашем мог больше, не следили ведь.

После краша вообще странности начались; Thunderbird, например, у которого профиль симлинкнут на отвалившийся раздел, заспаунил процесс LocalStorageDB (никогда такого раньше не видели!), сожравший более 400 МБ, и уже потом завис.

Шо, в дебиановский багтрекер опять? Там Спортлото, как правило.

Обновилась же. Но, видимо, лишь до патч-версии, иначе needrestart бы ругался, что перезагружаться пора.

Угу, продакшн с виндой в дуалбуте :3

А с учётом настроек оверкоммита есть предположения?

1 - это неограниченный оверкоммит, и в таком случае ratio не имеет значения.

1 - значит процессы не будут падать с cannot allocate memory. Мне тоже нравится 1.

Compiz при этом вот иногда падает на аллокации, когда своп забит (но не переполнен!)

Фрагментация памяти?

Кстати говоря, дефрагментировать можно и вручную.

см также

https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/

https://serverfault.com/questions/133305/linux-memory-fragmentation

Возможно стоит уделить больше внимания влиянию prelockd на обновление.

Но теоретически-то у каждого процесса своя головая есть. Какое им дело до другого процесса, который лочит для себя какие-то файлы.

Кстати, зачем вам прелокд в домашнем производстве?

Ваш prelockd может быть к этому причастен?

Можно представить, что файл был залочен, но на диске при обновлении удален, а в памяти-то остался висеть в расшареном виде. А дальше хз, что-то могло пойти не так.

В общем надо исследовать влияние блокировки либ на процесс обновления. - Как процессы воспринимают залоченные, но исчезнувшие с диска либы?

Можно, конечно, предложить выключать демона на время обновления.

Возможно дело и не в прелокд, точно сказать нельзя. Однако теперь есть повод для исследований.

Как раз с ним и будут же. Как на винде. Этот самый chkdsk и умудрился вся память выжрать, аж DWM падать начал O_O

Да ядро вроде и так время от времени дефрагментирует, не?

А для чего он придуман? :3

Без prelockd постоянно при резком возрастании потребления памяти всё фризилось нафиг с появлением десятков записей в iotop, с ним заметно меньше.

Дуалбутчик? Как не стыдно...

А чего тут стыдиться? Для мобилоковырятельных задач виртуалка не годится. Желателен прямой доступ к USB-порту, а не с предварительным перехватом хостовой ОС.

Вот только на практике это в последний раз понадобилось эдак в 2014-м. После этого грузились в винду от силы раз в год как раз для того, чтобы обслуживать этот самый NTFS-раздел, который для винды и держим *facepalm*

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

Ограниченный оверкоммит это 2 а не 1

да

Без prelockd постоянно при резком возрастании потребления памяти всё фризилось нафиг с появлением десятков записей в iotop, с ним заметно меньше.

спасибо за отзыв

Но с vm.swappiness=200 таки стало ещё лучше, и без prelockd! В свопе уже более двух гигов, при этом свободной памяти почти столько же. Можно будет, пожалуй, и четыре туда набить спокойно, что ранее уже клало систему на лопатки.

Не получится ли, кстати, что prelockd при таком раскладе будет только мешать? Лок же не только из кэша страниц выкидывать файлы не даёт, но и в своп?

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

Кстати, видали ещё параметр, отвечающий за объём памяти, зарезервированный под немедленные аллокации. Если процесс резко запросит больше этого объёма, то он просто зависнет на этом сисколле, пока ядро расчищает для него память, или завалится?

технически не может быть неограниченным

С overcommit=1 можно терабайты спокойно выделять. Но таки да, ограничение есть.

Но с vm.swappiness=200 таки стало ещё лучше

Очень хорошо, буду тоже это тестировать. Сам-то я 100 предпочитаю. И смотрю на рекомендующих для десктопа swappiness=10 как на поехавших.

Не получится ли, кстати, что prelockd при таком раскладе будет только мешать?

prelockd-то сам по себе не идеален и, вероятно, блокирует лишнее - не все маппленные файлы используются полностью, в идеале надо бы лочить файлы лишь частично, только те части, которые реально используются.

Лок же не только из кэша страниц выкидывать файлы не даёт, но и в своп?

он не мешает своппингу, но он лочит лишнее. Это работает как запрет на отбрасывание кэша исполняемых файлов и либ.

Продолжайте наблюдение.

Когда-то реальная память закончится, и при попытке заполнить виртуальную, когда реальной для этого уже недостаточно — что произойдёт?

OOM и киллер приходят при нехватке физической. Виртуальная бесплатна и не соответствует физической же. Можно выделить терабайт виртуальной, когда доступная практически на нуле.

When this flag is 1, the kernel pretends there is always enough
memory until it actually runs out.

When this flag is 2, the kernel uses a "never overcommit"
policy that attempts to prevent any overcommit of memory.
Note that user_reserve_kbytes affects this policy.

overcommit_ratio:

When overcommit_memory is set to 2, the committed address
space is not permitted to exceed swap plus this percentage
of physical RAM.  See above.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

параметр, отвечающий за объём памяти, зарезервированный под немедленные аллокации

min_free_kbytes? отличная штука, его увеличение также помогает, особенно заметно со свопом на zram.

В прежние времена любил увеличивать его до 200000 с дефолтного 67000. С такими значениями с легкими стрессами заморозки нет. однако предполагаю, что большое резервирование также не вполне рационально и будет занимать память впустую.

Компромиссный вариант - лочить через прелокд только самый важные файлы - иксы и оконные менеджеры, например. - Это не должно занять слишком много места. Например, 150м занимается на деб10 гном для лока гнома и вяленого. В последней версии прелокд есть в конфиге ручка для частичного лока.

Или имеете в виду не min_free_kbytes?

А на моем деб9 в пределах 100 мегабайт можно залочить иксы, панель, оконный менеджер и терминал.

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

Безкостыльный вариант - это высокие значения swappiness и min_free_kbytes.

Стоит отметить, что memavaild позволяет не просто держать доступную память, но и уаравлять приоритетами при своппинге, позволяя вытеснять фоновую нагрузку и освобожная от конкуренции за ресурсы остальное группы, в том числе в которой гуй.

И смотрю на рекомендующих для десктопа swappiness=10 как на поехавших

Ну если своп на HDD, то это вполне reasonable. Лучше меньше кэша оставить, чем дёргать его лишний раз (тем более, своп обычно делают на другом разделе, и головки будут к нему бегать постоянно взад-вперёд). При наличии SSD то же самое, кэш вообще нафиг не нужен особо, а вот свопом его мучать лишний раз нечего.

Высокий swappiness имеет смысл именно для узких случаев, когда своп быстрее, чем часто используемый носитель. То есть либо zram, либо под своп выделена отдельная флешка/SSD (как ReadyBoost на винде, чому нет?), либо система вместе со свопом на SSD, но подключён ещё HDD под данные и часто шарпается, ну и т.п. Думать надо, в общем, а не тупо адвайсы читать ;)

но он лочит лишнее

Да это ж по дефолту, там вайтлист есть.

pretends there is always enough memory until it actually runs out

Да это-то читали. Произойдёт по итогу что? Сфейлившаяся аллокация у той программы, которой не повезло попасть на этот момент (первой попавшейся, без всяких OOM score)?

Или имеете в виду не min_free_kbytes?

Вроде его.

С такими значениями с легкими стрессами заморозки нет

А как это помогает? Эта ж память резервируется только под аллокации, а не под файловый кэш. А фризится обычно именно на подтягивании файлов с диска. Так что эта память просто откусана от кэша как раз выходит.

вы тут опять хернёй занимаетесь, вместо закидывания жручего софта в ограниченную cgroup

Да с ним особого смысла нет ;)

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

Когда-то закидывали, много возни :C Даже скриптик валяется для этого дела.

Тем более, не всегда можно предсказать, кто обожрётся. Это чего, и консольщину всякую типа less или pandoc в цгруппу класть? Они запросто могут обожраться входных данных.

можно всё подозрительное закидывать, ведь требуется только зарезервировать памяти под гуй, это не так уж и много

Ну если своп на HDD, то это вполне reasonable

Ну ккто в 2020 использует своп на HDD?

кто на ссд - свопят на ссд, остальные - zram/zswap. - Все это хорошо заходит с swappiness=100

Сфейлившаяся аллокация у той программы

При оверкоммите=1 аллокации не фейлятся (если процесс не выделяет десятки терабайт), просто кончается физическая память с последующим оом.

но он лочит лишнее

Да это ж по дефолту, там вайтлист есть.

Лишнее не в том смысле, что лишние процессы, а в том, что файлы целиком, когда можно было б лочить их лишь частично.

Эта ж память резервируется только под аллокации, а не под файловый кэш.

хз как, но факт остается фактом

Вот thrash-protect под высокой нагрузкой реально хулиганить начинает, сигстопает всё подряд, даже баши

есть у меня вариант скрипта для для заморозки именно тяжелых фоновых процессов. Детектитт проблему на основе psi метрик. Например, если memory full avg10 > 10, то морозит дочерние процессы до снижения давления. Таким образм, посторонние процессы типа гуя не подвергнутся негативному влиянию, морозится только дочерняя группа.

Применение:

$ psi-stop make -j 666

Подобным образом успешно скомпилял ядро.

Работающий прототип - http://okturing.com/src/9600/body