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