Почему при копировании на внешний диск окно прогресса отображается некорректно

Не стесняйтесь редактировать заголовок, чтобы лучше объяснить, что я собираюсь написать здесь.

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

Это происходит не только с большими файлами, но и со многими небольшими файлами. Если я скопирую их, индикатор выполнения, например, скажет 15 секунд и завершится за это время, но реальное время может составить 1 минуту, и в течение следующих 45 секунд мне нужно будет реально посмотреть на индикатор в ручке, чтобы увидеть, есть ли это реальная деятельность на этом.

Я не хочу знать, как это исправить, так как я прочитал, как глубоко это можно исправить. Я хочу знать, почему тогда в окне прогресса отображается оценка, которая не соответствует процессу копирования.

Это зависит от кеша во внешнем блоке?

Размер файла и размер файла влияют на правильную оценку. Например, 1 файл объемом 4 ГБ или 1000 файлов размером 4 МБ.

Есть ли параметры конфигурации, которые могут изменить поведение.

Есть другие вопросы, подобные этому, такие как копирование файлов на USB-флешку, которое никогда не было закончено, но я больше сосредоточен на механике, объясняющей, почему она будет вести себя так.

Я полагаю, что вы используете Nautilus в качестве файлового менеджера, и в этом случае имеются давние ошибки по этому поводу. Слишком глупо, чтобы упоминать о воздействии Mint, Fedora, Red Hat и тому подобное. Ubuntu не без этой же проблемы.

Некоторые предлагают отключить просмотр миниатюр. Другие надеются на «новейшее ядро», но оно все еще существует.

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

Работа вокруг, кажется, sudo cp /filetobecopied /dev/nameofdevice

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

Это также хороший ответ с решением: https://unix.stackexchange.com/a/181236 Он говорит:

Это происходит потому, что программа говорит «записать эти данные», а ядро ​​Linux копирует их в буфер памяти, который ставится в очередь для перехода на диск, а затем говорит «хорошо, готово». Так что программа думает, что скопировала все. Затем программа закрывает файл, но внезапно ядро ​​заставляет его ждать, пока этот буфер будет выгружен на диск.

Так что, к сожалению, программа не может сказать вам, сколько времени займет очистка буфера, потому что она не знает.

Если вы хотите попробовать некоторые хитрости для опытных пользователей, вы можете уменьшить размер буфера, который использует Linux, установив / proc / sys / vm / dirty_bytes примерно на 15728640 (15 МБ). Это означает, что приложение не может получить больше чем 15 МБ перед его фактическим прогрессом.

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

Но не устанавливайте это слишком маленьким! Я использую 15 МБ для приблизительной оценки того, что ядро ​​может сбросить буфер на обычный жесткий диск за 1/4 секунды или меньше. Это удерживает мою систему от ощущения "отставания".