LINUX.ORG.RU

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

 , ,


0

2

Семь лет штабильно работал, и тут внезапно:

[5660927.384895] mount.ntfs-3g[673]: segfault at 45d1b68b6880 ip 00007feb2fee4eb4 sp 00007ffd6c50f7e8 error 4 in libc-2.30.so (deleted)[7feb2fdd0000+14a000]

Почему — непонятно. Заметили аж через полчаса. Ставили примерно в тот момент обновления, но вроде ничего связанного не обновляли: ни fuse, ни glibc, mount разве что. До этого более трёх месяцев аптайма было.

При обращении к точке монтирования лезли ошибки transport endpoint is not connected. fusermount -u /media/d тоже не отрабатывал: device or resource busy, только с -uz отработал. После перемонтирований было то же самое, причём, что самое странное — даже при монтировании ядерным NTFS-драйвером в новую директорию.

Думали, раздел накрылся. Загрузились в винду, прогнали chkdsk /I D: — вроде всё чисто. Загрузились обратно — работает.

@hakavlad, Ваш prelockd может быть к этому причастен? OOM killer в dmesg не было точно, но вот из-за нехватки памяти сам завалиться мог, жручий же.

Куда это репортить-то вообще (и есть ли смысл?) Форум Tuxera анально огорожен вроде, да и глухо там. Драйвер три года не обновлялся, 1:2017.3.23AR.3-3 стоит.

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

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

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

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

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

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

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

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

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

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

mertvoprog ()

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

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

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

Кроме одной:

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

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

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

кто жручий?

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

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

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

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

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

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

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 МБ, и уже потом завис.

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

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

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

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

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

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

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

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

см также

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

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

hakavlad ★★ ()

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

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

hakavlad ★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от mertvoprog
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pretends there is always enough memory until it actually runs out

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

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

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

Вроде его.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применение:

$ psi-stop make -j 666

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

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

hakavlad ★★ ()