Board.KolibriOS.org

#9734, #9735 exFAT file system support (only read)

Известные ограничения:
1) Диски более 2ТB, как и на драйвере FAT, работают только в пределах первых 2ТB. Потому что используются 32-х битные вызовы (2^32*512 байт). 64-х битные вызовы сложно использовать из-за IA-32. Код пухнет и его отладка сложна (мозг опух).
2) Отсутствие поддержки директорий с количеством записей более 4GB (если таковые найдутся в природе, 7 - 40 миллионов записей это не мало). Не путать с объемом содержащихся внутри файлов и субдиректорий!
3) Хэш имени файла не поддержан. Код вычисления хэша уже сделал, но нужно еще правильно интегрировать в текущий код - это должно немного ускорить поиск файлов и директорий при чтении (и в последствии записи).
4) Директория "." не реализована из-за ненужности.
5) Директория ".." - во всех директориях (кроме корневой, где по логике ее нет) создается виртуально. Все файловые менеджеры поддерживают это нормально, кроме FNav - он удаляет из своего списка настоящие директории "." и "..", однако не хочет также делать с виртуальной "..". В чем причина мне не известно, исходных кодов программы не наблюдаю.

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

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

Да не заметил. Извините

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.

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 (61.49 KiB)

Viewed 14477 times

C поддержкой хеша r9738

Spoiler:

SCR_1_hash.PNG (65.48 KiB)

Viewed 14477 times

2) eBox
Без поддержки хеша r9737

Spoiler:

SCR_ebox_nohash.PNG (67.5 KiB)

Viewed 14477 times

C поддержкой хеша r9738

Spoiler:

SCR_ebox_hash.PNG (64.14 KiB)

Viewed 14477 times

Использовал жесткий диск на 2TB, разбитый на кучу разделов. Диск подключен через USB коробку с контроллером SATA. На разделе exFAT предварительно создал директорию 6520 файлов и последним скопировал туда большой файл AVI, на котором тест производился.

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

Больший разрыв в показаниях мог быть, если бы длина имен файлов была больше, например более 250 байт (или 500 байт UTF16), но это специфическая ситуация и обычно имена файлов намного короче.

Так, кажется я что-то пропустил. Чего вы хотите добиться и какими средствами?

Pathoswithin

Spoiler:

exFAT_hash_docs.png (176.03 KiB)

Viewed 14454 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.