Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Windows Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
 Re: Оптимальный размер блока при записи файла на флэшку  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47539
Flying-home
У меня на 40 МБ перестала расти. Может, у меня какой-то не общий случай, может с размерами файлов какая-то коллизия произошла, надо будет еще посмотреть.

С алгоритмом у тебя коллизия скорее всего произошла. На 40 мегабайтах разница по времени между логической записью в кэш и физическим обменом с флэшкой стала достаточной для того, чтобы следующий блок успел прочитаться с винта.
11 янв 19, 15:05    [21782916]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный размер блока при записи файла на флэшку  [new]
Flying-home
Member

Откуда: nas.vrostove.net
Сообщений: 14660
Dimitry Sibiryakov
Flying-home
У меня на 40 МБ перестала расти. Может, у меня какой-то не общий случай, может с размерами файлов какая-то коллизия произошла, надо будет еще посмотреть.

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

Я еще до флэшки не дошел, пока только с сата винчестерами балуюсь. И до FILE_FLAG_NO_BUFFERING тоже еще не добрался. Рихтера уже начал читать. Очень доходчиво пишет, респект ему.

Чтобы было с чем сравнивать, я сделал эталон:
Использую виндовый буфер, применяю FILE_FLAG_SEQUENTIAL_SCAN, принудительно сбрасываю буфера по очереди после того, как вся группа файлов формально скопируется. Недостаток этого метода в том, что винда сбрасывает буфера когда захочет и делает это параллельно, это заметно снижает скорость записи на диск. Тут я ничего поделать не могу. Алгоритм копирования тут особого значения не имеет, поскольку запись идет всегда в память и начинает задерживаться только когда буфер переполняется.

С этим эталоном я сравниваю свой алгоритм:
Чтение с использованием буфера, запись - "через буфер" (FILE_FLAG_WRITE_THROUGH) алгоритм для одного жесткого диска - один поток, один блок, для разных дисков - два потока, два блока. Играю размерами блоков, вижу, что чем больше, тем лучше. 64 МБ - самое то. У эталона выигрываю 8% на одном диске и 15% на разных дисках.
Это я сделал, потому что думал, что винда правильно и качественно сбрасывает буфера. Кто ей мешает, например, использовать для этого тот же алгоритм, что и в FILE_FLAG_NO_BUFFERING, и делать все последовательно? Но нет.

Пока еще у меня все сырое, но буду держать вас в курсе.
:)
20 янв 19, 14:22    [21789636]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный размер блока при записи файла на флэшку  [new]
Flying-home
Member

Откуда: nas.vrostove.net
Сообщений: 14660
Набросал тут мысли по поводу:

Что зависит от программиста:

Алгоритм копирования:

  • один поток, один блок (полезно для копирования на тот же диск)
  • два потока, несколько блоков (для копирования на другой диск)

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

    Способы открытия файлов:

  • для чтения: с буфером, без буфера
  • для записи: с буфером, "через буфер", без буфера

    Для вариантов с буфером полезен флаг FILE_FLAG_SEQUENTIAL_SCAN, при использовании буфера можно принудительно сбрасывать буфера на диск, можно не сбрасывать.


    Специфика окружения, от которой может зависеть выбор алгоритма и способа открытия файлов:

    Источник и целевой файлы могут находиться

  • на одном физическом носителе
  • на разных носителях


    Источник и целевой файлы могут находиться

  • на жестком диске
  • на твердотельном накопителе
  • на RAID массиве
  • на компакт, DVD диске
  • на съемном флэш-накопителе (для которого винда либо включила буферизацию, либо нет)
  • в локальной сети
  • на подключенном к компьютеру смартфоне (носители которого либо распознаются системой как диски, либо нет)

    Носители могут иметь различные

  • файловые системы
  • размеры сектора
  • размеры кластера

    Про сектора наверное, можно забыть и оперировать только размерами кластера (подгонять под них размеры блоков)

    Продвинутость пользователя
    Одного пользователя можно ненавязчиво спросить, расположены ли C:\ и D:\ на одном HDD, другого - нельзя.

    Ограничения операционной системы
    Еще не пробовал, но кажется, програмная попытка получить ответ на предыдущий вопрос под ограниченным в правах пользователем с включенным УАКом может потерпеть крах и / или испугать пользователя.
    Тоже самое с попыткой выяснить размер кластера и количество свободного места на диске (предполагаю)
  • 20 янв 19, 14:32    [21789639]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Забыл сказать, что при копировании двумя потоками у меня упреждающее чтение работает и между файлами.
    То есть, когда записывающий поток заканчивает с одним файлом, читающий уже начинает со следующим.
    20 янв 19, 14:46    [21789648]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    И еще я пока не вижу преимуществ overlapped I/O. Если у меня и так все длительные операции в отдельных потоках и у пользователя ГУИ не тормозит, зачем он может быть нужен?
    20 янв 19, 14:54    [21789652]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Leonid Kudryavtsev
    Member

    Откуда:
    Сообщений: 7659
    Flying-home
    И еще я пока не вижу преимуществ overlapped I/O. Если у меня и так все длительные операции в отдельных потоках и у пользователя ГУИ не тормозит, зачем он может быть нужен?

    AFAIK & IMHO overlapped IO позволяет уменьшить кол-во потоков. Если у тебя 2-3 потока - то все нормально, а если 200-300 потоков, то тогда уже на переключении потоков будет overhead.

    AFAIK & IMHO для обычных дисков, до 1 Mb рост скорости от увеличения буфера вполне чувствуется без всяких замеров, до 8 Mb уже не столь существеннено. Больше (для обычных дисков) может потребоваться только если чтение и запись идет одновременно с одного и того же диска (уменьшаем перемешение головок), но тут приделов нету. И до 512 Mb можно выгоду почувствовать

    На SSD-флешке головок нет, мне кажется 64 Mb тут сильно лишнее.
    20 янв 19, 16:54    [21789723]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Leonid Kudryavtsev
    мне кажется 64 Mb тут сильно лишнее.

    А чем плохо? Только тем, что перед копированием надо узнать, сколько некэшируемой оперативки может выделить система приложению? Может, действительно, три блока по 64 МБ будет тяжело?


    Leonid Kudryavtsev
    Если у тебя 2-3 потока - то все нормально, а если 200-300 потоков, то тогда уже на переключении потоков будет overhead.

    У меня всего 2 потока. Зачем больше? Для упреждающего чтения достаточно количество блоков увеличить.
    20 янв 19, 18:36    [21789776]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    А, кстати.
    Рихтер пишет, что для выделения блоков использует VirtualAlloc, потому что так данные выравниваются в памяти правильно. А что, обычный GetMem не будет выравнивать?
    20 янв 19, 18:39    [21789778]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Flying-home
    на компакт, DVD диске

    Интерсно, как лучше с них читать? Думаю, с обычной буферизацией.

    Flying-home
    на подключенном к компьютеру смартфоне (носители которого либо распознаются системой как диски, либо нет)

    А кто-нибудь сталкивался с подобной задачей? Последние Андроиды как правило, не дают системе нормально примонтировать свои носители. Но в проводнике они видны (не как диски) и копировать файлы туда-сюда все-таки можно.
    20 янв 19, 18:46    [21789780]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Что самое смешное, что большинству пользователей вся эта оптимизация нафиг не нужна.

    Я, например, много лет назад заглянул в настройки Тоталкоммандера, увидел там разные размеры блока для одного и двух дисков, сказал "Ого", оставил все как есть и больше эти настройки не открывал. А теперь я копирую быстрее него. Как мне кажется, у Джислера во всех случаях однопоточное копирование. По крайней мере в шестой версии.
    20 янв 19, 18:58    [21789785]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 40744
    Эту тему можно переносить в Windows.
    20 янв 19, 21:35    [21789837]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Dimitry Sibiryakov
    Member

    Откуда:
    Сообщений: 47539
    Flying-home
    И еще я пока не вижу преимуществ overlapped I/O. Если у меня и так все длительные операции в отдельных потоках и у пользователя ГУИ не тормозит, зачем он может быть нужен?

    Overlapped I/O нужна для того чтобы НЕ использовать потоки. Это древняя технология, появившаяся ещё до многопоточности.
    21 янв 19, 15:13    [21790330]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Dima T
    Member

    Откуда:
    Сообщений: 13672
    Flying-home, почитай про "Порт завершения ввода/вывода" IO Completion Port
    21 янв 19, 15:32    [21790353]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    kealon(Ruslan)
    Member

    Откуда: Нижневартовск
    Сообщений: 4620
    Dimitry Sibiryakov
    Flying-home
    И еще я пока не вижу преимуществ overlapped I/O. Если у меня и так все длительные операции в отдельных потоках и у пользователя ГУИ не тормозит, зачем он может быть нужен?

    Overlapped I/O нужна для того чтобы НЕ использовать потоки. Это древняя технология, появившаяся ещё до многопоточности.
    да вроде одинаково они появились, иначе было просто нельзя мультимедиа и прочее фоновое поддерживать
    21 янв 19, 16:07    [21790386]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    mayton
    Эту тему можно переносить в Windows.

    Windows - подраздел "Администрирования".
    23 янв 19, 14:23    [21792161]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Разные тонкости:

    При чтении файла открытого с флагом FILE_FLAG_NO_BUFFERING параметр nNumberOfBytesToRead всегда надо указывать кратным размеру сектора. Даже в конце файла, когда известно, что прочитано будет меньше.


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

    Модератор: Тема перенесена из форума "Программирование".
    23 янв 19, 14:26    [21792171]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Еще одна проблемка всплыла.
    Как узнать размер кластера на дисках:
    1. каталоги которых подключены через хардлинк.
    2. которые монтированы как NTFS папки других дисков.

    Функции GetDiskFreeSpace надо указывать корень диска да и сомнительная она, функции GetDiskFreeSpaceEx можно указывать каталог, но она не не показывает размер кластера.

    Открывать диск функцией CreateFile не хочется, надо повышать права.
    30 янв 19, 09:58    [21797474]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 40744
    Посмотри fsutil
    30 янв 19, 10:49    [21797534]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    mayton
    Посмотри fsutil


    Ее может не быть на клиентском компе.
    30 янв 19, 13:05    [21797710]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    kealon(Ruslan)
    Member

    Откуда: Нижневартовск
    Сообщений: 4620
    Flying-home
    Еще одна проблемка всплыла.
    Как узнать размер кластера на дисках:
    1. каталоги которых подключены через хардлинк.
    2. которые монтированы как NTFS папки других дисков.

    Функции GetDiskFreeSpace надо указывать корень диска да и сомнительная она, функции GetDiskFreeSpaceEx можно указывать каталог, но она не не показывает размер кластера.

    Открывать диск функцией CreateFile не хочется, надо повышать права.
    1. хардлинк может быть только на этот же том

    2. это софтлинк, общего механизма нет, в общем случае драйвер может послать куда угодно взять данные откуда угодно, даже виртуальные файлы "придумать"
    30 янв 19, 13:11    [21797715]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 40744
    Flying-home
    mayton
    Посмотри fsutil


    Ее может не быть на клиентском компе.

    Эта утилита использует API который тебе нужен. Типа fsutil fsinfo ntfsinfo [drive]
    Или поищи сорцы или описание у Рихтера или Руссиновича. Полюбому они
    должны были пройтись краями по этой теме.
    30 янв 19, 14:11    [21797780]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    mayton
    Flying-home
    пропущено...


    Ее может не быть на клиентском компе.

    Эта утилита использует API который тебе нужен. Типа fsutil fsinfo ntfsinfo [drive]
    Или поищи сорцы или описание у Рихтера или Руссиновича. Полюбому они
    должны были пройтись краями по этой теме.

    Угу.
    30 янв 19, 14:39    [21797815]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    kealon(Ruslan)
    1. хардлинк может быть только на этот же том

    Да. Я имел в виду junction points
    30 янв 19, 15:16    [21797886]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Если все делать правильно, то надо отказываться от GetDiskFreeSpace.
    Использовать DeviceIoControl с операцией IOCTL_DISK_GET_DRIVE_GEOMETRY
    Эта функция требует хэндл диска, открытого с помощью CreateFile, что в свою очередь требует повышения прав.

    По поводу симлинков: наверное, придется проверять каждую папку в пути на то, не является ли она ссылкой, и если является, смотреть, куда она указывает.
    30 янв 19, 15:53    [21797962]     Ответить | Цитировать Сообщить модератору
     Re: Оптимальный размер блока при записи файла на флэшку  [new]
    Flying-home
    Member

    Откуда: nas.vrostove.net
    Сообщений: 14660
    Может, можно обойтись меньшей кровью? Без повышения прав? Задачи-то простые.

    1. Есть файл, доступный для чтения. Теоретически доступа к корню диска, на котором он расположен, может не быть. Диск может быть компакт-диском. Надо узнать размер кластера файловой системы диска.

    2. Есть каталог, в который предстоит писать файлы. Права на запись в каталог есть. Доступа к корню диска может не быть. Опять же, надо узнать размер кластера.
    30 янв 19, 16:09    [21797983]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
    Все форумы / Windows Ответить