Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ZSZ
Цитата:
Цитата:| А вот тут пишут про то, что уже и DAEMON Tools научился монтировать zip архивы. |
В статье много маркетингового вранья |
Когда-то сходно поступила Intel - "Процессоры DEC Alpah AXP это вчерашний день и тупиковый путь развития техники.", а причин было две - производительность в четыре - пять раз более высокая чем у аналогов, и возможность за счёт подгрузки PAL кодов (микрокода чужих наборов команд и программной конфигурации ЦП) эмулировать любой иной ЦП с уровнем производительности от 0,997 на родных программах. Такой сильный конкурент им просто не был нужен и его купили, а купив тут же свернули проект объявив его "морально устаревшим и тупиковым путём развития техники" ещё в 1997-ом году. Так что цель такой статьи может быть не только в рекламе своего, но и в потоплении любых, в т.ч. возможных альтернатив и конкурентов.
Что до задачи монтировать контейнер как файловую систему, то V0lt и Aniskin показали вам что у неё есть критичное условие влияющее на время её решения - доступность данных для произвольного доступа. Для упрощения мы можем говорить что у нас в качестве модели выступают два разных устройства: НМД - дисковый накопитель и НМЛ - ленточный.
НМД позволяет на повернуть головку на определённую дорожку и считать произвольный блок данных за время равное времени поворота позиционера плюс время оборота диска до нужного сектора, и что важно в НМД головка не касается поверхности диска имея воздушный зазор над ней что позволяет ему вращаться с большой угловой скоростью. В итоге время доступа к данным достаточно мало даже для старой механики.
А у НМЛ нам нужно промотать ленту на N секторов от текущего до нужного, что займёт много больше времени т.к. лента трётся о поверхность головки и скорость её движения ограничена прочностью материалов ленты и головки на уровне нескольких метров в секунду. Поэтому время доступа будет тем больше, чем больший участок ленты нам надо промотать.
Обычный (не SOLID) архив по своим свойствам похож на НМД - т.к. он состоит из ряда независимых блоков данных, то мы считываем оглавление, находим там нужный блок и читаем его. Время доступа к произвольному фрагменту данных сложится из времени чтения содержащего его блока, времени поиска фрагмента в оглавлении блока и времени перехода к нужному нам фрагменту относительно начала данного блока. И в большей степени оно будет зависеть от величины считываемого блока и времени перехода от его начала к нужному фрагменту.
В случае с SOLID архивом сначала мы должны прочитать его оглавление и найти там смещение нужного сегмента относительно начала блока данных архива, затем считать единственный блок из архива до нужного смещения и только с него начать собственно чтение данных. Но время до начала чтения в нём будет тем больше, чем дальше от начала архива находится нужный нам фрагмент.
Т.е. в случаях с обычным и непрерывным архивами мы легко видим аналогию с механическими накопителями - в первом случае мы выбираем две координаты - БЛОК (цилиндр/дорожка/пластина в пакете) и СМЕЩЕНИЕ (сектор относительно начала дорожки и начальный бит данных в нём) относительно начала нужного блока, во втором только СМЕЩЕНИЕ относительно начала единственного блока.
Поэтому задача монтирования SOLID архивов хотя и решаема, но её решение в принципе более медленное чем в случае обычных архивов. И с этим, так же как и с тем, что внутренний формат контейнера может быть изменён в любой момент надо считаться, а значит тот кто берётся за её решение берёт на себя дополнительные заботы. А кому они особо нужны?
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
