ntfs-3g + большой объем I/O
Вчера приобрел себе по случаю материнку ASUS P8H67-V и Core i5-2310. Ранее пользовался Core2Duo плюс материнка ASUS P5Q SE plus (чипсет Intel P45). Ядро пересобрал, но в него добавил только поддержку USB-3.0 и драйвер для сетевушки, остальное оставил как есть. Диски использую в режиме AHCI.
Вчера понадобилось переписать файл размером 105Гб с локального диска (NTFS) на USB-3.0 накопитель (NTFS). К копированию данных вопросов нет: скорость около 70 Мб/c, достаточно быстро. Но, в процессе копирования, имеет место быть большой I/O wait, такой, что load average ~=3.5. Соответственно, система на момент этой операции была практически неюзабельна. Раньше я как-то не замечал таких чудес, все было хорошо. Теперь, собственно, вопрос, если кто в курсе: это кривые руки, особенности ntfs-3g, или я халатно отнесся к конфигурированию ядра?
Спасибо за внимание.
- Для комментирования войдите или зарегистрируйтесь
ntfs-3g - это FUSE, а значит,
ntfs-3g - это FUSE, а значит, операции с ФС на уровне пользователя. Поэтому работа с большими файлами всегда будет тормозить систему.
Не грусти, товарищ! Всё хорошо, beautiful good!
.
Как бы про FUSE понятно, да. Может, я ошибаюсь, но всегда думал, что ntfs-3g использует async I/O. В этом случае вроде бы не должно так быть... Да, я не упомянул еще об одной детали: копировал я в mc, чтоб скорость посмотреть. А вот если mc пользуется sync I/O, то тогда очень может быть, что торможение вызвал именно mc. Только раньше я тоже копировал довольно большие файлы в mc, но не с/на NTFS, и не на этом железе, а еще на старом. И вроде не припомню хоть какого-то дискомфорта, хотя бывало и по 40 минут копировалось...
как уже вам ранее ответили mc
как уже вам ранее ответили mc тут не при чем.
все дело в FUSE. попробуйте ядерный драйвер для сравнения - он FUSE не использует. вам же только читать надо с ntfs.
.
Ммм... Вы в курсе, отчего бывает I/O wait? И как, собственно, работает IFS driver, и в чем различие между FUSE и не-FUSE? Ну, кроме того, что написано в аннотации к пункту конфига в ядре и в пользовательской документации?
.
Пробовал.
Именно ядерным.
Правда давно это было...
Читать. Но порядочно (десятки гигабайт).
И процессор грузит ого-го, и копирует ме-е-едленно.
ЗЫ: Впрочем, недавно бросал достаточно большие файлы на флешку...
По одному получилось бы _намного_ быстрее (это намёк на то, что проблема может заключаться не в поддержке NTFS).
И да: каюсь и посыпаю волосы пеплом, на детальное исследование проблемы положил болт. Хоть и знаю, что это неправильно.
:wq
--
Live free or die
alexpro написал(а): Вчера
Как часто приходилось копировать большие файлы?
Есть предположение что это старая проблема ядра, которая началась, если не ошибаюсь, с версии 2.6.17. Суть в том, что при копировании больших файлов значение IOWait доходит до 100%.
Наткнулся на описание в инете года два назад -- рассказал знакомому сисадмину, он не поверил, решили проверить на практике, благо у него под рукой были системы с ядрами 2.6.9 и ~2.6.20 на одноядерных пентиумах. Проверяли командой типа
.
Так на ядре 2.6.9 команда нормально отрабатывала, комп не вис (точно не помню, но iowait был мизерным), графическая оболочка "слушалась", а на 2.6.20 -- все висло наглухо: iowait доходил до 100%, графическая оболочка вроде "слушалась", но реальный запуск приложений происходил только после завершения команды 'dd'. Сисадмин был не много удивлен.
На нескольких ядрах система не виснет, но начинает заметно подтормаживать, если для копирования больших файлов использовать команды типа 'cp', 'mv' и т.п. В частности на двух ядрах iowait доходил до 70%, сейчас проверил на Atom'е реально 2, но система (3.1.9) видит 4 -- iowait <= 50%.
Похоже на проблему решили "забить", т.к. в графических оболочках типа Gnome или KDE система особо не виснет, хотя копирование происходит медленней, чем при помощи команды 'cp'.
То что ты описал - iowait bug
То что ты описал - iowait bug На проблему никто не забивал, в баге ведётся вялотекущий спор. Скорее всего это комплекс багов, в котором сложно понять что к чему.
Ага, он, неуловимый 12309,
Ага, он, неуловимый 12309, инструкцию по его лечению можно порой найти в самых неожиданных местах, например тут: http://lurkmore.to/12309
через 10 лет 12309 победят!!!
через 10 лет 12309 победят!!!
и не прерывая процесс записи запустить Evolution, у меня через 2 минуты окно появляется)))) Но я нашел решение: не юзать ноут во время дисковых операций)))
.
Очень странно. На момент создания топика у меня было ядро 3.1.6. Сегодня собрал 3.2.5 с конфигом от предыдущего ядра, и ситуация очень сильно поменялась. Я повторил в точности то же самое, что и в титульном сообщении, и в итоге имею load average ~=0.5, и этот процесс абсолютно не влияет на работу системы. Единственное, скорость копирования упала до примерно 45 Мб/c. Интересно, что же такого могло поменяться, чтобы настолько радикально изменилось поведение? В конфиге не менял ничего существенного, кроме кое-каких изменений в разделе сетевых устройств.
Кстати, кто-то знает, на что влияет CONFIG_FSCACHE? Ну, кроме того, что написано в справке по опции?