Обнаружил некоторые ненужные действия в процессе распаковки образовПоправил
Теперь работа программы ускорилась практически в два раза
На тестовом наборе (разные операции, в основном распаковка, но прилично и работы с секциями) примерно в 7.5 гигов время работы было примерно 40 минут, теперь в районе 21 минуты.
Продолжаю доработку вывода тех информации. Что бы и всю и читабельно
К сожалению, выходные закончились, так что дальше всё будет медленней.. До следующих выходных
Что такое кластерный АД? Это файловая система RSTS
По порядку.
Достаточно быстро разрабы RSTS дошли до точки, когда выяснилось, что 16-ти битный номер блока - это мало
Вспоминая другие ФС, можно увидеть три варианта - забили, с самого начала использовли больше 16-ти бит (RSX), ввели понятие секции (RT-11)
В RSTS народ пошёл своим (не оригинальным) путём - ввёл понятие кластера.
То есть, в зависимости от размера диска, вычсиляется размер кластера, так что бы номер блока оставался 16-ти битным - и вуаля. Этот размер кластера (устройства) иногда даже записывается в секретное место
А вот дальше начинается АД.
Помимо размера кластера для устройства - ввели ещё размер кластера для pack-а (а ля disk pack, а ля дисковый пакет). Типо - умолчание для всего файлового на диске. Тоже записан в метаинформации.
Но.
Если надо - для каталога можно ввести свой размер кластера по умолчанию - для всех файлов в этом каталоге.
И.
Если очень надо - для файла можно ввести свой размер кластера - конкретно для этого файла.
Да уж.. Гулять так гулять
На текущий момент - метаинформация обрабатывается вроде корректно и файлы извлекаются вроде тоже корректно.
Но вот техническая информаци, а конкретно - что в каком блоке что находится... Воюю
Последний раз редактировалось Hunta; 23.06.2025 в 10:34.
Тэкс.. вроде то, что я вижу в тех информации о записях в MFD и UFD и их распределении по блокам - меня устраивает
Последний раз редактировалось Hunta; 29.06.2025 в 14:59.
Как обычно - параллельно добавлению функционала - идёт доработка внутренностей и устранение старых "проблем".
С самого начала ImageUtils писался так, что бы не гонять лишний раз данные из образа туда-сюда. Скажем, если файл в образе занимает смежные блоки (непрерывный), то вместо создания для объекта файл массива с данными файла и копирования байт в него - ImageUtils создаёт объект SmartArray - который выглядит как массив, но на самом деле просто ссылается в основной массив с данными из образа.
Всё это хорошо работает, когда файлы (или другие данные из образа) непрерывные, но ... Это технически - редкий случай. И для НЕнепрерывных файлов всё делается по старинке. Вот это я и пытаюсь исправить - пока при работе с ФС RDS.
Движение вперёд есть, но пока ещё не всё работает. Тестирую, исправляю ошибки, доработатываю, тестирую,...
Упрощение структуры SmartArray. Проверено на наборе старых тестов и на работе с ФС RSTS.
На этом пока приостановлюсь - надо кое-что оценить и подумать - как двигаться дальше во внутренних доработках.
А пока вернусь к недоделанному в ФС RSTS
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Тесты по RSTS включил в общий список
С ФС RSTS вроде более менее закончил. Последние доработки - дамп метаинформации.
Дальше в планах - возможно, как обычно - рефакторинг кода и затем - разные вариант ФС RSTS на лентах.
Хе
Функционал допилил, все тесты (включая с ФС RSTS) прошли - очередной коммит.
И тут я налетел (в очередной раз) на ленту BRU с ошибками (переставлены местами блоки), так что малость поразвлекаюсь с новой программой (там крайне ранняя пред-альфа версия) - ImagesEditor
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
