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

dd сообщает мегабайты в секунду. :)

В столбцах, как и раньше, размер в 512-байтных единицах и скорость в kB/s:

Сложно пересчитать?

Лучше бы взял и сам проверил.

То, что с sync сильные тормоза, читал не раз.

Может быть в течении дня и сам проверю.

На, смотри:

$ for i in 1 5 10 15 20 25 50 100 200; do echo $i; dd if=test.img of=/dev/sdb bs=$((i*512)) oflag=sync; done
1
20480+0 records in
20480+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 56.26 s, 186 kB/s
5
4096+0 records in
4096+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 14.441 s, 726 kB/s
10
2048+0 records in
2048+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 8.25986 s, 1.3 MB/s
15
1365+1 records in
1365+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 6.23084 s, 1.7 MB/s
20
1024+0 records in
1024+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 4.90544 s, 2.1 MB/s
25
819+1 records in
819+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 5.24667 s, 2.0 MB/s
50
409+1 records in
409+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 3.31774 s, 3.2 MB/s
100
204+1 records in
204+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 2.59634 s, 4.0 MB/s
200
102+1 records in
102+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 2.61212 s, 4.0 MB/s

Ты ведь даже не подумал, что ты пытаешься измерять :) Ты зачем-то пишешь файл на какую-то ФС, вместо того, чтобы просто измерить скорость чистого интерфейса.

ЗЫ: Без oflags=sync у меня вообще получается для 200 блоков

10485760 bytes (10 MB, 10 MiB) copied, 0.0210274 s, 499 MB/s

То, что с sync сильные тормоза, читал не раз.

C sync будут тормоза если писать мелкими кусочками какой-нибудь гуйнёй с прогрессбаром. cp вот копирует кусками по 128кБ и никаких тормозов с sync нету.

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

Ты глуповат, да? Какие мегабиты? Читать научись, теоретик.

У тебя скорость в чём? В килобитах или килобайтах? :) dd выдаёт скорость в байтах/секунду, если что.

Flush это же по сути неявный fsync при закрытии файла.

Ты ведь даже не подумал, что ты пытаешься измерять :) Ты зачем-то пишешь файл на какую-то ФС, вместо того, чтобы просто измерить скорость чистого интерфейса.

Ты глуповат, да? Какой смысл писать напрямую на блочное устройство? Ты часто файлы копируешь прямо на блочное устройство?

dd сообщает мегабайты в секунду. :)

Ты глуповат, да? С чего ты взял, что там единицы измерения захардкожены на мегабайты в секунду?

Ты глуповат, да? Какой смысл писать напрямую на блочное устройство?

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

Ты часто файлы копируешь прямо на блочное устройство?

В общем нередко, а что?

У тебя скорость в чём? В килобитах или килобайтах? :) dd выдаёт скорость в байтах/секунду, если что.

Ты глуповат, да? Откуда ты вообще биты взял? Там B большое. Конечно же килобайты.

Ремарка о том, что это значит, относится к вопросу килобайт против кибибайт. Просто знаю, что авторы некоторых утилит намеренно используют надпись KB, хотя имеют в виду KiB. В итоге нужно в код смотреть, а я этого не сделал.

Ты глуповат, да? С чего ты взял, что там единицы измерения захардкожены на мегабайты в секунду?

Это любой идиот познавший азы арифметики поймёт, dd пишет и объём в байтах, и время рядышком. dd выводит скорость в G/M/k байтах в секунду.

Конечно же килобайты.

Ну и сколько в мегабитах у тебя выйдет 7700 килобайт в секунду?

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

То есть, тут обсуждают запись на ФС, ты влезаешь, заявляешь, что надо с sync монтировать, а потом выдаёшь цифры записи на блочное устройство? Тебя не смущает, что при записи на блочное устройство напрямую, смысла в опциях монтирования ФС на этом блочном устройстве нет? Что ты вообще доказать-то пытался?

В общем нередко, а что?

Мда.

dd выводит скорость в G/M/k байтах в секунду.

Ты только что заявлял, что в мегабайтах в секунду. А теперь там и k, и G уже появились, а не только M. Плывёшь в показаниях.

Это любой идиот познавший азы арифметики поймёт

Как арифметика с этим связана? Выбор единиц измерения — дело авторов кода. Как напишут, так и будет. Никто не мешает сделать вариант dd, который в гигабайтах в секунду всегда скорость пишет. Арифметика тут не при чём вообще.

Ну и сколько в мегабитах у тебя выйдет 7700 килобайт в секунду?

61,6 получается.

То есть, тут обсуждают запись на ФС, ты влезаешь, заявляешь, что надо с sync монтировать, а потом выдаёшь цифры записи на блочное устройство? Тебя не смущает, что при записи на блочное устройство напрямую, смысла в опциях монтирования ФС на этом блочном устройстве нет? Что ты вообще доказать-то пытался?

Ты вообще понял о чём речь?

То, что без sync какая-то произвольная софтина «пишет» быстрее - вообще ни о чём не говорит. У USB флешки есть максимально возможная скорость записи, ограниченная USB протоколом и собственно скоростью записи во флеш. Если писать на флешку очень маленькими кусочками, то скорость упирается в USB протокол. Если писать большими, то скорость упрётся в флешку. Дык вот, если при включённом sync писать на флешку по 512 байт как делает всякий упоротый софт, чтобы показывать свистелки и перделки, то скорость упрётся в протокол, а если писать нормально - то упрётся в скорость флеша. Без опции sync скорость в любом случае упрётся в скорость флеша. Т.е. при нормально написанном софте скорость будет упираться в скорость флеша вне зависимости от того, включён ли sync или нет. Для упоротого софта запросто может быть разница в скорости из-за размера блока при копировании.

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

61,6 получается.

Это USB3.0 флешка?

Это USB3.0 флешка?

Прочитай уже про теоретическую скорость USB 2.0 в стандарте, на который сам ссылался, эксперт.

Ты вообще понял о чём речь?

Замеров скорости записи на ФС от тебя что-то не было видно. Боишься, что результат будет отличаться от теоретически ожидаемого?

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

Теоретик, блин.

Прочитай уже про теоретическую скорость USB 2.0 в стандарте, на который сам ссылался, эксперт.

Скорость будет упирается в стандарт только при вызовах write с размером меньше чем 13*512 байт. Дальше скорость будет упираться в скорость записи флеша. В среднестатистических флешках USB2.0 которые продаются у нас стоят флеши со скоростью хорошо если 40 мегабит. Если очень постараться, то можно найти 2.0 флешку с флешем который и 60 и даже 100 мегабит сможет. Но вряд-ли ты тестировал на специально купленной шустрой флешке, у нас такие очень долго искать надо.

Замеров скорости записи на ФС от тебя что-то не было видно. Боишься, что результат будет отличаться от теоретически ожидаемого?

С чего бы?

$ mount | grep sdb
/dev/sdb1 on /home/stanson/Desktop/sdb1 type ext2 (rw,relatime)
$ dd if=../../../Downloads/test.img of=test.img bs=102400 oflag=sync
102+1 records in
102+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 3.31533 s, 3.2 MB/s

...
$ mount | grep sdb
/dev/sdb1 on /home/stanson/Desktop/sdb1 type ext2 (rw,relatime,sync)
$ dd if=../../../Downloads/test.img of=test.img bs=102400 oflag=sync
102+1 records in
102+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 3.37469 s, 3.1 MB/s

Скорость от sync не зависит.

Скорость будет упирается в стандарт только при вызовах write с размером меньше чем 13*512 байт. Дальше скорость будет упираться в скорость записи флеша.

Ишь как заговорил. Тут вот по-другому писал: Запись на флешку: скачок и подвисание. (комментарий). Так стоит блок больше 13*512 байт использовать или нет? А то ведь из твоих слов выходит, что нет.

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

man «математика», man «оценка сверху»

Это флешка с хорошей скоростью записи для своего времени. Я же название модели привёл. Мог бы и погуглить, её бенчмарки в интернете есть. Не самая лучшая, конечно, но лучше всего того, что я вообще вживую тогда видел. Более того, при записи мелкими блоками она выигрывала у ширпотреба того времени в разы. Если уж с ней такие плачевные результаты, чего говорить о ширпотребе.

Это называется «оценка сверху».

С чего бы?

Название модели устройства, на котором тестишь, в студию!

bs=102400

А чего не 6656? :-D

Попробовал, кстати, записывать на ext2 с bs=102400, получается аж мегабайт в секунду. На FAT32 получается заметно печальнее. В этом смысле ext2 лучше. Но если ты считаешь, что на всех флешках будет ext2, ты неадекват.

Кстати, что это за флешка у тебя такая на 10 мегабайт?

Ну, а у меня так:

$ mount | grep sdb
/dev/sdb1 on /run/media/user/D1C7-53FC type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

[D1C7-53FC/]$ dd if=~/Desktop/warezz.rar of=./warezz.rar bs=102400 oflag=sync
4499+1 records in
4499+1 records out
460744533 bytes (461 MB) copied, 143.353 s, 3.2 MB/s

### VFAT SYNC-mount:

$ mount | grep sdb
/dev/sdb1 on /run/media/user/D1C7-53FC type vfat (rw,nosuid,nodev,relatime,sync,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

[D1C7-53FC/]$ dd if=~/Desktop/warezz.rar of=./warezz.rar bs=102400 oflag=sync
4499+1 records in
4499+1 records out
460744533 bytes (461 MB) copied, 1103.54 s, 418 kB/s

### EXT2 SYNC-mount:

$ mount | grep sdb
/dev/sdb1 on /run/media/user/94a35032-0139-440c-b430-8975549cebea type ext2 (rw,nosuid,nodev,relatime,sync,uhelper=udisks2)

[8975549cebea/]$ dd if=~/Desktop/warezz.rar of=./warezz.rar bs=102400 oflag=sync
4499+1 records in
4499+1 records out
460744533 bytes (461 MB) copied, 718.161 s, 642 kB/s

Трансенд JetFlash какой-то 1Гиговый. Ситуация аналогичная для сентос7 и федоры, дефолт

ext2 обгоняет по скорости vfat, вот это поворот! :)

Не будем забывать, что топик о проблеме с индикацией копирования всеми адекватными и первыми «приходящими на пальцы» способами (cp+pv, rsync, mc, разные файловые менеджеры), а не скоростью. dd может решить проблему с индикацией, он то как раз делает всё такими блоками, как указали. Шутка про «лучший редактор - это dd» становится всё менее смешной.

Ишь как заговорил. Тут вот по-другому писал: Запись на флешку: скачок и подвисание. (комментарий).

Щито??? Ещё раз объяснить, почему шина USB будет тормозить если писать мелкими пакетами? Или почему всё упрётся в скорость записи флеша при больших пакетах?

Так стоит блок больше 13*512 байт использовать или нет? А то ведь из твоих слов выходит, что нет.

Только такие блоки и стоит использовать, чтобы не было тормозов.

Трансенд JetFlash какой-то 1Гиговый.

Старенький?

А что у тебя hdparm -g /dev/sdb говорит?

старенький

$ sudo hdparm -g /dev/sdb

/dev/sdb:
 geometry      = 1010/32/61, sectors = 1972224, start = 0

Название модели устройства, на котором тестишь, в студию!

Первое попавшееся говно:

 lsusb -d 090c:1000 -v

Bus 002 Device 012: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x090c Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
  idProduct          0x1000 Flash Drive
  bcdDevice           11.00
  iManufacturer           1 UFD 2.0
  iProduct                2 Silicon-Power4G
  iSerial                 3 1110082800001207

# fdisk -l /dev/sdb
Disk /dev/sdb: 3.8 GiB, 4048551936 bytes, 7907328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe799e8c8

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1        2048 7907327 7905280  3.8G 83 Linux

# hdparm -g /dev/sdb

/dev/sdb:
 geometry      = 1020/125/62, sectors = 7907328, start = 0

Кстати, что это за флешка у тебя такая на 10 мегабайт?

Она на 4 гига. Файлик просто 10 мегов.

Попробуй её разметить с другим количеством «головок»/«цилиндров» - fdisk -H 224 -S 56 /dev/sdb Чтобы в одном «цилиндре» было целое количество 128k блоков и раздел был выровнен опять же на 128k. Может поможет.

Файлик просто 10 мегов.

То есть ты пишешь в ту область, где должны быть FAT-таблицы? Попробуй писать куда-нибудь в середину.

То есть ты пишешь в ту область, где должны быть FAT-таблицы? Попробуй писать куда-нибудь в середину.

Разницы никакой. Флеш с размером erase блока в 128К без всяких костылей.

Разницы никакой. Флеш с размером erase блока в 128К без всяких костылей.

Вообще-то лет десять назад проскакивали сообщения о том, что в некоторых флешках использовали два типа памяти. Контроллер их склеивал в одно устройство. В результате получалась «быстрая» флешка, у которой скорость потом значительно падала.

Если твоё заявление подкреплено экспериментом, то норм. Правда, непонятно тогда, почему ты просто результаты не показал.

Вообще-то лет десять назад проскакивали сообщения о том, что в некоторых флешках использовали два типа памяти. Контроллер их склеивал в одно устройство. В результате получалась «быстрая» флешка, у которой скорость потом значительно падала.

Этим уже давно не занимаются.

Если твоё заявление подкреплено экспериментом, то норм. Правда, непонятно тогда, почему ты просто результаты не показал.

Да лениво просто просто гигабайтные файлы записывать или переразбивать на 2 раздела, чтобы что-то кому-то доказать. Да и закончится это всё тем, что потом непременно потребуется ещё какой-нибудь пруф, а потом ещё один, и ещё... А если учесть, что мне тащемта абсолютно насрать на проблемы неосиляторов, у которых sync тормозит, то смысла в этом нет вообще никакого.

Этим уже давно не занимаются.

Так трудно проверить, что ли?

Да лениво просто просто гигабайтные файлы записывать или переразбивать на 2 раздела

Ну, в общем, понятно, почему трудно тебе. У dd есть опция seek, она помогает.

А если учесть, что мне тащемта абсолютно насрать на проблемы неосиляторов, у которых sync тормозит, то смысла в этом нет вообще никакого.

Вот и сидел бы в своём УМВР уголке. Чего вылез-то?

Тебе уже как минимум два человека показали, что опция sync для флешек это ад. Но нет, тебе же надо в грудь себя тапком бить, доказывая, что у тебя всё работает. Только потом выясняется, что пишешь ты на блочное устройство напрямую, а не на ФС. А когда всё-таки до тебя доходит, что для файлов нужна файловая система, тестишь на ext2. Ну конечно же все всегда ext2 используют! (Спойлер: нет).

В итоге все твои УВМР — только для кучи условий, о которых ты конечно же умолчал.

Так трудно проверить, что ли?

Что проверять? Тебе сцылку на даташит флеша дать, что-ли?

Ну, в общем, понятно, почему трудно тебе. У dd есть опция seek, она помогает.

И как она поможет записать файл в середину диска, причём на ФС ?

Вот и сидел бы в своём УМВР уголке. Чего вылез-то?

Потому что иногда задалбывает нытьё приползших с венды неосиляторов, у которых вечно ничего не работает.

Тебе уже как минимум два человека показали, что опция sync для флешек это ад. Но нет, тебе же надо в грудь себя тапком бить, доказывая, что у тебя всё работает.

Ну если бы показыватели подумали головой, то и у них бы тоже всё работало.

Только потом выясняется, что пишешь ты на блочное устройство напрямую, а не на ФС

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

А когда всё-таки до тебя доходит, что для файлов нужна файловая система, тестишь на ext2.

Какая разница, есть там файловая система или нет, если оно торомзит из-за записи мелкими кусками, даже без ФС вообще?

Ну конечно же все всегда ext2 используют! (Спойлер: нет).

Ну так валите на винфак со своим FAT и нойте там что оно тормозит, что вы тут тогда ноете?

Я вот FAT только на образах бутявок наблюдаю, образы эти на флешку заливаю при помощи dd и до ФС в них мне нет никакого дела. Где ещё я могу пересечься с этой FAT, если я не сношаюсь постоянно с вендами, и уж тем более не копирую ничего на них посредством флешек?

В итоге все твои УВМР — только для кучи условий, о которых ты конечно же умолчал.

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

Так стоит блок больше 13*512 байт использовать или нет? А то ведь из твоих слов выходит, что нет.

Только такие блоки и стоит использовать, чтобы не было тормозов.

Нет, этот параметр у каждой флешки свой

Так що делать-то? dd юзать заместо наутилуса?

echo 4194304 > /proc/sys/vm/dirty_bytes

Нет, этот параметр у каждой флешки свой

Это параметр USB high-speed режима, етить! Абсолютно одинаковый для всех USB2.0 флешек умеющих high-speed. В одном микрофрейме может быть максимум 13 bulk-трансферов. Максимальный размер bulk-трансфера - 512 байт. Длительность микрофрейма - 125мкс. Каждая новая операция write будет в новом микрофрейме. Соответственно, последовательные write'ы по 512 байт это 512 байт каждые 125мкс, последовательные write'ы по 13*512 байт это 6656 байт каждые 125мкс.

У самого флеша может быть разный размер erase блока, однако сегодня почти все современные флешки имеют размер erase блока в 128k, да ещё и контроллер флешки, как правило, берёт на себя оптимизацию и буферизацию erase-write циклов, поэтому этот параметр почти не влияет на скорость записи. В древних флешках контроллер был туповат, поэтому можно было попытаться оптимизировать «геометрию» USB флешки так, чтобы запись одного блока ФС не приводила к erase-write сразу двух блоков флеша.

fsync(fd) :-)

[*]

В одном микрофрейме может быть максимум 13 bulk-трансферов. Максимальный размер bulk-трансфера - 512 байт. Длительность микрофрейма - 125мкс

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

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

Ну если найдёшь USB2.0 флешку, контроллер которой снабжён полноценным write кэшем - сообщи. Только непонятно как она себя будет вести при выдёргивании даже после sync. Чтобы не было факапов там унутре должна быть батарейка или конденсатор весьма приличной ёмкости. Я флешек с батарейками или большими кондёрами не видел ни разу.

Это параметр USB high-speed режима, етить!

А вы об этом ... С моей колокольни тут рулит размер erase блока а не особенности протокола USB.

однако сегодня почти все современные флешки имеют размер erase блока в 128k

Это так было лет 10 назад. Я пять лет назад глубоко погружался в тему: тогда средними размерами были 256k и 512k.

запись одного блока ФС не приводила к erase-write сразу двух блоков флеша.

Когда я занимался флешками - главной проблемой было чтобы не записывать один и тот самый блок за несколько подходов.

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

Туда ставят ионисторы. Они выглядят как батарейка от миниатюрных женских кварцевых часов, но по параметрам ближе к конденсаторам большой емкости. Главное отличие от батареек - ионисторы припаиваются к плате.

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

А вы об этом ... С моей колокольни тут рулит размер erase блока а не особенности протокола USB.

Размер блока тоже рулит.

Это так было лет 10 назад. Я пять лет назад глубоко погружался в тему: тогда средними размерами были 256k и 512k.

Зависит от размера обычно. На ширпотребных дешёвых флешках 2-8Гб размер и сегодня обычно 128k.

Когда я занимался флешками - главной проблемой было чтобы не записывать один и тот самый блок за несколько подходов.

Сейчас контроллеры обычно не делают erase блока при последовательной записи более мелких кусков, если erase блока уже случился при предшествующих SCSI Write. Но помнить об уже стёртых блоках контроллер будет только до ресета или пропадания питания. Не знаю, правда, сколько всего стёртых блоков может помнить контроллер.

На ширпотребных дешёвых флешках 2-8Гб

4-16ГБ

На 2 не в любом ларьке магазине уже и найдёшь.

4-16ГБ

Вот на 16Гб уже скорее всего побольше 128k будет. Так-то и на 4Гб erase block может быть в 1Мб, и даже 4Мб у какого-нибудь хуникса, но во флешках они редко попадаются.

На 2 не в любом ларьке магазине уже и найдёшь.

Просто USB-флешка на 4 стоит теперь почти столько же, сколько и на 2, поэтому их и перестали завозить, а может уже и производить даже. Сами-то NAND на 16Гбит (2048x8) (и даже более мелкие) вполне производятся.

Зависит от размера обычно. На ширпотребных дешёвых флешках 2-8Гб размер и сегодня обычно 128k.

Хмм ... Согласно моего опыта это зависит от древности технологии.

Сейчас контроллеры обычно не делают erase блока при последовательной записи более мелких кусков, если erase блока уже случился при предшествующих SCSI Write.

Я думаю что это для меня новость.