exFAT

Drive subsystem, filesystem drivers
  • Здорово! Не тестил правда... Ну хоть на чтение уже хорошо!(я и такое бы не написал) Но можно вот такое не делать:

    Code: Select all

    mov     ebp, [esp+12+8+4+4+7*4+262*2+4+4]
    
    Изобретайте колёса каждый раз, когда хотите написать новую программу.
  • Во-первых, данный кусок кода закомментирован и используется для целей отладки.
    Во-вторых, разработка не закончена - в последствии эти места будут зачищены.
    В-третьих, когда я закончу можешь, хоть на на столь обожаемый ЯВУ синтаксис переделывать. Чтобы было понятней для одних и непонятней для других.
  • Да не заметил. Извините
    Изобретайте колёса каждый раз, когда хотите написать новую программу.
  • sober_dev,

    Thank you for your work! I'm glad you are back.

    I attached a disk image with MBR and a single exfat partition.
    That partition has the only directory dir_50, which contains ~50 directories in it.
    The bug is that KolibriOS (any file manager) doesn't show all the dirs inside dir_50.

    I also attach a text output of 'ls -1a dir_50' command under Linux (expected result) and a screenshot of KolibriOS (current state).
    As you can see, directories with names starting from d0000000044 are not visible in KolibriOS.
    Attachments
    dir50_qemu.png
    dir50_qemu.png (17.38 KiB)
    Viewed 13500 times
    dir50_ls.txt (6.72 KiB)
    Downloaded 134 times
    Downloaded 136 times
  • dunkaist
    Я буду разбираться с этим кейсом чуть позже. Пока я внедрял поддержку хэшей, то обнаружил, что директории дальше первого кластера не считываются. Пока занимаюсь этой проблемой. Возможно эти случаи связаны.
  • #9737 - Fix r9734 - reading content outside of the first cluster of directory

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

    dunkaist
    Как я и предполагал это связанные кейсы. Ревизия 9737 читает все заявленные в dir50_ls.txt директории.
  • #9738 exFAT - support for file name hashes

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

    1) Мой комп, который еще на Athlon двухъядерном:
    Без поддержки хеша r9737
    Spoiler:
    SCR_1_nohash.PNG
    SCR_1_nohash.PNG (61.49 KiB)
    Viewed 13283 times
    C поддержкой хеша r9738
    Spoiler:
    SCR_1_hash.PNG
    SCR_1_hash.PNG (65.48 KiB)
    Viewed 13283 times
    2) eBox
    Без поддержки хеша r9737
    Spoiler:
    SCR_ebox_nohash.PNG
    SCR_ebox_nohash.PNG (67.5 KiB)
    Viewed 13283 times
    C поддержкой хеша r9738
    Spoiler:
    SCR_ebox_hash.PNG
    SCR_ebox_hash.PNG (64.14 KiB)
    Viewed 13283 times
    Использовал жесткий диск на 2TB, разбитый на кучу разделов. Диск подключен через USB коробку с контроллером SATA. На разделе exFAT предварительно создал директорию 6520 файлов и последним скопировал туда большой файл AVI, на котором тест производился.

    Таким образом создал условия, когда без хеша сравнивается 6520 имен, а с хешем сравнивается 1 имя (судя по счетчику сравнений, который я в текущий код не заливал на SVN). Получается современные процессоры (даже eBox) настолько мощные, что проглатывают такую разницу почти без запинки.

    Больший разрыв в показаниях мог быть, если бы длина имен файлов была больше, например более 250 байт (или 500 байт UTF16), но это специфическая ситуация и обычно имена файлов намного короче.
  • Так, кажется я что-то пропустил. Чего вы хотите добиться и какими средствами?
  • Pathoswithin
    Downloaded 141 times
    Spoiler:
    exFAT_hash_docs.png
    exFAT_hash_docs.png (176.03 KiB)
    Viewed 13260 times
    Вычисляется по документации
    Spoiler:

    Code: Select all

    UInt16 NameHash
    (
        WCHAR * FileName,    // points to an in-memory copy of the up-cased file name
        UCHAR   NameLength
    )
    {
        UCHAR  * Buffer = (UCHAR *)FileName;
        UInt16   NumberOfBytes = (UInt16)NameLength * 2;
        UInt16   Hash = 0;
        UInt16   Index;
    
        for (Index = 0; Index < NumberOfBytes; Index++)
        {
            Hash = ((Hash&1) ? 0x8000 : 0) + (Hash>>1) + (UInt16)Buffer[Index];
        }
        return Hash;
    }
    На современных PC процессорах прирост незначительный. Подозреваю, что сделано для более слабых процессоров, встроенных в фото-видеокамеры.
  • А, так имя файла прям рядом лежит. Я то думал, что директория как-то упорядочена по хэшам. Тогда не понятно, зачем оно вообще надо, если количество считываний с диска не меняется.
    Конечно, скорость работы вертелки с блинами не соизмерима даже с калькулятором, а линейная скорость USB ещё ниже. Тоже самое касается и SDD. Также это причина по которой файловые дескрипторы не повлияли бы на скорость, ведь повторный поиск файла происходит в кэше.

    Кстати, разница в скоростях подтверждает мои слова, что оптимальный размер операции при работе с носителем это 16 МВ. Для USB это выражено особенно ярко.
  • Pathoswithin
    Да, согласен. Весьма странна реализация хеша. В свое время пришлось прикручивать в скрипт шейпера трафика для утилиты tc - параметры работы с хешем. Вместо линейного списка на 1300 адресов IP, который нещадно загружал процессор сервера и все равно давал производительность не более 500 mbps, внедрение таблицы из 256 ячеек, с сортировкой по последнему октету, снизило нагрузку до 1-2%. Скорость поднялась до максимально доступной на сетевухе 1 gbps.

    Не уверен насчет 16 MB, поскольку замеры с SATA диска напрямую дали для размера блока 64 MB скорость 81920 КБ/с, а предыдущие значения были три раза по 79872 КБ/с, а еще до этого 5 раз по 96-97 тыс. Вероятно, это уже предел линейной скорости блинов. Плюс еще размер кеша диска тоже влияет.
  • #9744 exFAT_SetFileInfo - set attributes of file/folder (F70.6)

    Оказывается Шиндовс, в режиме параноика, проверяет по контрольной сумме каждый вход директории. Они идут наборами от 3-х до 19-и записей по 32 байта для вложенного файла или директории, в зависимости от длины имени. Теперь понятно зачем понадобился такой хеш - это компенсация падения производительности при вычислении контрольной суммы. У них даже алгоритм вычисления сходный. Хотя реализация хеша от этого не становится менее странной. Возможно реализация для Linux действует по такому же алгоритму.

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

    З.Ы. А еще для FAT отсчет даты ведется от 1980 года - надо поправить документацию.
  • #9745 Correction of documentation for F70

    Добавил пояснение насчет датировки стартующей от 01.01.1980. Я пока знаю о Fat12/16/32 и exFAT. Если у кого есть сведения об ограничениях для других систем - просьба дополнить.

    З.Ы. Поправка к предыдущему комментарию - Шиндовс отказался лечить образ диска примонтированного через утилиту ImDisk Virtual Disk Driver, так что настоящий реальный раздел на реальном диске может и будет лечить скандиском.
  • #9755 exFAT_Delete - delete file/folder (F70.8 )

    Удаление файлов и пустых директорий.

    З.Ы. Пока писал код нашел и исправил очередные баги в KFM, компоненте File Browser библиотеки Box_Lib и в OpenDialog.
  • Who is online

    Users browsing this forum: No registered users and 3 guests