Процесс Ntfs загружает процессор

Обновлено: 05.07.2024

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

mount.ntfs и процент ЦП

В последнее время у меня наблюдаются вялые/временные зависания, и я заметил одну вещь: процесс с именем mount.ntfs потребляет до 100 % ресурсов ЦП во время некоторых из этих эпизодов. Что это такое, и могу ли я что-нибудь с этим сделать, используя столько %?

Привет, плохое лекарство! Вы редактировали файл /etc/fstab? Не могли бы вы опубликовать это здесь, пожалуйста?

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

Если ваша проблема решена, будьте так любезны и укажите это, отредактировав название темы в первом сообщении. :)

Я не редактировал его, насколько мне помнится, но я легко забываю некоторые вещи На самом деле я не могу вспомнить, как найти содержимое fstab, но как только я это сделаю, я могу опубликовать его.

Я вручную монтирую свой накопитель каждый раз при запуске Linux, если это помогает. Кроме этого я ничего не монтирую на регулярной основе.

bad Medicine написал: Не помню, как найти содержимое fstab, но как только найду, могу выложить.

Запрос на просмотр содержимого fstab состоял в том, чтобы проверить, нет ли в этом файле проблемы. Здесь ничего нет. Проблема в другом.

Иногда я использую флэш-накопитель, но я никогда не использовал его, когда % ЦП резко возрастал. Не использовал ни одного за неделю. Кроме этого, я никогда не использую внешний диск.

Да, у меня есть раздел Windows, раздел восстановления и прочий хлам, которого я даже не помню

Число Начало Конец Размер Тип Файловая система Флаги
1 1049 КБ 12,6 ГБ 12,6 ГБ основной ntfs diag
2 12,6 ГБ 12,9 ГБ 300 МБ основной ntfs boot
3 12,9 ГБ 118 ГБ 105 ГБ основной ntfs
/>4 118 ГБ 320 ГБ 202 ГБ расширенный lba
5 118 ГБ 275 ГБ 157 ГБ логический ntfs
7 275 ГБ 316 ГБ 41,2 ГБ логический ext4
6 316 ГБ 320 ГБ 4079 МБ логический linux-swap(v1)

% меняется так быстро, что трудно выполнить команду прямо перед тем, как она упадет. Но вот 2 примера, снятых как можно быстрее, когда я увидел % на уровне 30% (первый) и 70+%. Они могут быть одинаковыми, я не сравнивал

При копировании файлов из одного раздела ntfs во второй раздел ntfs процесс mount.ntfs использует 42–49 % ресурсов процессора (вероятно, 100 % на одном ядре). Второй процесс mount.ntfs использует 5% процессорного времени. (используется «conky» для проверки)

/ и /home на первом диске sata (ext4)
исходный файл на втором диске sata (ntfs)
целевой файл на третьем жестком диске sata (ntfs)

Ubuntu 9.10 Alpha 1 (актуальная версия)

Athlon 2xCore
чипсет nvidia 570

Dependencies.txtEdit (4,5 КиБ, text/plain; charset="utf-8")
ProcMaps.txtEdit (44,9 КиБ, текстовый/обычный; charset="utf-8")
ProcStatus.txtEdit (762 байта, text/plain; charset="utf-8")

Ошибка подтверждена путем копирования 2 ГБ из раздела ntfs-3g в другой раздел ntfs-3g на локальном диске

Это происходит потому, что процесс mount.ntfs должен обрабатывать файловые операции на обоих дисках.
Каждый раз, когда вы копируете или вставляете в раздел ntfs, процесс mount.ntfs занимает определенное количество ресурсов ЦП.

Изменено в ntfs-3g (Ubuntu):
status:< /td>	Новое → Подтверждено

Мы с женой используем Jaunty 64bit со всеми обновлениями. У меня есть диск ntfs, расшаренный через Samba. Она копирует файл размером 20 ГБ на мой диск со своего локального диска ext3. Мое использование ЦП достигает 100%.

Я только что загрузил версию ntfs-3g в свой PPA, связанный с его собственным внутренним FUSE. Не могли бы вы попробовать установить этот пакет и сообщить мне, наблюдается ли по-прежнему высокая загрузка ЦП?

*** Отказ от ответственности: этот пакет полностью не тестировался мной, поэтому используйте его с осторожностью ***

< /tr>

Я не знаю, является ли это другой ошибкой, но я оставлю ее здесь.

Копирование 3,7 ГБ (DVD iso) на жесткий диск USB, отформатированный в FAT32, дает постоянную скорость около 26 Мбит/с. Переформатируй в NTFS и повтори: скорость начинается так же, но падает до 11Mb. Это не может быть фрагментация, так как диск только что был отформатирован. Первоначально у меня была проблема при перемещении 8 ГБ на внешний жесткий диск, который начинался со скорости 19 Мбит / с, но закончился со скоростью 2 Мбит / с до завершения копирования файла. Использую версию 9.10. Я регулярно копировал данные в свои разделы NTFS под 9.04 и не было никаких проблем.

Очень высокая загрузка ЦП на mount.ntfs, 70%+

Подтверждаю здесь с 9.10 final. Та же проблема: 100% загрузка процессора mount.ntfs

Вот еще один сценарий, который приводит к той же проблеме.
Загрузка с помощью Transmission DVD ISO CentOS и сохранение загруженного файла на диск NTFS (внутренний или через USB).
Через некоторое время загрузка ЦП настолько высока, что Transmission больше не загружается, он просто ждет (подобно режиму заморозки), пока ntfs-3g что-то не сделает (высокая загрузка ЦП), и, таким образом, загрузка является доброй. застопорился. Итак, на данный момент я загрузил около половины (1,7 ГБ) DVD ISO, и когда я запускаю Transmission, он просто потребляет мощность процессора (и электроэнергию) практически без каких-либо значительных затрат.

Это немного расстраивает, так как на моем Linux-разделе недостаточно места для загрузки DVD ISO.

Примечание: с Jaunty загрузка ЦП также была очень высокой, однако мне удалось загрузить DVD ISO предыдущего выпуска CentOS.

Все вышеперечисленные проблемы были и у меня. С передачей то же самое, он зависает после загрузки нескольких гигабайт данных. Я также пытаюсь скопировать 8 ГБ на свой раздел ntfs, но скорость загрузки снижается с 10 МО/с до 190 КБ/с. Так что ждать немыслимо, я возвращаюсь в Windows, чтобы сделать копию.
Я использую Ubuntu уже несколько лет, и раньше у меня никогда не было этой проблемы.

У меня есть еще одна проблема. Когда я открываю evince(pdf), компьютер зависает, и я вынужден нажать кнопку питания для перезагрузки.

Думаю, я вернусь в Веселый.

У меня такая же проблема 2.
У меня 100% загрузка ЦП на 1 ядро. % одних 10% других.
Проблема при передаче и копировании.
Оба мерзнут.
Передача останавливает загрузку. и, наконец, вылетает. ..
даже 1 DVD не может быть загружен полностью.
Процессор начинает нагреваться до 70´C. Вентилятор продолжает работать.
Ошибка должна быть исправлена в ближайшее время.
:(

ntfs-3g отлично подходит. я использовал его с 3 лет назад

но когда я играл в ритмбокс, он начинал поиск аудиофайлов на моем жестком диске[ntfs]
автоматически, затем ntfs-3g играл основную роль в качестве ключевого игрока при использовании
загрузки процессора более 99% долго[3 дня безотказной работы]
Боже мой, как жестоко

аудиофайлы моей коллекции достигают 40 ГБ

Есть ли какие-либо идеи для решения этой проблемы, это не происходит таким же образом,
когда я получаю доступ к аудиофайлу из ext3?

gnewsense deltah(последний)

Та же проблема, Кармическая Коала. Просто скачайте пару торрентов прямо в раздел NTFS. Использование ЦП постоянно высокое 88%.

Когда я копирую большие файлы на жесткий диск USB с файловой системой NTFS, используется 80 % ресурсов ЦП, а скорость снижается до 9 МБ/с вместо 30 МБ/с.

Иногда мой жесткий диск начинает работать очень тяжело, и мой процессор на 100 % используется mount-ntfs. Даже если я вообще не работаю с NTFS разделом (и у меня не установлен Трекер). Обычно это происходит вскоре после загрузки и занимает несколько минут.

У меня та же проблема.

У меня такая же проблема. Загрузка торрента размером 40 ГБ с передачей приводит к случайным блокировкам передачи и использованию одного ядра на 90 % из-за mount.ntfs.

Я копирую файл размером 8 ГБ из раздела Ext4 на USB-накопитель с файловой системой NTFS, и загрузка ЦП составляет 80 %. Скорость передачи составляет 7 МБ/с.

Это Ubuntu Karmic.

Меня тоже затронула эта ошибка. При копировании с или на раздел ntfs скорость передачи начинается нормально, но затем останавливается. Затем я получаю 100% загрузку ЦП, 0,2% использование памяти, и, что интересно, при использовании iotop я получаю в общей сложности только 20 кб/с операций записи на диск, и все из-за процесса mount.ntfs. Это происходит в Ubuntu Karmic, ядро 2.6.31-17-generic с использованием ntfs-3g версии 1:2009. 4.4-1убунту4. Интересно, занимается ли кто-нибудь этим, потому что это действительно неприятная проблема.

Возможна взаимосвязь между ntfsg и устройством-часами.
Эта проблема возникает на моем ноутбуке (ibm t41p) с параметром загрузки: clock=pit

Также возникла проблема: при передаче больших файлов в раздел ntfs или из него система становится едва пригодной для использования (Core2 Duo).
Я вижу высокую загрузку системы на системном мониторе Gnome Panel, но не могу подтвердить высокую загрузку процессора (по крайней мере, не в htop).

кстати, мои часы спешат.

Насколько я помню, в Jaunty мне такое не приходило в голову

У меня такая же проблема. Передача больших файлов Файлы размером более 4 ГБ. Перенос осуществляется с одного диска SATA 10 000 об/мин на другой диск SATA 10 000 об/мин. Скорость начинается нормально примерно до первых 4Gb. Затем скорость неуклонно падает. ЦП остается на уровне около 100% для одного ЦП (имеют четырехъядерный процессор i7). Запуск Ubuntu 9.10.

Дополнительное тестирование показало, что запись действительно больших файлов просто должна с большей вероятностью воспроизвести проблему, но на самом деле это не является обязательным требованием.С разделом NTFS, близким к емкости (осталось около 4 ГБ), я смог воспроизвести проблему, записав в него файл размером чуть меньше ГБ. Когда я заметил, что запись файла замедлилась на несколько секунд, я прервал и освободил еще полГБ (всего освободилось около 4,5 ГБ). Затем я смог записать свой не очень большой файл на нормальной скорости. Так что, похоже, это может быть связано с каким-то странным краеугольным случаем фрагментации.

Я тоже столкнулся с этой проблемой. Копирование ~ 6 ГБ, 5 файлов на 8 ГБ флешку ntfs увеличивает мою нагрузку до 6-7. После этого все действия с файловой системой блокируют nautilus примерно на 20 секунд.

Скорость передачи начинается примерно с 48 МБ/с, а затем снижается до 700 КБ/с.

Также заметил, что ntfs-3g медленно читает и пишет. Я использовал Fedora 12 и Ubuntu 9.04, у обоих одна и та же проблема. у меня также есть rtorrent и conky, установленные на моем Ubuntu 9.04, но если я хочу что-то скачать, я должен оставить компьютер, пока он не закончит загрузку. Даже зависание указателя, не говоря уже о просмотре или работе при копировании информации. rtorrent работает со скоростью 10 МБ/с всего несколько секунд, просто чтобы заполнить весь кеш, а затем скорость падает до 1,5 МБ/с или 6 МБ/с, если я ничего не трогаю.

пожалуйста, объединитесь с другими дистрибутивами Linux и устраните эту надоедливую ошибку. Все типы операций, которые подразумевают копирование, чтение и запись на разделы ntfs, невероятно медленны и замораживают машину.

Подсказка. с utorrent под wine такой проблемы нет, может кто воспользуется знаниями wine для написания хорошего драйвера для ntfs.

ntfs-3g также зависает при запуске виртуальной машины для меня в Lucid Lynx. Это регресс, поскольку стандартные настройки виртуальной машины решили проблему в версии 9.10.

Та же проблема у меня в Lucid! Сильное снижение скорости передачи при копировании больших файлов из разделов ext4 в разделы ntfs (а также FAT32). Начинается с 27 МБ/с (ноутбук HD) и снижается до 1 МБ/с при постоянной загрузке ЦП на 100%. Я знаю, что ntfs-3g имеет плохую производительность при записи, но описанное поведение выглядит для меня скорее как ошибка. Подобные симптомы возникают даже при записи в FAT32.

Та же проблема у меня в Lucid!

Существенное снижение скорости передачи при копировании больших файлов с разделов ext4 на разделы ntfs. Начинается с 500 КБ/с, я действительно не могу найти решение этой проблемы!!

Та же проблема с Lucid Lynx.

Копирование 3 огромных файлов (всего 80 ГБ, разреженные файлы) с внешнего жесткого диска USB2, отформатированного в XFS, в раздел NTFS заняло более 1500 минут *процессорного времени* для монтирования.ntfs.

если это действительно важно: двухъядерный процессор AMD, 3 ГБ ОЗУ, внутренний диск SATA2.

Возможно, ошибка должна быть помечена как «подтвержденная», а не как «неполная», поскольку высокая загрузка ЦП наблюдается и в более новых версиях?

Очень, очень, ОЧЕНЬ надоедливая ошибка. Обходных путей никто не нашел? (кроме того, что я полностью не использую ntfs, но для меня это почти невозможно)

Я сделал пакет debian с результатом, изменил версию, чтобы она не «обновлялась», и установил ее. mount.ntfs практически не отображается в системном мониторе (ksysguard) в KDE.

Можно выполнить
./configure
make
sudo make install с извлеченным архивом, но мне нравится упаковка deb, так что ее можно легко удалить. Мне пришлось удалить связанный файл «lib», сопровождающий ntfs-3g в Ubuntu.

Я не прикрепил его, потому что не совсем знаком с протоколом здесь.

У меня такая же проблема на K/Ubuntu 10.04 (2 ГБ оперативной памяти, E6750, ASUS P5B Deluxe). У меня есть 4 жестких диска SATA, с системой на первом (ext4) и различными данными на трех других (ntfs). Копирование 200 ГБ файлов из ie. второй-третий диск делает систему почти непригодной для использования. Пробовал версию 2010.8.8 ntfs-3g, производительность чуть лучше, но все равно очень высокая: около 50-60% загрузки процессора monut.ntfs и около 20% mc при копировании файлов с одного диска на другой.

Проблема у меня решается после установки:

неофициальная (PPA) сборка исходной версии ntfs-3g 2010.8.8.

Изменено в ntfs-3g (Ubuntu):
важность:< /td>	Не определено → Среднее
Статус:	Подтверждено → Не завершено

Изменено в ntfs-3g (Ubuntu):
status:< /td>	Не завершено → Подтверждено

Возможно, у меня такая же проблема на 10.04.1 LTS

При перемещении файлов из раздела NTFS в другой (на другой диск) я получил скорость 13747 байт в секунду (13 КБ/с).
Я вижу загрузку ЦП на 50-90% в одном из процессов mount.ntfs, и время безотказной работы говорит:
15:46:09 до 2:28, 2 пользователя, средняя загрузка: 2,07, 2,06, 1,94

У меня на машине Pentium 4 HT 3 ГГц, поэтому вычислительной мощности должно быть достаточно.

В разных сценариях я наблюдал производительность более 50 МБ на тех же дисках с использованием ntfs-3g.
Похоже, это зависит от файлов, возможно, от размера файла.

[Решено] Высокая загрузка ЦП процессом mount.ntfs-3g

Привет,
Недавно у меня возникла проблема с mount.ntfs-3g (Debian Stretch), например, когда я открываю gparted. Я думаю, что это могло начать происходить, когда решили использовать жесткие ссылки в разделах ntfs. Может быть, это связано с большими каталогами с жесткими ссылками ntfs?

Любая помощь, пожалуйста

Я заметил аналогичную проблему при копировании файлов на съемный носитель (внешний жесткий диск), который содержит файловую систему NTFS. Процессор используется примерно на 20-30 процентов. Однако при копировании с внешнего жесткого диска на диск, расположенный в компьютере (внутренний жесткий диск), используется только 5 процентов ЦП.

None1975 писал(а): Заметил аналогичную проблему при копировании файлов на съемный носитель (внешний жесткий диск), который содержит файловую систему NTFS. Процессор используется примерно на 20-30 процентов. Однако при копировании с внешнего жесткого диска на диск, расположенный в компьютере (внутренний жесткий диск), используется только 5 процентов ЦП.

Дело в том, что я ничего не копирую, иногда, когда я запускаю gparted, открытие занимает около 5 минут из-за разделов ntfs (mount.ntfs-3g работает с высоким процессором в течение пяти минут или около того)..

Я попробую удалить жесткие ссылки в разделах ntfs. У меня есть пять резервных копий папок с жесткими ссылками в этих разделах, я использовал их для восстановления неудаленных файлов в ntfs

учитывая, что вы посвятили себя запуску frankendebian (что это было, ядро Ubuntu на стабильной версии Debian?) - кто знает, почему это происходит, кроме вас?

debiman написал: учитывая, что вы посвятили себя запуску frankendebian (что это было, ядро Ubuntu на стабильной версии Debian?) — кто, кроме вас, знает, почему это происходит?

user@hall:/media/sda1/.SDA1/6-20180821_02:26:34/BACKINTIME/Youtubes/asa$ ls
ls: чтение каталога '.': Ошибка ввода/вывода

Возможно, это была проблема, которая вызывала проблемы с процессором драйверов ntfs-3g. Я собираюсь выяснить, как решить эту проблему, я думаю, я должен перезагрузиться в Windows и запустить chkdsk и попытаться удалить эти плохие папки.

ntfsresize v2016.2.22AR.1 (libntfs-3g)
Имя устройства: /dev/sda1
Версия тома NTFS: 3.1
Размер кластера: 4096 байт
Текущий том размер: 60001612288 байт (60002 МБ)
Текущий размер устройства: 60001615872 байт (60002 МБ)
Проверка на наличие поврежденных секторов.
Проверка целостности файловой системы.
Выполнено 0,00%
Выполнено 0,03%
.
Выполнено на 99,95%
Выполнено на 99,98%
Выполнено на 100,00%
Бухгалтерские кластеры .
Сбой учета кластера по адресу 12732863 (0xc249bf): дополнительный кластер в $Bitmap
.
Ошибка учета кластера 13997687 (0xd59677): дополнительный кластер в $Bitmap
Ошибка проверки файловой системы! Всего 9 кластерных учетных несоответствий.
ОШИБКА: NTFS несовместима. Запустите chkdsk /f в Windows, затем перезагрузите его ДВАЖДЫ!
Использование параметра /f очень ВАЖНО! Это программное обеспечение не вносило
никаких изменений в файловую систему NTFS, пока не будет исправлено.

Хорошо, проблема решена (я запустил chkdsk /f в Windows, затем перезагрузил ее ДВАЖДЫ!)

user@hall:/media/sda1/.SDA1/6-20180821_02:26:34/BACKINTIME/Youtubes/asa$ ls
ls: чтение каталога '.': Ошибка ввода/вывода

Эта ошибка не означает аппаратную проблему. Это может быть вызвано поврежденной файловой системой. Аппаратная проблема будет отображаться в журналах ядра.
chkdsk не исправит проблемы с поврежденными блоками без /r.

user@hall:/media/sda1/.SDA1/6-20180821_02:26:34/BACKINTIME/Youtubes/asa$ ls
ls: чтение каталога '.': Ошибка ввода/вывода

В моей файловой системе смонтированы два раздела NTFS. На одном из них размещаются мои проекты, так что это очень важно.

Время от времени мой компьютер становится медленным, иногда почти зависает. Я заметил, что всякий раз, когда это происходит, процесс mount.ntfs показывает спящий режим в столбце ЦП системного монитора ksysguard (см. снимок экрана ниже).

Примечательно, что в таких ситуациях память не заканчивается, а процессоры не работают на полную мощность.

Каковы возможные объяснения этого и как это исправить?

Я использую Kubuntu 19.04, 64-разрядную версию.

1 Ответ 1

В некотором смысле "спящий режим" не является причиной замедления работы, а всего лишь симптомом.

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

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

Причин может быть несколько:

Происходит много операций чтения или записи на диск (на этот физический диск в целом; не обязательно на этот конкретный раздел). Чтобы определить, является ли это причиной, начните с:

iotop или iotop -Pao для просмотра отдельных программ, выполняющих ввод-вывод в данный момент;
iostat -h 1 для отчета об общей скорости ввода-вывода для каждого физического устройства хранения.

Диск занят чтением поврежденной области. (Иногда на жестких дисках появляются поврежденные сектора — иногда сектор можно прочитать только после дюжины повторных попыток; иногда он полностью не читается, но вам нужно подождать, пока жесткий диск перестанет пытаться.)

dmesg или dmesg -w, чтобы узнать, сообщает ли диск об ошибках чтения или других аппаратных проблемах.

В ядре могут быть ошибки, например. диски, подключенные через USB 3.0 в высокопроизводительном режиме «UAS», в прошлом часто вклинивали всю систему.

Снова dmesg, но на этот раз ищите ядро, сообщающее о собственных зависаниях без соответствующей ошибки чтения с диска.

Если ваш проект важен, даже одиночная ошибка, о которой сообщается в 'dmesg', означает, что вы должны остановить все и сделать резервные копии на другой диск. (На самом деле, если ваш проект действительно важен, вы уже должны были делать резервные копии.)

Читайте также: