LINUX.ORG.RU

Зависание файловой системы NTFS

 , , ,


0

1

Привет всем!

Система Linux Mint LMDE6

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

Описываю что происходит. Работаю за компьютером , потом в какой-то момент перестает отвечать на запросы файловый менеджер Nemo. Это может быть во время работы или после получасового перерыва (компьютер простаивает). Перед этим пользуюсь разным софтом , в том числе VirtualBox , Wine.

Журнал никаких ошибок не выдает , только предупреждения:

TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'
----
июн 08 05:31:05 pc kernel: nvidia: loading out-of-tree module taints kernel.
июн 08 05:31:05 pc kernel: nvidia: module license 'NVIDIA' taints kernel.
июн 08 05:31:05 pc kernel: Disabling lock debugging due to kernel taint
----
июн 08 05:31:05 pc kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  535.261.03  Sat Jun 14 16:05:50 UTC 2025
----
июн 08 05:31:09 pc pipewire[1258]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
июн 08 05:31:09 pc pipewire-pulse[1260]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
июн 08 05:31:09 pc pipewire[1258]: mod.rt: found session bus but no portal
июн 08 05:31:09 pc pipewire-pulse[1260]: mod.rt: found session bus but no portal
----
июн 08 06:17:01 pc CRON[12735]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
июн 08 06:17:01 pc CRON[12736]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
июн 08 06:17:01 pc CRON[12735]: pam_unix(cron:session): session closed for user root
июн 08 06:25:01 pc CRON[14304]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
июн 08 06:25:01 pc CRON[14305]: (root) CMD (test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; })
июн 08 06:25:01 pc CRON[14304]: pam_unix(cron:session): session closed for user root
июн 08 06:38:02 pc systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
июн 08 06:47:33 pc cinnamon-session-binary[1261]: WARNING: t+4586.07507s: Client '/org/gnome/SessionManager/Client15' failed to reply before timeout
июн 08 06:47:33 pc cinnamon-session-binary[1261]: WARNING: t+4586.07542s: Client '/org/gnome/SessionManager/Client27' failed to reply before timeout
июн 08 06:47:33 pc cinnamon-session-binary[1261]: WARNING: t+4586.07563s: Unable to find desktop file 'org.Nemo.desktop'
июн 08 06:47:33 pc cinnamon-session-binary[1261]: WARNING: t+4586.07583s: Unable to find desktop file 'gnome-org.Nemo.desktop'
июн 08 06:48:06 pc cinnamon-session-binary[1261]: WARNING: t+4619.11149s: Playing logout sound '/usr/share/mint-artwork/sounds/logout.ogg'
июн 08 06:48:07 pc cinnamon-session-binary[1261]: WARNING: t+4620.57830s: Finished playing logout sound
июн 08 06:48:07 pc cinnamon-session-binary[1261]: WARNING: t+4620.57840s: Resuming logout sequence...
июн 08 06:48:08 pc cinnamon-session-binary[1261]: WARNING: t+4621.14479s: Requesting system restart...
июн 08 06:48:08 pc cinnamon-session-binary[1261]: WARNING: t+4621.14493s: Attempting to restart using systemd...
июн 08 06:48:08 pc systemd-logind[882]: The system will reboot now!

Примерно около получаса компьютером не пользовался (примерно до 6:38 - 6:40). Попытки что-то сделать в Nemo ни к чему не приводят , приложение висит. Попытки открыть заново Nemo ни к чему не приводят. Попытка вывести каталоги на NTFS диске в терминале приводят к зависанию терминала (как будто бесконечный цикл крутится). При попытке вывести каталоги на системном диске в терминале - все хорошо.

P.S. В Windows ничего подобного не происходит , то есть грешить на харды думаю не стоит.



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

Похоже вы абсолютно правы. Несмотря на то , что диск у меня HDD , он поддерживает TRIM. Сейчас запустил вручную: sudo fstrim -v путь_к_моему_диску

И все повисло точно так , как я описывал выше. Прошло минут 10 и все опять отвисло. Теперь вопрос: а стоит ли это делать с HDD дисками? А если нет , то как это вырубить для примонтированных дисков NTFS? У меня диск монтируется так: UUID=B2462C85643379CA /media/DISK1 ntfs-3g noatime,nodev,nosuid,rw,uid=1000,gid=1000 0 0

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

Так если действительно trim, то отключи его. Совершенно незачем восемь раз на дню тримить. Когда нечего делать, раз в неделю запустишь вручную.

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

Я очень рад , что корень проблемы был найден. TRIM оказывается такие штуки вытворяет. Посмотрел таймер запуска fstrim.timer , следующая активность 15 числа , то есть он запускается раз в неделю примерно , если учесть , что проблема была 8 июня. Спасибо всем большое за участие в топике. И отдельное спасибо anonymous , который предположил , что проблема в TRIM.

IAmInLinux
() автор топика

Вообще довольно странно, что trim вызывает тормоза. Может быть для ntfs он блокирует всю фс, пока собирает информацию о свободных блоках, но если так, то это какая-то кривозадая недоделанная имплементация конкретно для ntfs.

Смысла в trim на HDD ноль, хотя и вреда он не должен приносить. Отключай, конечно.

Мне даже интересно стало. У тебя только один раздел ntfs? Если есть второй, то на нём воспроизводится? Раздел большой, много файлов? Фрагментрован?

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

Смысла в trim на HDD ноль

В случае SMR диска может быть и полезно (а в других случаях вряд ли у hdd есть поддержка trim).

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

Смысла в trim на HDD ноль

А кто-то пишет , что HDD , поддерживающие TRIM (с черепичной записью (SMR)) , нужно «тримить».

У тебя только один раздел ntfs? Если есть второй, то на нём воспроизводится? Раздел большой, много файлов? Фрагментрован?

2 диска NTFS , оба при старте монтируются. Были фрагментированы лишь на 2%. Файлов много , но и места свободного достаточно. Когда сейчас вручную запускаю TRIM на диске DISK1 , то недоступен только он и дополнительно нельзя прочитать каталог /media , в котором монтированы оба NTFS раздела. А вот вложенный каталог /media/DISK2 и его дочерние можно читать. Но это проверка в терминале. Что касается Nemo и почему он полностью виснет, а так же не запускаются его новые копии , это уже вопрос к разрабам.

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

то это какая-то кривозадая недоделанная имплементация конкретно для ntfs.

Это не «имплементация для», это часть драйвера которым примонтирован раздел. Учитывая что ntfs-3g fuse не удивительно что заморачиваться с параллельной работой там не стали.

firkax ★★★★★
()

Создаете проблемы и потом героически их преодолеваете. NTFS не предназначена для Линукс и ядро у вас старое. Не используйте NTFS, только на чтение.

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

Я вот подумал, как бы я реализовывал fstrim и что-то как-то не вижу простого, надёжного и универсального для разных ФС способа, который бы не требовал блокировки всех операций (записи) на время trim. Потому что если просто получить список свободных блоков и послать их девайсу, то есть возможность, что какие-то из свободных блоков ФС как раз решит занять и возникнет ситуация гонки.

Как мне справедливо заметили, для дисков SMR trim - осмысленная операция. И времени может занимать порядочно, ведь там надо головами двигать, данные читать и писать. Если на ntfs, к примеру, 10000 4кб пустых кусков, то это 20000 перепозиционирований головок по 20мс = 400 секунд тупняка.

Если не хочется отключать trim целиком, то я бы посоветовал исправить сервис и дописать параметр fstrim ... --minimum 32MiB (можно и побольше, например 256MiB).

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

универсального для разных ФС способа

Потому что если просто получить список свободных блоков

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

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

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

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

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

Если не хочется отключать trim целиком, то я бы посоветовал исправить сервис и дописать параметр fstrim … –minimum 32MiB (можно и побольше, например 256MiB).

Я посмотрю в этом направлении и проведу тест. Спасибо за совет!

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

и именно на этой операции драйвер зависнет, собирая эти данные

Не убеждён в этом.

Любая ФС уже хранит в себе список свободных блоков, например в виде битовой карты. В любом случае, это всего несколько десятков тысяч пар uint64, совершенно незначительный объём по нынешним временам. Хотя хранить не обязательно, можно сразу читать и переводить в команды trim.

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

First, identify the type of NTFS implementation being used. If it is a kernel-based NTFS driver, check the kernel version or kernel number associated with it, as this can affect compatibility and available features.

TylerCox
()

Если зависания происходят во время копирования на NTFS-раздел в GNU / Linux Debian в Dolphin, Считается ли это что я второй раз поймал 12309? Все диски исправны.

anonymous
()

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

safocl ★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария