Вообразим, будто мы хотим написать OS для Speccy. :)
Понадобятся драйверы блочных устройств.
Какой размер блока использовать?
Вид для печати
Вообразим, будто мы хотим написать OS для Speccy. :)
Понадобятся драйверы блочных устройств.
Какой размер блока использовать?
В рамках данного вопроса различие между понятиями сектора и блока существенно. Например iS-DOS использует сектора 1К но блоки 256 байт.
Второй аспект - единообразие поддержки разных дисков. Если OS будет напрямую поддерживать только свой формат, а остальные только через спец копировщики - это нехорошо.
Предлагаю Windows-образную иерархию драйверов. :D .
Драйвер устройства (FDD,HDD,CD-ROM,RAMDISK...) получает от вышестоящего драйвера файловой системы информацию о желаемом размере БЛОКА. Если драйвер устр-ва не может поддержать требуемый размер блока - все, жизнь данной файловой системы с данным драйвером устр-ва не сложилась. Если же может - все хорошо. Таким образом для ФС TR-DOS будет запрошен размер блока 256 байт, для FAT - 512 байт, и т.д.. Проблемы по конвертации блок - сектор полностью берет на себя драйвер устройства.
Как вариант, можно предложить еще более сложную схему -
"драйвер устройства" - "драйвер-конвертер" - "драйвер ФС".
Драйвер устр-ва сообщает конвертеру размер сектора, который поддерживает устр-во. Драйвер ФС сообщает конвертеру размер блока. А конвертер занимается преобразованием проходящей информации - разбиение блоков на сектора и склеиванием.
В обоих случаях будет достигнуто единообразие поддержки разных ФС на разных устр-вах. Правда возникают сложности в деталях (типа если просят записать блок 256 байт на устр-во с секторами 512 байт то придется сначала читать весь сектор, заменять в нем нужный блок и записывать обратно), но думаю, что все это разрешимо.
Для начала, как насчёт простейшего решения: размер блока = размер сектора.
Драйвер файловой системы спрашивает у блочного драйвера: "какой у тебя размер блока?", и сам решает подходит ли такой размер.
Вернее спросить не "какой у тебя размер блока", а "какие у тебя есть варианты размеров блока,предлагай". Для универсальности.
это то что размер блока должен быть кратен 2 - точнее быть образован от степени двойки (256, 1024 и т.д.).
Однако (моя т. зр.) в спекке памяти не очень то много, так что с позиций программиста блок может быть произвольного размера.
Можно выделить разные API-функции - для блоков кратных размеров и для блоков произвольных размеров. Вследствие математики первый будет быстрей, а второй менее затратен для памяти.
:) :) :)Цитата:
Сообщение от captain cobalt
вот прикинь, есть у тебя дискета с форматом в килобайт на сектор. пзухой по нормальному ты не прочитаешь только четверть сектора, чтоб получить 256 байт. тебе придется читать весь сектор во временный буфер, а потом уже доставать из него нужное куда надо...
может, проще, чтоб уже тот, кто работает с устройством решал, может ли он с ним _таким_ работать? и пусть работает по-своему:) может ему даже лучше будет этот килобайт, чем сначала ты его будешь разбивать, а он потом обратно..
т.е., имхо, все от размера сектора:) а лишние (не оправданные?) виртуализации только едят быстродействие...
используй тот размер блока, который удобнее (проще) для организации файловой системы. Усложнять ни к чему. Да и, в сущности, какая разница? Если умеешь работать с любым размером сектора, то потом допишешь утилиту для работы с прочими форматами. Чтобы один то раз перегнать данные с с TRDOS на нормальную файловую систему и забыть про нее навсегда как про кошмарный сон. :) Есть, к примеру, уже реализованный на ZX формат CP/M (к вопросу о велосипедах) - имплементируется на любой размер блока именно описанным способом - читается NNN байт (физический сектор), из них выделяется NN байт (логический сектор). И, кстати, при лог. секторе 128байт и физическом 512/1к хорошим тоном в версиях BIOS СP/M было за раз читать в буфер аж по 2к :) , что существенно ускоряло среднестатистический процесс (на линейном чтении в особенности) работы с НГМД.
Это если не усложнять. А если хочешь приключений, то сразу планируй модульность файловой системы, где при общем API допускается подключение модулей разных файловых систем, а уж что они там внутри себя будут делать - их сугубо личное дело.
Кстати, большинство файловых систем уже написано и существуют в открытом коде. Вот, например, адаптированная для микроконтроллеров (по размеру кода) версия для FAT12/16/32, нужно только процедуры работы с секторами кастомизировать - и всё:
http://elm-chan.org/fsw/ff/00index_e.html
Такс... Стоп!
Мы говорим о размере блока в драйверах блочных устройств, или же о размере блока в виртуальных драйверах ФС?
Если говорить о драйверах блочных устройств, то размер блока ВСЕГДА равен размеру блока носителя. Если же подняться на уровень ФС, то размер блока будет соответствовать размеру блока, принятому для данной ФС. А пересчет этих блоков осуществляется виртуальным драйвером, являющимся, как раз, тем самым механизмом, который "сглаживает" все различия для API файловой системы.
Бессмысленное обсуждение. Имхо, юзеру надо предоставлять возможность выбора размера блока ФС, независимо от размера сектора. jdigreeze прав.