LINUX.ORG.RU

Запись на флешку: скачок и подвисание.

 , , ,


4

6

В CentOS7 используя Nautilus закидываю _на_ флешку 460.7MB файл. Статус сразу скачет до 459.6MB и работа продолжает кипеть. Т.к. флешка медленная, то минуты 2! Затем «460.7MB» и ок.

Черт возьми, это достало! Жутчайший треш в интерфейсе, не отражающий состояние системы. Другие ФМ делают тоже самое! Корни где-то ниже уровнем. Даже rsync, с указанием --progress, ничего не показывает, пока не запишется 99% файла.

Причем в обратную сторону, с флешки, копируется равномерно.

Что заметил: даже запуская «sync» - он не отрабатывает, пока не запишется файл на флешку целиком.

Как заставить Linux писать на флешку по-нормальному, кусками например, по 5MB?

UPD уточнение про rsync: rsync отрабатывает за секунду, показывая «sent 460,857,140 bytes received 35 bytes 307,238,116.67 bytes/sec», потом флешка продолжает минуту мигать. Асинхронность, мать её.

Deleted

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

у меня была как-то мысль написать микроутилитку, чтобы она --

копировала бы файловое дерево (регулярные файлы и пересоздавала бы символьные ссылки.. а также время изменения файлов и unix-права (без сохранения uid-пользователя разумеется))

по следущиму алгоритму:

при копировании файлов (при проходе по дереву): накручиваем счётчик мегобайтов всего скопированого.

при перевале счётчика за 32MiB — сбрасываем счётчик и ждём fsync() на текущем открытом (в работе) файлвом дескрипторе текущего файла (файл может оказаться маленьким, но всё равно может попасть под раздачу fsync() :-)).

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

при начале копирования очередного файла (файлвого дерева) — проверять что внутри того списка файловых дескрипторов не накопилось ли более 200 файловых дскрипторов. если накопирось, то 100 из них (наиболее старых) мы подвергаем fsync() и close().

после обработки всего файлового дерева — занимаемся всеми оставшимися незакрытыми файловыми дескрипторами (fsync() и close())..

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

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

наверно плохой алгоритм: нужна правка такая:

после перевала счётчика за 32MiB делаем fsync() на всех в текущий момент открытых файловых дескрипторах и затем close() на дескриптарах которые в списке готовых файлов.

(но это не отменяет того что мы должны сделить за размером списка открытых файловых дескприторов)

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

Монтируй флешку с параметров sync,

это дало замедление раз в 8, по сравнению с тем, когда испольвал дефолт и контроллировал по команде 'sync' реальное попадание данных на флешку

Deleted
()
Ответ на: комментарий от Deleted
echo 10485760 > /proc/sys/vm/dirty_bytes

Затем пробуй копировать. Индикация будет более адекватной.

Если всё нормально, то пропиши установку опция через sysctl.

vm.dirty_bytes

kostik87 ★★★★★
()

зачем на серверной осиgui?

anonymous
()

dd bs=4M if=file_name of=/dev/sdX status=progress && sync

zoloz
()
Ответ на: комментарий от kostik87

Узнаю древний «фикс» 12309. Можно и с другими параметрами поиграть, вот небольшое описание. У меня раньше было так:

echo 4194304 > /proc/sys/vm/dirty_bytes
echo 4194304 > /proc/sys/vm/dirty_background_bytes

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

Имеет. На 8 дебиане без этих параметров при копировании, особенно на съёмные носители, у меня всё жёстко тормозило. И не только у меня, этот рецепт был найден как «фикс».

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

В данной теме не обсуждалась проблема 12309, я об этом.

Ну и у меня, к счастью ничего не тормозит и без этого параметра.

kostik87 ★★★★★
()

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

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

Монтируй флешку с параметров sync

Какой ужасный совет.

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

echo 4194304 >/proc/sys/vm/dirty_bytes

нет.

все остальные программы (кроме той одной программы которая копирует файлы на USB-Флешку) нужно чтобы работали как раньше — без каких-либо изменений.

а ты аноним предлашаешь перенастраивать целиком-всю систему.. серьёзно? долбанулся чтоль?

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 3)
Ответ на: вот такая получилась микро-утилитка от user_id_68054

coding: utf-8 -*- — в python 3.x это всё ещё нужно?

Название неудачное. Лучше что-то типа copy2usb (глянул — уже занято...)

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

необходимости в этом нет именно для Пайтона. это просто для текстовых редакторов.

вообще лучше бы на C переписать .. на Python чисто чёрновичёк я думаю :-)

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

В mc абсолютно та же фигня (да, у меня такая же ситуация, как у ТС). Причём это началось с какого-то ядра, раньше такого не было. Вроде с 4.14, но могу ошибаться.

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

Кстати, копировал только что сам на раче, таки да, тоже самое.

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

Они и работают как раньше. Какую ещё систему перенастраивать, долбанулся чтоль?

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

cp2usb

красиво ты придумал. верно..

я особо долго не выдумывал — «slow-copy» звучит редкостно нудно, но зато я хоть знаю что оно работает :-)

и, может быть, имеет смысл объединиться с https://github.com/dmerejkowsky/pycp

неужто программ для копирования файлов — не меньше чем аудиоплееров? :-)

а как я объединюсь? там же у него какие-то сложные украшательства (прогрессбары) в которых я не разбираюсь.. кстати может и не так сложно

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

там же у него какие-то сложные украшательства

Попробовал собрать пакет в арче — ну его к лешему, у него ещё и несколько зависимостей из АУР-а...

greenman ★★★★★
()

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

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

эт где? тут https://github.com/polymorphm/slow-copy/releases ?

а как сделать чтобы такого не было бы? :-D

я ведь эти тарболы не делал — за меня их GitHub сам придумал

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

Как сделать — не знаю. Только у других такого не наблюдается.

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

это дало замедление раз в 8, по сравнению с тем, когда испольвал дефолт и контроллировал по команде 'sync' реальное попадание данных на флешку

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

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

Это ты не понимаешь работы предмета и пытаешься своё незнание себе оправдать.

Бгг. Ламер 80lvl? Слышал звон, да не знаешь где он?

Это ты совершенно не в курсе как работает USB и почему хоть усрись, а запись на флешку всегда будет пакетами равными EP Size. И никакие буфера не помогут вообще, всё равно на каждые 512 байт (обычно такой размер EP флешек) будет отдельный URB и отдельный USB request. Хоть монтируй с sync, хоть sync в консоли пиши - результат будет абсолютно одинаковым - 100500 512-байтных URB. Можешь запустить usbmon и убедиться самостоятельно.

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

Это ты хорошо себя описал, у dd дефолтный размер буфера как раз 512, если его не увеличить значительно, он пишет очень медленно.

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

Это ты хорошо себя описал, у dd дефолтный размер буфера как раз 512, если его не увеличить значительно, он пишет очень медленно.

Ты совсем дурак, что-ли? При чём тут размер буфера dd? Речь о размере пакета USB. Марш читать USB Specification, их все можно на халяву скачать на usb.org, а то ведь так и будешь путать тёплое с мягким.

Сцуко, развелось ламерья, ещё имеют наглость советы давать и сраные сцылки на совершенно левую хероту в педивикии постить.

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

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

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

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

Это ты не имеешь ни малейшего представления, что такое USB Storage Class, как оно устроено и как оно работает. Вообще. Но, тем не менее имеешь наглось что-то там вякать. Если бы ты знал хоть что-то о работе железа которым ты пользуешься, то был бы в курсе, что если ты хочешь обсуждать размер блока именно программы dd применительно к записи на USB флешку, то нужно вести речь о размере блока 13 * 512байт - ибо именно 13 bulk трансферов можно запихать в 1 микрофрейм на high-speed, Соответственно, при величине блока dd меньше ~7кбайт USB шина получается банально недогружена, потому что каждый следующий syscall write будет относится к следующему микрофрейму, а не выполнятся мгновенно. Дальнейшее увеличение размера блока никак на фактическую скорость записи на USB флешку не повлияет, выигрыш будет только за счёт уменьшения количества syscall'ов.

Ды вот, если копирующая софтина при включённой опции sync на примонтированной ФС копирует файл кусочками меньше 7к, чтобы свои сраные свистелки и перделки показать, то будут ощутимые тормоза, по сравнению с отсутствием опции sync и sync вручную. Если же софтина нормальная, перделок и свистелок не показывает на кажый килобайт, то отличий никаких не будет, потому что и в том и в другом случае будет происходить совершенно идентичный процесс передачи пакетов по USB.

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

Больше 13 * 512байт проверять пробовал?

уменьшения количества syscall'ов
если копирующая софтина

Ну так вот.

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

Больше 13 * 512байт проверять пробовал?

До этого размера скорость растёт почти пропорционально размеру блока, что очевидно, после - очень медленно поднимается до максимальной скорости флешки. Можешь сам попробовать, это несложно.

Ну так вот.

Что вот? Не пользуйся унылым говном с прогрессбарами и прочими свистелками и монтируй флешки с sync - волосы будут гладкими и шелковистыми, и никаких тормозов, флешку можно выдёргивать сразу без всяких, и всё такое.

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

Можешь сам попробовать, это несложно.

Я вдохновился этим советом, и решил потестить. Взял JetFlash TS2GJF160, достаточно старенькую двухгиговую флешку. Неплохая скорость записи для того времени.

Монтируем с опцией sync, меряем

dd if=/dev/zero of=largefile bs=$((1*512)) count=4000 status=progress
В левом столбце размер bs, в 512-байтных единицах. В правом — скорость в kB/s, которую показывает dd, что бы это ни значило:
1	11
2	15,2
3	21,7
4	23
5	27,8
6	30,7
7	36,9
8	27,6
9	45
10	47,2
11	49,1
12	51,2
13	51,9
14	53,3
15	54,9
20	59,2
25	64
30	66,2
32	69
50	72,5
64	74
128	79,9
256	80,4
512	83,6
Насыщение есть, но я бы не сказал, что оно в районе 13. Скорее, где-то около 128. И 80 килобайт в секунду это очень грустно.

Теперь монтируем без sync, но зато в параметры к dd добавляем oflag=sync. От этого он открывает файл с флагом O_SYNC. В столбцах, как и раньше, размер в 512-байтных единицах и скорость в kB/s:

1	50,3
8	76,5
16	117
32	228
64	446
128	848
256	1600
512	2700
1024	4200
2048	5700
4096	6800
8192	7700

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

Вывод.
Ты можешь сколько угодно потрясать стандартом, и делать на основе вычитанных оттуда сведений какие-то выводы. Но это не повлияет на реальность, которую я вижу перед собой. Монтирование с опцией sync роняет скорость записи в такие глубины, о которых я и не подозревал.

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

Бгг. И тебя ни разу не насторожила скорость записи в 70 мегабит на флешку? :)

Не, мамкины тестеры ничему, похоже не учатся. Т.е. вообще ничему. :)

Stanson ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.