NTFS

Drive subsystem, filesystem drivers
  • Может лучше сделать, чтобы пользователь не заматерился от того, как медленно ползёт шкала? Проверь скорость копирования на жёстком диске под виндой. Можно менять размер операции в зависимости от типа устройства. Я тебе дал ссылку, где описана проблема механических вертелок с блинами, со старым драйвером они всегда вот так ползали, а теперь с одной операцией на 400 МБ справляются за 5 секунд.
  • Pathoswithin wrote:с одной операцией на 400 МБ справляются за 5 секунд
    Не 5 секунд, а примерно 1 минута. И не 400 Mb, а, как видно на скриншоте, 241 Mb viewtopic.php?f=31&t=659&start=225#p68027

    Если говорить про viewtopic.php?f=31&t=659&start=225#p68028
    то получается, что для KFM потребовалось 256 Mb(четверть ОЗУ), в то время как для fNav только 256 Kb. При этом KFM справился менее чем на 15% быстрее, запросив для этого в 1024(!!!) раз больше памяти. Также, KFM зависал на время копирования.
    Pathoswithin wrote:Проверь скорость копирования на жёстком диске под виндой.
    Сделал некоторые замеры ради интереса.
    Копировался тот же самый файл 1,36 ГБ (1 465 528 320 байт), находящийся на HD FAT32.
    При копировании на USB флешку NTFS через explorer это заняло примерно 3,5 минуты.
    При копировании через TotalCommander на USB флешку NTFS в режиме "use big file copy mode" буфер 64 K — чуть более 4 минут.
    При копировании с помощью fNav из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — примерно 1,5 минуты.
    При копировании с помощью KFM из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — 01:20.

    Лично для меня это мало что прояснило. Попробую ещё разные варианты размера буфера во fNav на реальной системе. Возможно, будет смысл увеличить его в пределах 2..8 Mb(я в то же время не хочу, чтобы пользователь замечал подвисание во время копирования).
    Pathoswithin wrote:Если сделать работу с файлами в отдельном потоке, не будет зависать.
    А вот если добавить не один, а два дополнительных потока, то, возможно, смысл есть. Один поток непосредственно копирует и сам он вполне может подвисать(это не будет заметно, он окна не имеет), второй поток имеет окно и отображает прогресс, его окно всегда будет реагировать на действия пользователя. Общаться они также могут с помощью IPC. Просто нужно больше потоков.
  • Ну что тебе не понятно? Диск крутится и продолжает крутится после окончания операции. Когда работа с непрерывными данными прерывается, нужно ждать почти полный оборот диска, чтоб вернутся к нужному месту и продолжить. Скорость в итоге зависит от того, насколько существенны эти задержки по сравнению с операциями. Прошивка диска бывает достаточно умной, чтобы избежать этих задержек, но оптимальный размер операции - 16 МБ.
    С ФС всё ещё хуже: каждое увеличение файла это куча мелких операций в разных местах диска, тут надо ещё и головками двигать. Умный виндовый кэш способен это компенсировать почти полностью, а у нас чем больше размер операций, тем меньше лишних (а ещё, ниже вероятность фрагментации файла).

    А оперативная память для того и есть, чтоб её использовать.
  • Pathoswithin wrote:А оперативная память для того и есть, чтоб её использовать.
    Использовать надо рационально. Если не видно разницы, то зачем тратить больше? А то получается копеечная выгода в быстродействии в обмен на более чем 1000-кратные затраты памяти.

    Я в прошлый раз ошибся
    0CodErr wrote:для KFM потребовалось 256 Mb(четверть ОЗУ), в то время как для fNav только 256 Kb. При этом KFM справился менее чем на 15% быстрее, запросив для этого в 1024(!!!) раз больше памяти.
    На самом деле четверть ОЗУ это 512 Mb. Следовательно, KFM запросил не в 1024, а в целых 2048 раз больше памяти.

    Я решил сделать некоторые замеры в зависимости от размера буфера.
    Создал для этого несколько версий fNav: fNav(128Mb).kex, fNav(16Mb).kex, fNav(1Gb).kex, fNav(1Mb).kex, fNav(256Kb).kex, fNav(256Mb).kex, fNav(2Mb).kex, fNav(32Mb).kex, fNav(4Mb).kex, fNav(512Mb).kex, fNav(64Mb).kex, fNav(8Mb).kex
    Копировался файл размером 1,36 ГБ (1 465 528 320 байт) с HD FAT32 на USB NTFS.
    Размер RAM = 2 Gb.
    К сожалению, при размере буфера 1 Gb удалось скопировать только 1,00 ГБ (1 073 741 824 байт).
    Малозаметные зависания появляются уже при размере буфера 1 Mb.
    Получилась такая табличка:
    Spoiler:
    0.png
    0.png (11 KiB)
    Viewed 9511 times
  • Вот зачем ты копируешь на флешку? Мы и так знаем, что они медленно работают. Тестируй жёсткий диск. Можешь читать на рамдиск, писать с рамдиска, а самые яркие результаты будут при копировании в пределах диска.
  • Pathoswithin wrote:Вот зачем ты копируешь на флешку?
    Чтобы раздел не запороть. А то мало ли... Но вообще хорошо было бы, если кто-то сравнил бы скорость копирования HD -> HD при различных размерах буфера.
    Pathoswithin wrote:Мы и так знаем, что они медленно работают.
    А зачем ты скорость сравниваешь? Ты соотношение сравнивай.

    Яркий результат пока вот
    0CodErr wrote:К сожалению, при размере буфера 1 Gb удалось скопировать только 1,00 ГБ (1 073 741 824 байт).
    Но неизвестно, это ошибка записи на NTFS или ошибка чтения с FAT32(64Kb кластер). По идее EOF должен при чтении приходить. Но вон там viewtopic.php?f=31&t=659&start=225#p68015 было копирование NTFS -> NTFS, и тоже скопировалось меньше.

    Одно ясно — даже после стольких лет разработки в KolibriOS с дисковой подсистемой ещё очень много проблем. И для серьёзных вещей она не годится.
  • Ну у меня как-то Netsurf читал папку с FAT32 и умудрился превратить её в фарш. Уж не знаю, как такое получилось, но shit happens даже при чтении. А скорость копирования я уже сравнил - разница в несколько раз, что не удивительно. Можешь чтение на рамдиск проверить, там тоже какая-то разница будет. А у флешек разница совсем скромная - они ж не механические.

    Если EOF, значит при чтении.

    Спасибо, Кэп. В течении всех этих лет её разрабатывало не более одного человека за раз.
  • Pathoswithin wrote:Ну у меня как-то Netsurf читал папку с FAT32 и умудрился превратить её в фарш.
    Ну если только папку, то, подумал я, рискну тогда. Но, к сожалению, "Not supported for this file system". Папка не сжатая, не шифрованная. Chkdsk ошибок не нашёл. Просто что-то не поддерживается.

    Похоже придётся отложить это до лучших времён. Предлагаю попробовать пофиксить EXT. Может хотя бы там заработает.
    Pathoswithin wrote:А скорость копирования я уже сравнил - разница в несколько раз, что не удивительно. Можешь чтение на рамдиск проверить, там тоже какая-то разница будет.
    На рамдиске же FAT, а хотелось проверить запись NTFS. И для рамдиска тоже нужно память выделять, тогда для буфера копирования останется мало(всего RAM 2 Gb). C FAT32 на FAT32 тоже проблема, там у меня размер кластера 64 Kb, а это сейчас в KolibriOS глючит.
    И, кстати, вон там viewtopic.php?f=31&t=659&p=68039#p68032 из-под KlbrInWin разница не в разы, а точно так же примерно 15%.

    Может есть ещё желающие протестировать?

    И всё-таки не понятно, какой лучше размер буфера для копирования? Ведь уже при 1 Mb начинаются еле заметные подвисания(а дальше больше). Думаю, что увеличить его во fNav с 256 Kb всё равно надо. Может пока для тестирования несколько версий выложить стоит?
  • Тестить надо только на реальном железе? И какие конкретно условия теста?
    to infinity and beyond
  • Pathoswithin wrote:Ну у меня как-то Netsurf читал папку с FAT32 и умудрился превратить её в фарш. Уж не знаю, как такое получилось, но shit happens даже при чтении.
    А там, наверное, происходит ещё установка LastAccessDate, то есть, запись тоже присутствует при чтении.
    Но, к сожалению, "Not supported for this file system".
    Даже не создаётся файл. Это скорее всего из-за ограничения 32000(если не ошибаюсь). У меня на разделе файлов явно гораздо больше. С чем связано ограничение, кстати?
    punk_joker wrote:Тестить надо только на реальном железе?
    Ну по идее да. Я вот хотел запись NTFS проверить, но кроме как на флешку никакой другой возможности у меня нет.
  • Готов потестить на реальном железе. Если надо, могу и fNav с разными буферами протестить.
    to infinity and beyond
  • Для увеличения полноты картины вон того viewtopic.php?f=31&t=659&p=68039#p68032
    При копировании с помощью fNav из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — примерно 1,5 минуты.
    При копировании с помощью KFM из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — 01:20.
    решил проверить также в TotalCommander на тот же самый диск в режиме "use big file copy mode" буфер 10240 Kb. Результат — 01:07. И никаких "в разы" тут и близко нет.
    Pathoswithin wrote:теперь с одной операцией на 400 МБ справляются за 5 секунд.
    То есть, это получается 80 Mb\s.

    Я потому и спросил
    0CodErr wrote:Pathoswithin, а у тебя может там AHCI?
    Или ещё что-то...

    У меня ATA100. Вон там http://www.realworldtech.com/ata100/ пишут
    The main thing to remember is that the ATA/100 (100MB/s) speed ONLY applies to buffer to host transfers. That is, when the operating system can’t find the data needed in its own cache, and it is not in the controller’s cache, but doesn’t need to be retrieved from the actual disk itself (the platters). A small amount of data is cached in the disk’s buffer, and that is the ONLY data that will be transferred at ATA/100 speed. Any data retrieved from the actual platters cannot be done so at that high rate of speed – period. The chances that the system will be able to find what it needs in the disk buffer (unless your request are very small and fits the cache scheme) are slim to none, mostly due to its small size. So, your limiting factor is the actual data transfer from the platters to the buffer – which is well under the ATA/100 speed, under ATA/66 speeds, and not much better than ATA/33.
    А на второй странице есть таблица http://www.realworldtech.com/ata100/2/ и результаты там не так уж сильно отличаются от виндовых.
    Вот перевод статьи http://stolica.ru/techinfo/article/2001_02/07_01.htm
  • У меня там SATA в режиме IDE, но скорость диска определяется его размером, а там аж 160 ГБ.

    punk_joker
    Надо сравнить fNav с KFM (или Eolite) на реальном диске - время копирования крупного файла, файловые системы любые (хотя запись на FAT может работать медленней), дополнительно можно проверить скорость работы с рамдиском.
  • 926 mb файл, копировался на FAT32 раздел SSD диска (как оказалось, только на нем был подходящий раздел, позже проверю все таки и на жестком) с HDD в режиме AHCI (в режиме bios-диски)
    KFM 0:39 мин
    fNav 2:50 мин
    to infinity and beyond
  • Who is online

    Users browsing this forum: No registered users and 4 guests