Является ли "дросселирование обратной связи" решением "проблемы остановки USB-накопителя"?
Чтобы grep основывался на одном столбце имени пользователя (и печатал только файлы), вы можете попробовать:
ls -la | grep "^-\S\+\s\+\S\+\s\+rahmu"
Для каталогов измените - на d, для любого типа удалите -.
По сути, он выбирает каждый столбец по \S\+\s\+, который соответствует непробельным символам, за которыми следуют пробельные символы, поэтому мы сопоставляем три первых столбца, а затем имя пользователя.
Проблема заключается в том, что в статье «Зависание USB -флешки» нет доказательств. Были подлинные проблемы с «зависанием USB-накопителя -», и подобные сообщения продолжают поступать. Однако тема, обсуждаемая в статье LWN, не является одной из них! Поэтому мы не можем привести статью в качестве примера. Кроме того, любые объяснения, которые он дает, должны быть ошибочными или, по крайней мере, неполными.
Подводя итог связанному ответу:
Проблема, о которой сообщалось ядру linux -, не не видела зависания всей системы во время сброса кэшированных записей на USB-накопитель. В первоначальном отчете Артем просто жаловался, что Linux допускает очень большое количество кэшированных операций записи на медленном устройстве, которые могут занимать до «десятков минут», прежде чем они завершатся.
Как вы сказали, предложенное Линусом «исправление» не было применено. Текущие версии ядра (v4.20 и более ранние версии )по-прежнему позволяют системам с большим объемом оперативной памяти создавать большие объемы операций записи в кэше страниц, запись которых может занять много времени.
В ядре уже был некоторый код, предназначенный для предотвращения «задержек USB -флешки». Это код «Нет -грязного регулирования ввода-вывода». Этот код также был описан на LWN в 2011 году.Он ограничивает вызовы записи ()для управления как размером общего кэша обратной записи, так и долей кэша обратной записи, используемой для конкретного резервного устройства . Это сложная инженерная система, которая со временем дорабатывалась. Я уверен, что он будет иметь некоторые ограничения. Пока я не могу количественно оценить какое-либо ограничение. Также были исправлены различные ошибки, не связанные с грязным кодом регулирования, для проблем, из-за которых он не мог работать.
WBT ограничивает количество отправленных запросов ввода-вывода для каждого отдельного устройства. Он не ограничивает кеш обратной записи, т.е. кеш грязных страниц .
Артем опубликовал дополнительный отчет о том, что запись 10 ГБ на внутренний диск сервера приводила к зависанию системы или, по крайней мере, к очень длительным задержкам ответа. Это согласуется с проблемой, которую WBT стремится решить.
Примечания сохранены из предыдущих версий этого ответа:
Сценарий, описанный для WBT, возникает, когда вы записываете большой пакет данных на ваш основной диск, и в то же время вы хотите продолжать интерактивно использовать свой основной диск, загружать программы и т. д.
Напротив, когда люди говорят о проблеме «зависания USB -флешки», они имеют в виду запись большого пакета данных на другой диск / внешний USB и т. д., а затем страдают от неожиданных задержек в программах, которым нечего делать. с этим диском. Пример:
«Даже такие простые вещи, как перемещение окон, могли заикаться… Это не было нагрузкой на ЦП, потому что сеансы ssh к удаленным машинам отлично реагировали; вместо этого казалось, что все, что могло смутно приближаться к выполнению операций ввода-вывода файловой системы, сильно задерживалось.."
- https://utcc.utoronto.ca/~cks/space/blog/linux/USBDrivesKillMyPerformance
- https://utcc.utoronto.ca/~cks/space/blog/linux/FixingUSBDriveResponsiveness?showcomments
В ветке списка рассылки 2013 года о проблеме с USB-накопителем упоминались -ограничения устройства на кэш грязных страниц как возможность для будущей работы .
WBT не работает с планировщиками ввода-вывода CFQ или BFQ. Debian и Fedora по умолчанию используют CFQ, поэтому WBT не поможет ни для USB-накопителей (, ни для вращающихся жестких дисков ), если у вас нет специальной конфигурации.
Традиционно CFQ хорошо работал с вращающимися жесткими дисками. Я не совсем уверен, где это оставляет WBT. Может быть, главное преимущество WBT для SSD, которые быстрее, чем вращающиеся жесткие диски, но слишком медленны, чтобы обращаться с ними как с оперативной памятью?
Или, может быть, это аргумент в пользу использования планировщика deadlineи отказа от функций CFQ. Ubuntu переключился наdeadlineв версии 14.04 , но вернулся к CFQ, начиная с версии 17.04 (пикантной). (Я думаю, что CentOS 7.0 слишком стар для WBT, но утверждает, что использует CFQ для дисков SATA и deadlineдля всех остальных дисков. CentOS 7.0 также поддерживает диски NVMe, но показывает только «none » для их планировщика.)