Вот еще вопрос всплыл.
Если флэшка отформатирована под exFAT с размером кластера 32 МБ (у меня такая есть, исключительно для больших файлов), на нее что, в принципе нельзя писать маленькими блоками? Она будет каждый кластер переписывать по несколько раз?
И с HDD, и с SSD аналогичный вопрос.

А если файл был открыт для записи с флагом FILE_FLAG_NO_BUFFERING?

kealon(Ruslan)Flying-home,

а можно ещё и папку заместо файла открыть, если "постараться"
зачем банальности спрашивать
Я-то не знаю, что там в контроллере флэшки. Может, защита от дурака есть?

Еще интересный момент:
Windows Server 2003, зеркало на контроллере LSI
Файл открывался для чтения с флагом FILE_FLAG_NO_BUFFERING, размер блока - 64 МБ
При попытке сделать первое чтение выскочила ошибка 1450 - недостаточно системных ресурсов для завершения операции.

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

Flying-homekealon(Ruslan)Flying-home,

а можно ещё и папку заместо файла открыть, если "постараться"
зачем банальности спрашивать
Я-то не знаю, что там в контроллере флэшки. Может, защита от дурака есть?
Кстати, если предположить, что при записи блоков в 16 МБ на флэшку с кластером в 32 МБ кластера будут переписываться по два раза, то мы должны будем получить падение скорости записи примерно в 2 раза. На практике я этого не вижу.

Flying-homeЕще интересный момент:
Windows Server 2003, зеркало на контроллере LSI
Файл открывался для чтения с флагом FILE_FLAG_NO_BUFFERING, размер блока - 64 МБ
При попытке сделать первое чтение выскочила ошибка 1450 - недостаточно системных ресурсов для завершения операции.

Почитал про ошибку. Похоже, это связано не с сервером и не с контроллером, а с фрагментацией файла.
Нет. С фрагментацией это не связано, или связано очень слабо.
И это проблема, которую надо решать.
Ситуация следующая:
С файлами, открытыми с флагом FILE_FLAG_NO_BUFFERING вообще невозможны операции блоками больше 16 МБ. Ни чтение, ни запись.

Еще один интересный момент:

Внезапно обнаружил, что при прочих равных я проигрываю Тотал Коммандеру при копировании "на тот же диск" примерно 4% по скорости.
Искал причину два дня. Когда уже почти отчаялся, вспомнил, что ТС не устанавливает размер файла сразу, а копирует как есть, размер файла растет по мере записи в него. А у меня эта фича стояла по умолчанию. Убрал ее и сразу вышел в ноль.

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

Еще одна странность, присущая, как мне кажется, Windows 7.

Если выделять память под блоки с флагом NO_CACHE (В MSDN сказано, конечно, что этот флаг не надо без нужды использовать, но другого способа предотвратить сбрасывание страниц в своп я пока не вижу), скорость копирования падает с 58 МБ/c до 32 МБ/с. Почти в два раза. Это при безбуферном чтении и безбуферной записи.

Похоже, память выделяется как-то не так, как надо функциям записи и чтения, работающими с FILE_FLAG_NO_BUFFERING.

maytonНесколько наблюдений.

1.

Лет десяток назад когда я активно качал торрентами я заметил что файловая система достаточно интеллектуальна
в части аллокации дискового файла. Грубо говоря созданный пустой файл с нулями при перемотке seek хоть на терабайт вперед
не аллоцирует места (sparse file). После этого я стал пристально изучать возможности NTFS, XFS, ZFS и потерял веру в человечество
и файловый API. Сюда-же идут и буфера записи. Вобщем если кто-то хочет бенчмаркать диск, флешки, SD карты то нужно сказать всем файловым
системам - "идите на йух". Нужно подключать сырое устройство без всякой разметки. И мерять его самым низкоуровневым
API которое только доступно. В этом случае мы замеряем реальную скорость записи информации.

2.

Одна из моих флешек 64G определенно буферизирует трафик. Причем этот эффект заметен как на Windows так и на Linux.
СНачала копирования - высокая скорость. Потом - падает чуть ли не до нуля. А потом поднимается на 10% и так и копирует
до конца. Бенчмаркал через $ dd (disk duplicate)

Другая старенькая на 8G. Копирует всегда медленно но стабильно.

3.

Флешки - микрокомьютеры с контроллерами внутри. Не просто плоская память. И мы не знаем как они работают
и какие делают оптимизации для сбережения ресурса памяти по записи. Отсюда вобщем-то непрогнозируемая
скорость записи. Можем в среднем прикинуть. Но не дать гарантий.
зависит от разных внутренних состояний.

Флешки
Да. Интересно было бы ту твою большую флэшку потестить насчет FILE_FLAG_NO_BUFFERING. У меня сейчас две 32-гиговые, не знаю, насколько умные, при записи на них стабильно выигрывается 5-10% безбуферной записью. И скорость записи не плавает.

Еще я заметил по копированию из сети (запись на локальный диск безбуферная, чтение - с буферизацией Виндовс): Первые 8 гигов копируются с быстро, почти 70 МБ/с, потом скорость падает до 30 МБ/с. Вот как такое может быть? Файл-сервер - 2003 сервак, клиент - семерка. 8 гигов, Карл! На 8 гигах кто-то из них решает, что хватит буферизировать?

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

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

tunknown,

Спасибо. Чем дальше в лес, тем больше дров.

2all

Хотите посмеяться? Я на новогодних праздниках написал простенькую прогу, которой в лучшем случае будут пользоваться пара тысяч старых пердунов из Канады и Новой Зеландии. Так вот, когда я ее написал, и решил приступить к написанию справки, я подумал: "Надо бы сделать и свое копирование файликов. Граничные условия узкие, должно получиться хорошее ускорение по сравнению с виндовыми операциями. Пусть старики порадуются."

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

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

maytonСитуация в динамике - такая-же как и в 64Гб флешке. Первые несколько секунд - скорость 70 Мб в сек. И потом
падает до 5Мб и до конца идет так.
А можно посчитать, сколько байт уходит на флэшку за эти "несколько секунд"? А в доке по флэшке есть информация о буфере? А может это буфер оси? Я стараюсь где можно отказываться от чужой буферизации.

Несколько наблюдений по чтению из сети.

Получатель - новый диск на 64-битной семерке (локальный), скорость записи значительно превышает скорость чтения.
Сетка - гигабит через убиквити едж свитч.
Источник - тот же самый 2003 сервак с зеркалом на LSI контроллере.
копируется группа из 8 файлов от 24 МБ до 3 ГБ. Общий размер - 8 ГБ.

Изначально, при курении MSDN я пришел к следующему выводу: флаги (используемые при открытии файла на чтение) FILE_FLAG_NO_BUFFERING и FILE_FLAG_SEQUENTIAL_SCAN взаимно исключающие. То есть, даже если их указать вместе, работать будет только один из них. Вывод логичный, поскольку один флаг полностью отменяет буферизацию, а второй - управляет ею. Увидел в интернетах, что кто-то использует их вместе, решил поэкспериментировать. Мало ли, если винда по каким-то причинам не может применить один флаг, она попытается применить другой? Нет.

FILE_FLAG_SEQUENTIAL_SCAN - скорость 100 МБ в сек, размер блока большого значения не имеет. Лучшие значения - 8 и 16 МБ.

FILE_FLAG_NO_BUFFERING - скорость от 50 до 60 МБ в сек.

FILE_FLAG_NO_BUFFERING и FILE_FLAG_SEQUENTIAL_SCAN - скорость от 50 до 60 МБ в сек.

FILE_ATTRIBUTE_NORMAL без всякой оптимизации - 100 МБ в сек. Проигрывает FILE_FLAG_SEQUENTIAL_SCAN буквально на два процента и то не факт. Статистики мало.

Отсюда выводы:

1. FILE_FLAG_NO_BUFFERING по локалке может навредить почти в два раза.

2. Не надо надеяться на винду и подсовывать ей все возможные варианты оптимизации. Надо самому убедиться, что ты читаешь из сети и применять FILE_FLAG_SEQUENTIAL_SCAN, он по крайней мере не помешает.

Еще одно замечание. Если в группу файлов включить файл 25 ГБ, скорость падает до 30-40 МБ в сек. Никакие флаги не помогают. Кто тут больше виноват, Microsoft или LSI, пока не ясно.

А при чтении с 2008 сервера все лучше.
FILE_FLAG_NO_BUFFERING дает прирост в 4%.
проблем с файлами больше 4 ГБ не наблюдается.

Было бы неплохо узнать, какие флаги были реально применены виндой при создании файла.
Типа, говоришь ей: FILE_FLAG_NO_BUFFERING, а она тебе в ответ: "Нифига, попробуй другой вариант".

maytonНе забывай про чистое время копирования + отмонтирование флешки.
Да я помню. Это все также связано с буферизацией. Даже провел опыт, когда под рукой был ноут с десяткой. Скопировал файлы своей прогой, будучи уверен, что буферизация отключена. Потом скопировал файлы виндовым проводником и выдернул флэшку сразу после завершения операции. Все файлы на флэшке оказались целыми. Значит, десятка при копировании на флэшку буферизацию не использует. Скорее всего.
Да, и по скорости я ничего не выиграл.

Когда файлов много, к чистому времени копирования еще прибавляется время, затраченное на расчет общего размера с "кластерными хвостами". И еще надо тратить время на расчет так называемых "секторных хвостов" для безбуферных операций.

А кто-нибудь видел своими глазами скорость копирования по сети 100 мегабайт в секунду?
Я вчера увидел и немного офигел. Правда, до этого я и не задавался этими вопросами.
Это 0.8 гигабита в секунду, близко к пропускной способности гигабитной сетки. А может, и на пределе. Сколько там служебных байт надо самбе для передачи файла?
ЗЫ размер блока - 32 МБ.