Зачем slowest_runner заблокировали?

Ты видимо не сначала читал, тут этих пользователей дисков хоть отбавляй. И распечатывать с принтера, чтобы потом читать - это не нормально, причём абсолютно не нормально. Распечатки нужны только для отчётности, и то только потому что если отчётность будет в электронном виде то от неё проще избавиться либо по-быстрому переделать.

Фигасе ты дал. С каких это пор дисками пользуются только старые маразматики? И с какого это перепугу распечатывать для того, чтобы читать - стало не нормально? У меня, к примеру, куча книг по администрированию, которые представляли из себя просто сканы страниц, без свякого там форматирования - просто картинка. Я что, дебил возиться с ними в ридере? Конечно же они все у меня распечатаны и сброшюрованы - получается ничуть не хуже исходных книжек.

Читать с экрана художественную литературу - невыносимо... + в ***** ваши читалки. А DVD хороший вариант для складирования информации, хоть на долго хоть на время, даже если это время пару часов или дней. Учитывая что в реале цена DVD не превышает 10 рублей.

С каких это пор дисками пользуются только старые маразматики?

Может и молодые ещё есть, но их возможно меньше.

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

А у кого-то, к примеру, куча перацкой венды, которая представляет собой просто образ диска, безо всяких там наклеек - просто болванка.

Два чая этому почтенному дону.

Читать с экрана художественную литературу - невыносимо...

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

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

А чем вам читалки не угодили? Вы современным e-Ink-ом пользовались?

Как много книг в год вы читаете? Спрашиваю с точки зрения приобретения и хранения литературы. Я до приобретения читалки прочитал книг достаточно, чтобы забить большой шкаф (и по деньгам нехило, ибо в хорошем переплёте). А на читалке прочитал почти половину прежнего, к тому же комфортнее из-за возможности увеличить шрифт. Лично мне читалка сэкономила много денег и пространства.

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

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

Вы современным e-Ink-ом пользовались?

Он настолько хорош, что может сравниться с качеством печати на бумаге?

ибо в хорошем переплёте

Дело вкуса, конечно, но в личной библиотеке любимые, да и просто хорошие, книги должны быть именно такими - в хорошем переплете. Держать их в электронном виде - кощунство, имхо.

Да, бумажные страницы так приятно шуршат, их можно поглаживать, трогать,

Вот же ж фетишист!

в них можно что-нибудь оборачивать...

Солёную рыбу, например.

Он настолько хорош, что может сравниться с качеством печати на бумаге?

В принципе, да. Читаю много с kindle paperwhite - глаза вообще не устают. Попробуйте сами.

некоторые пытаются противопоставить флешки дискам

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

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

Видимо сильно беспокоятся об объёмах продаж дисков, бумаги и т.п.

Давай, перечисли альтернативы.

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

Видимо сильно беспокоятся об объёмах продаж флешек, карт памяти и т.п.

cdemu + любимая грабилка, умеющая делать bin/cue (readcd/readom вроде умели)

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

А по пространству и деньгам, у меня книг хватает еще от родичей.

А покупать как-то особо и нечего. Уже написано много, а нового, действительно чтоб стоящего не фонтан и даже не прудик.

... а при чём скорость сброса данных на блины для приложения или ОС? Ни приложение (в т.ч. и тестовое), ни ср ни чего не знают о блинах, скорости их вращения и времени позиционирования головок. Им это не нужно.

В тестах (да, почему-то на ntfs?) используется block size, изменяемый случайным образом от 512 байт до 4К. У меня используется xfs с фиксированным block size в 32К. 64К не рискнул. Пока не запишется/не прочитается блок, головки перепозиционированы не будут. Время позиционирования здесь важно. Например, в SSD позиционироваться нечему, там время доступа крайне мало. А вот в электро-механических HDD, оно роль играет. По этой причине, при больших размерах файлов, лучше не ставить block size в 4-8К (тем более в 512байт, хоть это и размер физического сектора винчестера), а использовать 16-32-64К. Правда, есть один минус, он заключается в том, что файлы не кратны размеру блока. Т.е., даже если в блок записано всего 1-2К, будет занят блок в 32К в моём случае. Но на терабайте это мелочи.

Вот таким нехитрым способом можно повысить производительность ФС в случае СУБД, архивов или видео, а не расчитывать «скорость сброса данных на блины». Пока до блинов дойдёт, данные в 2-3 буферах отлежаться успеют. И здесь важна скорость передачи и размер буфера, а скорость сброса на блины вторична.

Зачем вообще ставить ОС с флешки, если есть устройства наподобие http://habrahabr.ru/post/116799/

можно положить хоть 50 образов и не мучиться с организацией загрузочного меню

Вот таким нехитрым способом можно повысить производительность ФС.

Но не скорость записи/считывания на блины - именно в неё упирается производительность HDD.

Ну, может, у его харда буфер тоже в терабайт размером, чтоб ОС могла на 500 МБ/с забить его данными, а там уж пусть хоть полчаса на блины сбрасывается — с точки зрения программы копирования дело сделано, скорость полгига в секунду показана, юзер кончилсчастлив.

Да, почти так...

... именно почти, потому что:

буфер тоже в терабайт размером

Буфер не в терабайт, само собой. Но довольно большой, чтобы нормально поддерживать скорость обмена согласно спецификации USB 3.0 до 5Gbit/s (не Gb/s, а Gbit/s!).

Причём, этих буферов как минимум два — на стороне хоста, к которому подключён накопитель и на стороне самого по себе накопителя (не HDD накопителя, а самого по себе накопителя).

а там уж пусть хоть полчаса на блины сбрасывается — с точки зрения программы копирования дело сделано

Да. Именно так. Пока всё на блины не сбросится, накопитель нельзя отмонтировать. Пока структура ФС не всосётся, накопитель нельзя примонтировать. Эти временные потери не учитываем. Однако, в любом случае Вы здесь правы — «с точки зрения ОС или программы копирования». Дело в том, что цифири, которые мы видим в процессе копирования (например, в Nautilus) или при тесте (в том же Crystal Disk, да и hdparam, что более праильно для Linux) это то, что мы получаем со стороны ОС. Читать данные о времени копирования в максимально чистом виде мы можем только в случае, если у нас есть доступ к контроллеру HDD, а его напрямую нет. Так что, цифири, которые выдаёт для случая «нормальных» дисков hdparm -tT /dev/sda (например), это некоторые относительные цифры, с учётом буферизаций всех видов, планировщика ввода-вывода (иногда можно умудриться подобрать крайне фиговый для конкретного случая) и ещё ряда параметров — тот же block size может сыграть здесь весьма заметную роль. Можете, если интересно, то понаблюдать за изменением параметров под нагрузкой на диск.

Если кому хочется подробностей, то я проделывал аналогичные опубликованным здесь -> http://habrahabr.ru/post/154235/ работы для различных RAID-массивов, там не всё так просто и параметров, заметно влияющих на производительность дисковых подсистем довольно много. Для рассматриваемого случая по-меньше, но тоже есть в чём покопаться.

Кстати, я вообще не вкурил (выше уже писал) почему используется Crystal Disk с ntfs. Проще было бы как-то так:

# cd /mnt/drive

# sync 

# time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile

И посмотреть результаты для разных bs (block size) и для разных ФС. Особенно интересно было бы (уж поверьте на слово ;)) посмотреть на результаты при разных степенях заполнения дисков. Но это целое исследование можно написать. Я такое уже делал, больше не хочу, да и времени нет. А, если кому будет интересно, то займитесь.

P.S. Скорость сброса на блины важна безусловно, но она в данном случае несколько... вторична что ли. Реальную мы ни как увидеть не можем, а гадать — ну его на фиг.

Так ведь в том и прикол, что в любых более-менее нормальных тестах скорости накопителей читают/пишут такое количество данных, что никаких промежуточных буферов в этих самых накопителях не хватит (в первом из указанных devl547-ом тестов использовали файл >8ГБ). В результате, особенно если дополнительно пользоваться некоторыми функциями ОС наподобие fsync(), получается так, что выполняющую чтение/запись программу приходится периодически приостанавливать и итог измерений получается намного ближе к реальным возможностям накопителя, а не [теоретической] пропускной способности интерфейса.

из-за медленной/дорогой сети

Как там тебе живётся то, в начале 2000-ых?

Мудилко, за МКАД вылези. Можешь не найти даже медленной/дорогой.

... только не всегда:

если дополнительно пользоваться некоторыми функциями ОС наподобие fsync()

Пользуются вызовами синхронизации. Для big data (сужу по своему опыту), тот же fsync()/sync() вызывает ненужные тормоза. Как правило, синхронизация буферов при записи данных это забота ОС. В особенности если это какой-нибудь RAID с дисками где-нибудь на 170Т. Вы просто льёте туда данные, а что-то аналогичное fsync() или sync() на уровне ОС, выполняется по мере необходимости (возможности) самостоятельно. Ну и однозначно что при закрытии файла произойдёт сброс буферов и синхронизация. При использовании libaio всё ещё веселее. Там приложение даже сказать не всегда может когда данные (или порция данных) до конца считаны/записаны и когда конкретно надо делать синхонизацию. Оно там просходит, но как-то само.

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

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

Не стоит слепо верить маркетолухам, вешающим хомячкамлюдям на уши лапшу про запись на HDD со скоростью 5Гбит/с. Работа у них такая — нести всякую херню ради увеличения продаж.

Хорошо конечно, но cd/dvd ещё хоть кто-то пользуется?

На dvd можно записать несколько разных live систем, иногда удобно.

http://multicd.tuxfamily.org

RIP ... древняя технология ... только для старперов...

Взял открыл вики по свежайшей PS4 - а там: 6-скоростной Blu-Ray и 8-скоростной DVD привод. Такие дела

cd/dvd ещё хоть кто-то пользуется?

Представь себе, не все живут в Москве.

Я живу на Крайнем Севере. И?

Представь себе, не все работают в Газпроме или на других олигархов.

Я вообще дежурный администратор на рынке, так что не надо. Сто мегабит за тыщу можно подключить везде, я думаю. Ну только в Салехарде, да у чукчей/ненцев низя.

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

я срал на посанов — CDROM'ы объективно == говно.

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

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

Зачем вообще ставить ОС с флешки, если есть устройства наподобие http://habrahabr.ru/post/116799/

зачем нужны говноустройства, если Slackware Linux ставится откуда угодно?

Скорость сброса на блины важна безусловно, но она в данном случае несколько... вторична что ли. Реальную мы ни как увидеть не можем, а гадать — ну его на фиг.

umount что, не сбрасывает?

Нет, с хорошей полиграфией даже рядом не валялся, скорее можно сравнивать с дешевыми газетами.

Про «современность» я уточнил потому, что ранние е-инки были очень медленными, сейчас это уже не столь актуально.

Сбрасывает...

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

Ну и да, 5 Gbit/s это просто придумка маркетологов от делать нечего. Да и то, что там сила тока малость поболе чем на USB 2.0, мне это тоже кажется...

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

потому и тормозит, что мы видим _реальную_ скорость копирования. Невижу ничего странного.

Ну и да, 5 Gbit/s это просто придумка маркетологов от делать нечего.

если втыкать старенький IDE-HDD через переходник — да, без разницы. Если воткнуть новый SSD, то разница есть, и ощутимая. Причём без тестов, на любой задаче, которая требует много рандомного чтения.

Да и то, что там сила тока малость поболе чем на USB 2.0, мне это тоже кажется...

этого не знаю, не мерил.

Тормозит...

... да вовсе не потому, что:

мы видим _реальную_ скорость копирования

Мы _реальную_ скорость копирования можем увидеть только встав на сам по себе контроллер винчестера. Всё остальное — не реальная скорость копирования, а предположения системы или софта о ней.

если втыкать старенький IDE-HDD через переходник — да, без разницы.

А о стареньком ли IDE-HDD через переходник мы тут?

этого не знаю, не мерил.

См. спеку на USB 3.

Мы _реальную_ скорость копирования можем увидеть только встав на сам по себе контроллер винчестера. Всё остальное — не реальная скорость копирования, а предположения системы или софта о ней.

не совсем. Когда устройство размонтируется(синкнется), тогда, и только тогда можно считать запись гарантированно завершённой. Если ты выдерешь флешку до этого, то файлы пропадут, можешь проверить(с HDD не рекомендую). Т.ч. если разница и есть, то она не сильно велика. Ну и потом купи флешку с лампочкой, и увидишь, что запись продолжается и после «записи», но прекращается после размонтирования. Или думаешь лампочка тоже врёт, и телепатирует состояние ОС, а не внутреннего контроллера?

См. спеку на USB 3.

старые спеки содержали баг, из-за которого приходилось втыкать устройства двойным проводом(т.к. тока не хватало, хотя честные китайцы выдерживали стандарт). В USB3 баг пофиксили, и китайцы уже не имеют право делать такие говнопорты(или вешать на них спек USB3).

В том-то и беда...

... что обсуждаемые нами процессы не столь очевидны. О чём я и писал выше, собственно.

Когда устройство размонтируется(синкнется), тогда, и только тогда можно считать запись гарантированно завершённой.

Да. Но весь вопрос в том, когда именно произойдёт окончательная синхронизация буферов в памяти компьютера и самого устройства и «железного диска». Окончательная синхронизация произойдёт после закрытия файла. Промежуточные синхронизации — я бы не стал в программе копирования делать сам fsync()/sync(), т.к. «система» сама с этим разберётся по-лучше меня. Ей виднее когда синкаться, возможно что и на промежуточных этапа копирования.

Как я и писал выше, компьютер занят не одним копированием. Вполне вероятно, что для завершения копирования, системе надо будет переключить контекст в процесс копирования (например), а перед этим — сделать что-то в другом процессе (процессах).

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

Ну и потом купи флешку с лампочкой, и увидишь, что запись продолжается и после «записи», но прекращается после размонтирования. Или думаешь лампочка тоже врёт, и телепатирует состояние ОС, а не внутреннего контроллера?

Светодиод не врёт. Он просто моргает при обращениях к контроллеру флешки. И прекращает моргать при отсутствии таковых. Но в том-то и трюк что сразу отмонтировать флешку не получится. Пройдёт несколько секунд (когда больше, когда меньше) пока это можно будет сделать и система разрешит отмонтировать и не выкинет своё «device busy». Это как-раз и связано с тем, что система даже при завершении копирования (например, в том же Nautilus) ещё чем-то там занята, что возможно и не относится непосредственно к процессу копирования, но какую-то роль играет.

И, кстати, да. Если мы именно о флешке, а не о тех USB-HDD, что выше, то такая задержка не совсем была бы понятна — на флешке нет дисков и головок, там перепозиционировать и отключать нечего. Казалось бы, закинул данные, закрыл файл (в этом случае синхронизация делается принудительно), скорость должна быть высокой даже для USB 2, задержек быть не должно. А задержка есть. На мой взгляд это и говорит о том, что мы имеем дело не с реальной «скоростью сброса данных на блины», а с какой-то, которую нам сообщает сама система. По её мнению.

В USB3 баг пофиксили, и китайцы уже не имеют право делать такие говнопорты(или вешать на них спек USB3).

Ну, тот диск, который я использую (см. выше), там USB 3 по-честному сделан. Кабель с одной стороны USB 3 type A (для компьютера), с другой — USB 3 Micro (или Micro-B, не смотрел точно). На ноуте/компах USB 3, как правило, тоже честный.

Да. Но весь вопрос в том, когда именно произойдёт окончательная синхронизация буферов в памяти компьютера и самого устройства и «железного диска». Окончательная синхронизация произойдёт после закрытия файла.

Окончательная синхронизация произойдёт после закрытия файла.

нет

я бы не стал в программе копирования делать сам fsync()/sync(), т.к. «система» сама с этим разберётся по-лучше меня. Ей виднее когда синкаться, возможно что и на промежуточных этапа копирования.

конечно сама. Sync просто гарантирует то, что она ВСЁ сбросила. Т.е. делать его безопасно. Но после каждого файла не нужно, т.к. получится медленнее. IRL в Over9000 раз медленнее. Однако в конце — можно. Естественно лучше сделать umount, если устройство надо отсоединить.

Как я и писал выше, компьютер занят не одним копированием. Вполне вероятно, что для завершения копирования, системе надо будет переключить контекст в процесс копирования (например), а перед этим — сделать что-то в другом процессе (процессах).

это к делу не относится. Процессор не копирует, он лишь ставит задачу.

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

я тоже повторю: всё мы знаем, это всё записано в мануалах. Копируем мы конечно не напрямую, а через файловый кеш.

Светодиод не врёт. Он просто моргает при обращениях к контроллеру флешки. И прекращает моргать при отсутствии таковых. Но в том-то и трюк что сразу отмонтировать флешку не получится. Пройдёт несколько секунд (когда больше, когда меньше) пока это можно будет сделать и система разрешит отмонтировать и не выкинет своё «device busy». Это как-раз и связано с тем, что система даже при завершении копирования (например, в том же Nautilus) ещё чем-то там занята, что возможно и не относится непосредственно к процессу копирования, но какую-то роль играет.

она именно КОПИРУЕТ. Просто на флешку медленно копируется, потому и запись откладывается.

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

нет.

а с какой-то, которую нам сообщает сама система. По её мнению.

система ничего не сообщает. Команда cp завершается после того, как файл прочитался в файловый кеш, но ДО того, как он отправится в флешку.

Ну, тот диск, который я использую (см. выше), там USB 3 по-честному сделан. Кабель с одной стороны USB 3 type A (для компьютера), с другой — USB 3 Micro (или Micro-B, не смотрел точно). На ноуте/компах USB 3, как правило, тоже честный.

потому что USB3.

В смысле...

... «нет»?

> Окончательная синхронизация произойдёт после закрытия файла.

нет

Почему «нет»? Откуда тут «нет», если как минимум fclose():

Note that fclose() only flushes the user-space buffers provided by the C library.

Да, приложение работает с буферами user-space, отдавая на откуп ОС реальный сброс данных «на блины», хотя есть способ заставить ОС сбросить данные, но он не всегда используется, достаточно того, что ОС сама знает когда ей лучше сбросить данные из системных буферов:

To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).

Из -> http://linux.die.net/man/3/fclose Для наглядности — просто выдерните флешку, несмотря на «device busy» при попытке отмонтирования.

Ещё можно припомнить fdatasync(), но там с fsync() разница только в том, что метаданные файла не обновляются (время доступа, например), меняется только содержимое. Слегка быстрее, но и то не особо нужно.

А с close() ещё смотреть надо — как открыт файл, в частности выставлен ли флаг O_SYNC при открытии через open(). Так что, тут тоже можно не париться особо — буферы либо принудительно будут сбрасываться при каждой записи в файл (если файл открыт с флагом), либо ОС сама решит когда их сбросить (после закрытия файла). Хотя, выше сказанное (про системные буферы и их сброс) справедливо и здесь, кстати, я например, при копировании данных в своём софте, O_SYNC не ставлю, полагаясь на наличие стабильного питания на устройствах. Мне важнее скорость.

Так что, то что при отмонтировании мы можем получить «device busy», с этим и связано. Пока система буферы до конца не сбросит, она не даст отмонтировать диск. И это слабо связано со «скоростью сброса данных на блины» (данные там уже записаны), это связано с тем, что ОС лучше знает когда она освободила user-space & kernel-space buffers.

Однако в конце — можно.

Зачем? Система и сама всё знает. А вот тормоза (и здесь я соглашусь) довольно серьёзные. Но в чём проблема, я повторю — при закрытии файла система сама сбросит данные просто для того, чтобы быть уверенными в том, что содержимое файлов (откуда и куда копируем) одинаково и перейти к следующему файлу, если его надо копировать, использовав те же буферы в памяти. Иначе нет логики. Буферы есть, заняты, а чем — не ясно. Зачем они системе? Память да, дёшева, но она не резиновая и безнаказанно хранить явно ненужные данные (файл-то закрываем!) она не будет.

это к делу не относится. Процессор не копирует, он лишь ставит задачу.

Относится. У нас не real-time system, где есть чёткие временные интервалы в течении которых запрос на то же копирование либо обработан, либо возвращена информация о невозможности (постоянной или временной) провести операцию. У нас система с мягким real-time, так что здесь не посчитаешь более-менее точно скорость выполнения задачи. Только приблизительно. Таким образом, если мы относительно точно считаем, то про какое там «реальное время сброса данных на блины» идёт речь? Мы его посмотреть в реале не можем, можем только доверять документации на свой винчестер. Таким образом, на это время можно забить как на класс и забыть о нём. Про что я и говорю, собственно.

она именно КОПИРУЕТ. Просто на флешку медленно копируется, потому и запись откладывается.

Нет. Не поэтому. При тех же 5Gbit/s я вижу различия в скорости при различной нагрузке на систему. Ещё раз рекомендую (если интересно) провести тесты -> Пополнение в проекте GNU — GNU ccd2cue (комментарий)

я тоже повторю: всё мы знаем, это всё записано в мануалах. Копируем мы конечно не напрямую, а через файловый кеш.

Уже лучше. Дальше мы должны вспомнить о том, что есть user-space и kernel-space... Упс! Я уже писал выше... ;)

Почему «нет»?

ну лампочка-то мигает? Сам же видишь...

Note that fclose() only flushes the user-space buffers provided by the C library.

какое отношение имеют user-space buffers к нашему спору?

я тоже повторю: всё мы знаем, это всё записано в мануалах. Копируем мы конечно не напрямую, а через файловый кеш.

Уже лучше. Дальше мы должны вспомнить о том, что есть user-space и kernel-space... Упс! Я уже писал выше... ;)

угу

Дык...

... как какое?

какое отношение имеют user-space buffers к нашему спору?

Самое непосредственное. Копирование файла может производиться посредством ф-ий буферизированного ввода-вывода (fread/fwrite), небуфиризированного (read/write), асинхронного (aio), ну и sendfile (до кучи). Может использоваться как синхронизированный, так и несинхронизированный режимы (выставлен или нет O_SYNC). Вот буферизированный ввод-вывод и использует двойную буферизацию — user & kernel-space. В read/write как правило, только kernel-space.

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

ну лампочка-то мигает? Сам же видишь...

Светодиод моргает при любом обращении к USB-flash. Сейчас вот копирования нет, а тоже помаргивает равномерно. Это не очень хороший показатель, к сожалению.

Самое непосредственное. Копирование файла может производиться посредством ф-ий буферизированного ввода-вывода (fread/fwrite), небуфиризированного (read/write)

оно «небуферезированное» в том, и только в том смысле, что не используется буфер в user-space. Файловый кеш всё равно используется. AFAIK уже 30 лет никто не пишет в io напрямую, а только через буфер в памяти. Причём этот буфер в Linux занимает всю «свободную» память. А fwrite(3) пишет через два буфера(не считая буфера в самом девайсе). Первый буфер лежит в userspace, в структуре FILE, и доступен клиентскому коду (например по ungetc(3), см. соотв ман). Второй буфер лежит в файловом кеше, и недоступен. Считается, что если ушло туда, то «запись окончена».

Светодиод моргает при любом обращении к USB-flash.

нет, не при любом. А только при записи/чтении, т.к. флешка больше ничего не умеет.

Сейчас вот копирования нет, а тоже помаргивает равномерно. Это не очень хороший показатель, к сожалению.

man 1 iostat

И да и нет...

... да:

оно «небуферезированное» в том, и только в том смысле, что не используется буфер в user-space. Файловый кеш всё равно используется.

Нет:

Причём этот буфер в Linux занимает всю «свободную» память.

Это регулируется через /proc/sys/vm/dirty_ratio по дефолту у меня там 20% от RAM, делать что-то типа echo 100 > /proc/sys/vm/dirty_ratio и отдавать 100% на кеши записи, превращая свой хост в «машину только для копирования», я бы не рекомендовал. Как правило, на хосте есть ещё и другие задачи, кроме копирования.

Ну и, справедливости ради, я бы ещё посмотрел на /proc/sys/vm/vfs_cache_pressure (по дефолту 100). Его можно увеличить и заставить ядро достаточно редко писать на диск, лишь бы памяти хватило:

Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a «fair» rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes.

Считается, что если ушло туда, то «запись окончена».

Считается на уровне user-space приблуды, я замечу. Что там реально произойдёт с kernel-space буфером, приблуде неизвестно. Однако, сама по себе ОС не даст отмонтировать девайс, пока не сбросит до конца буферы.

Ну, это несколько не так:

нет, не при любом.

Я в курсе про iostat, скажу сразу и копирования там в момент наблюдения не было. Светодиод моргает всякий раз, когда есть обращение к флешке. Т.е., есть +5V на шине USB, включились. Нет — выключились. «Интеллекта» там ноль. По-моему, автомаунтер это балуется. Хотя, я и не проверял, скажу честно.

=======

Т.е., мы можем констатировать что буферы user-space & kernel-space есть, роль свою они играют. И куда большую чем «сброс данных на блины», которую оценить правильно довольно сложно. Отлично.

Ну и теперь мы можем перейти к следующей части нашей небольшой уличной магии. Мы можем поговорить о подборе планировщика ввода-вывода. И влиянии его выбора на скорость записи. Я бы предложил рассматривать не тот планировщик, который есть в системе и который применяется для ввода-вывода на диски если не оговорено иное, а посмотреть на cat /sys/block/sdc(пусть будет usb-флеш на sdc)/queue/scheduler. Сильно удивлюсь, если там будет указан не применяемый на Вашей машине планировщик.

Но беда в том, что задача планировщика ввода-вывода состоит в группировке данных таким образом, чтобы оптимизировать запись за счёт того, что головки диска будут меньше тратить времени на поиск (перепозиционирование). В случае с USB-flash (как и с SSD) время на перепозиционирование равно нулю. Так что, можно спокойно сделать echo noop > /sys/block/sdc/queue/scheduler. Или echo deadline > /sys/block/sdc/queue/scheduler

Трогать параметры (для deadline, для noop их нет) /sys/block/sdc/queue/iosched/writes_starved, /sys/block/sdc/queue/iosched/read_expire, /sys/block/sdc/queue/iosched/write_expire, позволяющие крайне тонко настраивать работу планировщика deadline мы не будем, впрочем, можем и потрогать, если кому интересно будет. Проблема в том, что deadline заточен в основном под чтение, так что при записи его подкручивать надобно.

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