LINUX.ORG.RU

Медленное копирование на флешку

 


1

3

Добрый день всем

Извиняюсь, что старую тему поднимаю. Видел архивные затухшие темы на этот счет. Но у меня на достаточно новой системе такая проблема

lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy

Флешек несколько штук. Все довольно новые (1-2 года) с USB 3. Последнюю вчера купил.

Когда копирую большой файл (гигов 10), то до процентов 50% добегает за пару секунд, а потом стопорится и невероятно медленно доходит до 10%. После попытки отмонтировать еще приходится столько же ждать пока система сообщит о том, что устройство отключено.

Нет ли у кого правильного рецепта это решить?

PS

  1. Да, забыл сказать, что дело не в NTFS. Я сначала его использовал, а затем стал пробовать extFAT. На нем и продолжил все эксперименты. Так вот с extFAT та же проблема.

  2. Находил такой совет

Открыть файл /etc/sysctl.conf и дописать строки:

vm.dirty_bytes = 4194304 vm.dirty_background_bytes = 4194304

применить изменения: sudo sysctl -p

Однако, эта настройка повлияет не только на флешки, но и на все файловые операции. Я не уверен в ее безопасности и правильности. Хотелось бы более верное решение.

PS2

РЕЗЮМИРУЮ ПО ТЕМЕ

Было 2 проблемы - неравномерное заполнение прогрессбара и медленное копирование (на глаз).

Посоветовали включить sync. Надо было создать файл /etc/udisks2/mount_options.conf и добавить в него строки:

[defaults]
ntfs_drivers=ntfs3,ntfs
ntfs:ntfs3_defaults=uid=$UID,gid=$GID,sync
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro,sync

Индикация после этого стала нормальной. Но скорость копирования в сравнении с Виндой стала в 5 раз медленнее. Отключил sync, прогрессбар стал показывать не плавный прогресс, также долго стало отмонтироваться, но копироваться, и правда, стало быстрее. Причем сильно. И данные теперь с виндой совпадают.

Попутно выяснилось, что порт, в который втыкалась флешка, хоть и был синего цвета, но работал не как USB 3.

Вот выдача lsusb

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 004: ID 0bda:568a Realtek Semiconductor Corp. Integrated Webcam
Bus 001 Device 003: ID 062a:4c01 MosArt Semiconductor Corp. 2,4Ghz Wireless Transceiver [for Delux M618 Plus Wireless Vertical Mouse]
Bus 001 Device 010: ID 0951:1666 Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50
Bus 001 Device 006: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
Bus 001 Device 002: ID 09da:0025 A4Tech Co., Ltd. A4tech 2.4G Wireless Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub - это шина USB 3.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub - это шина USB 2.

Bus 001 Device 010: ID 0951:1666 Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50 - флешка, которая, как видно сидит на Bus 001, т.е. USB 2.

Переткнул в другой разъем и картина поменялась, на такую:

lsusb
Bus 002 Device 002: ID 0951:1666 Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 004: ID 0bda:568a Realtek Semiconductor Corp. Integrated Webcam
Bus 001 Device 011: ID 062a:4c01 MosArt Semiconductor Corp. 2,4Ghz Wireless Transceiver [for Delux M618 Plus Wireless Vertical Mouse]
Bus 001 Device 015: ID 09da:0025 A4Tech Co., Ltd. A4tech 2.4G Wireless Device
Bus 001 Device 006: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

В режиме дерева:

lsusb -t   
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 10000M
    |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
    |__ Port 2: Dev 16, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 16, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 3: Dev 11, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 3: Dev 11, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 5: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 6: Dev 5, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M
    |__ Port 14: Dev 6, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 14: Dev 6, If 1, Class=Wireless, Driver=btusb, 12M

Чтобы еще точнее убедиться можно также смотреть выдачу lsusb -v или dmesg

Копирование в медленном порту (хоть он и тоже синий) - 10 Гигов за 8 минут (с sync было 25 -28 минут). Копирование в быстром порту - 10 Гигов за 3 минуты. Причем в это время я и включаю отмонтирование (засекал по часам).

Для того, чтобы прогрессбар был плавным и не было задержек с отмонтированием можно использовать библиотеку autofsync https://github.com/i-rinat/autofsync. Воспользоваться ей можно так:

  1. Клонируем или качаем репозиторий

  2. Выполняем в рабочей копии (или каталоге с кодом репозитрия)

    cmake CMakeLists.txt
    make
    

    и получаем файл autofsync.so

  3. Копируем этот файл в удобное место; например в /home/me_user/.local/lib/ (оставшийся каталог autofsync-master можно удалить).

  4. Добавляем в ~/.bashrc алиас

alias mc='LD_PRELOAD=/home/me_user/.local/lib/autofsync.so mc'

ИТОГ

Таким образом, медленно копировалось из-за того, что один из портов в компе на самом деле работает медленнее, чем должен (не поддерживает USB3, хоть и синий). И эта проблема решилась выбором другого порта.

А прогресс бар сделать плавным и избавиться от задержек при отмонтировании можно через библиотеку autofsync. Штатных средств решения проблемы не найдено.

БОНУС

Попутно скинули ссылки по полезные ресурс по флешкам - https://www.usbdev.ru/articles/

Там информация о том как узнать реальный объем флешки и как восстановить флешку.

Хотя более человеческим языком кратко это рассказано в статье https://lifehacker.ru/kak-vosstanovit-fleshku/



Последнее исправление: it07 (всего исправлений: 3)

У вас есть файл большой, есть флешка, для которой есть заявленная скорость. Вот, быстрее чем отношение размера файла к скорости флешки копироваться не будет.

А, то что индикация процесса такая, с этим только смириться.

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

Хотелось бы все же индикацию иметь верную. Еще ладно бы прогресс-бар медленно двигался. Хотя бы можно время прикидывать. Но при отмонтировании еще висит без прогресс-бара сколько.

it07
() автор топика

Когда копирую большой файл (гигов 10), то до процентов 50% добегает за пару секунд

За пару секунд 5 гигов не может скопироваться, прогрессбар брешет. Хорошо, если 1% скопировал.

Хочешь реальный прогресс наблюдать - попробуй копировать через mc

Chord ★★★★
()
Ответ на: комментарий от it07

в mc ты как раз и увидешь, что копирование ещё не закончилось, и не будешь преждевременно отмонтировать. А как прогресс покажет что всё скопировано - отмонтируешь и отмонтируется сразу. Ибо всё уже записано.

Chord ★★★★
()

vm.dirty_bytes = 4194304 vm.dirty_background_bytes = 4194304

Времён горохового Царя совет. К тому же влияющий вообще на весь дисковый ввод-вывод. Монтируй флешку с -o sync, винда именно так их монтирует.

PS. С FUSE based драйверами не работает, они не умеют в sync, так что ntfs-3g в пролёте. И ФС называется не extfat, а exfat.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от it07

Но при отмонтировании еще висит без прогресс-бара сколько.

Это сброс буфера из оперативки на накопитель, без этого никак. Что-то я даже с ходу и не скажу, что сейчас из ФМ умеет копировать в синхронном режиме.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от vvn_black

Что-то я даже с ходу и не скажу, что сейчас умеет копировать в синхронном режиме.

Практически всё умеет, кроме древней FUSE реализации exfat и ntfs-3g.

Если нужно заставить udisks2 в синхронном режиме монтировать и копировать — это делается через конфиг /etc/udisks2/mount_options.conf

[defaults]
defaults=sync

Можно более конкретно, например только для exfat, если в качестве драйвера ntfs до сих пор используется ntfs-3g, в sync не умеющий.

[defaults]
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro,sync

А можно и вот так:

[defaults]
ntfs_drivers=ntfs3,ntfs
ntfs:ntfs3_defaults=uid=$UID,gid=$GID,sync
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro,sync

Jameson ★★★★★
()
Ответ на: комментарий от anonymous

Всё будет напрямую зависеть от качества флешкиного контроллера. Даже на usb3 бывают медленные и быстрые флешки. Ещё есть такой момент, ntfs под sync не оптимизирована, она всё таки как FS для внутренних накопителей мыслилась, с кешированием записи. А вот exfat вполне нормально работает.

Jameson ★★★★★
()

При малейших аппаратных сбоях (перегрев контроллера) или ненадёжном соединении (грязные контакты с высоким электросопротивлением) флэшка, как всякое USB-устройство, переходит на протокол обмена с низкой скоростью USB 1.1: просто вероятность появления ошибок в канале приёма-передачи зашкаливает.

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от Jameson

Да, забыл добавить, подробности можно посмотреть в /etc/udisks2/mount_options.conf.example (если его нет он может в каталоге с документацией лежать). Там например для ntfs и ntfs3 упоминаются такие интересные опции как windows_names, prealloc, nocase...

Jameson ★★★★★
()
Ответ на: комментарий от it07

В mc та же песня с прогрессбаром.

Нет там никакой песни. Я вот сейчас скопировал на флешку исошник 5,5 Гиг, прогресс равномерно двигался (1минуту 17 секунд) по 1-2% пока не дошел до 100%, после этого сразу же отмонтировал, ждал сообщения что отмонтировано ровно 6 секунд.

Chord ★★★★
()
Ответ на: комментарий от anonymous

https://bugzilla.redhat.com/show_bug.cgi?id=157674

USB keys / drives are being mounted with the «sync» option. This is in the /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi file. This option causes the premature failure and destruction of flash memory with the FAT or VFAT file systems due to massive overwriting of the FAT tables. The man page for «mount» indicates that FAT and VFAT file systems ignore the «sync» option. This is not true and easy to prove by simply excercising a USB flash device with and without the sync option set.

greenman ★★★★★
()
Ответ на: комментарий от anonymous

Возможно, но ограничивать буфер вообще для всего это как то слишком тотально. Лично я никуда не тороплюсь. А так это и от контроллера флешки зависит, и от ФС, и от того пустая она изначально или с неё выборочно стирали\записывали...

Jameson ★★★★★
()
Ответ на: комментарий от it07

Ну вот у меня есть проблема с прогрессбаром и в mc

При монтировании с sync? Лично у меня всё ровно, если флешка свежеотформатированная и своего аппаратного кэша не имеет. Кстати тут правильно выше писали, на больших флешках с говноконтроллерами они перегреваются при продолжительной записи, начинают либо троттлить, либо пакеты в USB терять. Во втором случае в dmesg видно что контроллер USB её в 1.1 перемонтирует. А троттлинг контроллера самой флешки кроме тормозов никак не проявляется. Короче если флешка раскалилась и скорость записи упала — это оно.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

При монтировании с sync?

Нет конечно. Про mc в теме писали еще до того как советовали sync. Так что sync я только сейчас пробую (тестирую).

То есть версия что mc будет копировать сам по себе (при дефолтном монтировании) равномерно - не верна.

sync полностью сейчас протестирую с учетом отмонтирования и отпишусь. Предварительные результаты уже есть - прогрессбар движется равномерно. Проверяю остальное.

it07
() автор топика
Ответ на: комментарий от it07

То есть версия что mc будет копировать сам по себе (при дефолтном монтировании) равномерно - не верна.

Конечно не будет. Он грубо говоря оболочка. Даже если у него своя реализация функций копирования\перемещения он всё равно использует ядерные механизмы для работы с ФС.

Jameson ★★★★★
()
Ответ на: комментарий от it07

То есть версия что mc будет копировать сам по себе (при дефолтном монтировании) равномерно - не верна

Копировать он может как угодно, равномерно или нет (это может зависеть от флешки), это не имеет значения. Главное что когда прогресс дошёл до конца, запись тоже закончена и можешь сразу отмонтировать не ожидая по полчаса. Виден реальный момент окончания записи (+/- пару секунд)

Chord ★★★★
()
Ответ на: комментарий от Chord

Нет, без sync не виден. Реальный момент окончания записи может наступить как через пару, так и через десяток секунд, в зависимости от общего объёма ОЗУ, объёма занятого под кэш в текущем моменте ОЗУ, объёма копируемых данных и т.п. У тебя это 1-2 секунды, а у кого то секунд шесть или даже больше. Например у меня 128гб ОЗУ, и без sync при копировании с помощью MC образ размером в 4.5гб к примеру улетает в кеш целиком, моментально, после чего прогрессбар пропадает. А вот umount командную строку вернёт только тогда когда данные реально запишутся, и это будут не 1-2 сек.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

Никогда не монтировал с sync. В dolphin после прогресса можешь ждать ещё полминуты, а то и минуту-две на больших объёмах, а в mc 5-6 секунд и отмонтируется.

Как бы там ни было, время от начала копирования до момента отмонтирования будет одинаково хоть через dolphin, хоть через mc. Разница в поведении прогрессбара. В одном случае показывает ерунду, в другом - более или менее точно отображает процесс копирования и его окончание.

Chord ★★★★
()
Ответ на: комментарий от Chord

Дольфин нынче через xdg портал работает и как то хитро юзает fusefs. Возможно он, точнее портал, что то там сам по себе ещё кеширует в юзерспейсе. Как бы то ни было твой личный опыт — не показатель, так как сильно зависит от того сколько у тебя физического ОЗУ и насколько интенсивно ты её заполняешь (файловый кэш выделяется из «свободного» ОЗУ), поэтому если у тебя ОЗУ 8-16гб и при этом ты активно юзаешь браузер с кучей вкладок например — у тебя кэш маленький и органолептически накопитель ведёт себя как с sync. И ждать нужно действительно в районе секунды, потому что мелкий кэш быстро сбрасывается на диск.

Jameson ★★★★★
()
Ответ на: комментарий от vvn_black

Хороший ответ, но я поправился, имел в виду ФМ.

Вот про ФМ которые нынче через xdg портал файлы двигать начали я как то сам не уверен, они вполне могут поверх ядрёного кэша юзерспейсный юзать. А все остальные опираются на ядерный кэш. И с sync будут честно пытаться синхронно «в дырочку USB» записывать.

Jameson ★★★★★
()
Ответ на: комментарий от Chord

Сделал вот так:

cat /etc/udisks2/mount_options.conf | grep -v '#'


[defaults]
ntfs_drivers=ntfs3,ntfs
ntfs:ntfs3_defaults=uid=$UID,gid=$GID,sync
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro,sync

Для справки файл копирую 1 файл размером 10 GB.

После этих настроек действительно в exFAT прогрессбар стал равномерно двигаться. И отмонирование занимает 2-3 секунды.

Но скорость записи оставляет желать лучшего.

Чтобы избежать аргументов про плохую флешку решил сравнить с виндой.

В общем на винде скорость записи на флешку этого файла составляла 60 МБ/c. На Линуксе - 6 МБ/c

Только вот что подумал пока писал сообщение. Это, правда, на разных компьютерах. И предвидя, что сейчас причину могут начать искать в этом проверю на всякий случай на одном с перезагрузкой в разные ОС.

it07
() автор топика
Ответ на: комментарий от it07

В общем на винде скорость записи на флешку этого файла составляла 60 МБ/c.

Верится с трудом. Скорее всего, здесь где-то ошибка, скорее всего. Такие флешки, конечно, в природе существуют, но они очень дорогие. «Обычные» флешки обычно пишутся со скоростью от 5 до 20 МБ/с. Советую перепроверить ещё раз.

CrX ★★★★★
()
Ответ на: комментарий от CrX

Вполне может быть что и нет, какие то хронические проблемы со скоростью с sync действительно есть, многие уже десятки лет на это жалуются. Причём у кого то их не было и нет, а у некоторых sync немедленно провоцировал тот самый «легендарный баг IO» при котором всё раком вставало (номер бага к сожалению забыл). Причём в винде всё нормально, и по дефолту «кеширование записи» отключено для внешних носителей.

Я тащемто сам sync не пользуюсь, попробовал, убедился что он действительно «делает прогрессбар ровным», и отключил. Во первых потому что меня «неровный прогрессбар» не напрягает, во вторых я приучен отмонтировать и «безопасно извлекать», а в третьих мне из общефилософских соображений понятно что с кэшем лучше чем совсем без кэша.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Причём в винде всё нормально, и по дефолту «кеширование записи» отключено для внешних носителей.

Вряд ли там sync, скорее вариант flush mount option (только для fat; и есть ощущение, что почему-то заброшено в linux)

greenman ★★★★★
()
Ответ на: комментарий от CrX

Нет, не нормально.

Проверил теперь на одном и том же компе. Только в разных ОС С одного и того же SSD пишу на одну и ту же флешку.

Линукс - 4-5 МБ/c Винда - 20-25 МБ/c

Перепроверял 3 раза

it07
() автор топика
Ответ на: комментарий от it07

Линукс - 4-5 МБ/c Винда - 20-25 МБ/c

Запросто может быть такое.
В Винде порт работает как USB-3 (есть драйвер под конкретную микруху), в Линуксе - как USB-1 (нет драйвера - работает универсальный).
Общий вывод - хочешь скорости копирования, вместо USB-флэшек используй usb-переходник на SSD m2

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 3)
Ответ на: комментарий от Jameson

Я тащемто сам sync не пользуюсь, попробовал, убедился что он действительно «делает прогрессбар ровным», и отключил. Во первых потому что меня «неровный прогрессбар» не напрягает, во вторых я приучен отмонтировать и «безопасно извлекать», а в третьих мне из общефилософских соображений понятно что с кэшем лучше чем совсем без кэша.

Аналогично, кстати.

CrX ★★★★★
()
Ответ на: комментарий от it07

Линукс - 4-5 МБ/c Винда - 20-25 МБ/c

Это с включенным sync?

А если попробовать с выключенным? Забить на показания прогрессбара и тупо замерить время от начала копирования до полного отмонтирования флешки в винде и линуксе.

Для чистоты эксперимента и уменьшения погрешности лучше брать файл побольше.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от Jameson

а в третьих мне из общефилософских соображений понятно что с кэшем лучше чем совсем без кэша.

Не уловил. Применительно к записи флешку (где только и есть у меня exFAT) какая польза от этого кеша?

it07
() автор топика
Ответ на: комментарий от CrX

Это с включенным sync?

Да

А если попробовать с выключенным? Забить на показания прогрессбара и тупо замерить время от начала копирования до полного отмонтирования флешки в винде и линуксе.

Вы таки моей смерти хотите, сударь )))) Может решусь попозже. Очень утомительны такие эксперименты

Для чистоты эксперимента и уменьшения погрешности лучше брать файл побольше.

Линукс эти 10 гигов итак более 20 минут пишет. Куда еще больше?

it07
() автор топика
Ответ на: комментарий от it07

Грубо говоря с буфером ядро будет более полно использовать «полосу пропускания» интерфейса чем без буфера. Например за счёт меньшего количества команд и прерываний.

Jameson ★★★★★
()
Ответ на: комментарий от it07

Вы таки моей смерти хотите, сударь )))) Может решусь попозже. Очень утомительны такие эксперименты

Ну, не я советовал включить sync ;)

Он точно никак не ускорит запись. Сделает прогрессбар точнее — это да. Но на фактическую скорость записи либо не повлияет, либо ухудшит.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от it07

А есть те, кто экспериментирует (для разных значений dirty_bytes / dirty_background_bytes)

автоматический flush для для всех дисков (комментарий)

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от CrX

В лучшем случае «заметно не повлияет», это да. Ну и любители дёргать флешку из дырки сразу после исчезновения прогресбара без отмонтирования имеют меньше шансов угробить ФС или потерять часть данных.

Jameson ★★★★★
()