Размер блока в драйверах блочных устройств

[captain cobalt]

Вообразим, будто мы хотим написать OS для Speccy. :)

Понадобятся драйверы блочных устройств.
Какой размер блока использовать?

[captain cobalt]

В рамках данного вопроса различие между понятиями сектора и блока существенно. Например iS-DOS использует сектора 1К но блоки 256 байт.

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

[AlexCrush]

Предлагаю Windows-образную иерархию драйверов. :D .

Драйвер устройства (FDD,HDD,CD-ROM,RAMDISK...) получает от вышестоящего драйвера файловой системы информацию о желаемом размере БЛОКА. Если драйвер устр-ва не может поддержать требуемый размер блока - все, жизнь данной файловой системы с данным драйвером устр-ва не сложилась. Если же может - все хорошо. Таким образом для ФС TR-DOS будет запрошен размер блока 256 байт, для FAT - 512 байт, и т.д.. Проблемы по конвертации блок - сектор полностью берет на себя драйвер устройства.

Как вариант, можно предложить еще более сложную схему -

"драйвер устройства" - "драйвер-конвертер" - "драйвер ФС".
Драйвер устр-ва сообщает конвертеру размер сектора, который поддерживает устр-во. Драйвер ФС сообщает конвертеру размер блока. А конвертер занимается преобразованием проходящей информации - разбиение блоков на сектора и склеиванием.

В обоих случаях будет достигнуто единообразие поддержки разных ФС на разных устр-вах. Правда возникают сложности в деталях (типа если просят записать блок 256 байт на устр-во с секторами 512 байт то придется сначала читать весь сектор, заменять в нем нужный блок и записывать обратно), но думаю, что все это разрешимо.

[captain cobalt]

Для начала, как насчёт простейшего решения: размер блока = размер сектора.

Драйвер файловой системы спрашивает у блочного драйвера: "какой у тебя размер блока?", и сам решает подходит ли такой размер.

[AlexCrush]

Вернее спросить не "какой у тебя размер блока", а "какие у тебя есть варианты размеров блока,предлагай". Для универсальности.

[GriV]

это то что размер блока должен быть кратен 2 - точнее быть образован от степени двойки (256, 1024 и т.д.).

Однако (моя т. зр.) в спекке памяти не очень то много, так что с позиций программиста блок может быть произвольного размера.

Можно выделить разные API-функции - для блоков кратных размеров и для блоков произвольных размеров. Вследствие математики первый будет быстрей, а второй менее затратен для памяти.

[psb]

Вообразим, будто мы хотим написать OS для Speccy.
:) :) :)

вот прикинь, есть у тебя дискета с форматом в килобайт на сектор. пзухой по нормальному ты не прочитаешь только четверть сектора, чтоб получить 256 байт. тебе придется читать весь сектор во временный буфер, а потом уже доставать из него нужное куда надо...

может, проще, чтоб уже тот, кто работает с устройством решал, может ли он с ним _таким_ работать? и пусть работает по-своему:) может ему даже лучше будет этот килобайт, чем сначала ты его будешь разбивать, а он потом обратно..

т.е., имхо, все от размера сектора:) а лишние (не оправданные?) виртуализации только едят быстродействие...

[Error404]

используй тот размер блока, который удобнее (проще) для организации файловой системы. Усложнять ни к чему. Да и, в сущности, какая разница? Если умеешь работать с любым размером сектора, то потом допишешь утилиту для работы с прочими форматами. Чтобы один то раз перегнать данные с с 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

[James DiGreze]

Такс... Стоп!
Мы говорим о размере блока в драйверах блочных устройств, или же о размере блока в виртуальных драйверах ФС?
Если говорить о драйверах блочных устройств, то размер блока ВСЕГДА равен размеру блока носителя. Если же подняться на уровень ФС, то размер блока будет соответствовать размеру блока, принятому для данной ФС. А пересчет этих блоков осуществляется виртуальным драйвером, являющимся, как раз, тем самым механизмом, который "сглаживает" все различия для API файловой системы.

[Alex/AT]

Бессмысленное обсуждение. Имхо, юзеру надо предоставлять возможность выбора размера блока ФС, независимо от размера сектора. jdigreeze прав.

[captain cobalt]

Такс... Стоп!
Мы говорим о размере блока в драйверах блочных устройств, или же о размере блока в виртуальных драйверах ФС? Мы говорим о программном интерфейсе между блочными драйверами и драйверами файловых систем.

Когда драйвер файловой системы использует процедуры вроде blockRead и blockWrite, какого размера блоки должны передаваться?

[James DiGreze]

В данном случае размер блока должен быть равен размеру блока файловой системы, принятой в качестве основной. Остальные ФС должны подключаться через виртуальные драйверы, которые и нивелируют разницу в размерах блоков и структуре информации ФС.

[captain cobalt]

Это слишком узкое и частное решение, когда гибкое гораздо проще.

А есть какие-нибудь предложения по выбору основной ФС?

[James DiGreze]

Ну, наверно NTFS... Хотя нет, ReiserFS будет надежнее... ;) Шютка юмора!
Из всех систем я не видел ни одной, которая бы удовлетворила все насущные потребности. Ближе всего к норме считаю ФС от iSDOS, но и она не идеальна, особенно в части использования дискового пространства на жестких дисках.
Есть кое-какие наброски по ее модернизации за счет виртуализации механизма работы с накопителями, что не должно сказаться по крайней мере на существующей прикладном ПО этой системы. Но работа над этим пока зашла в ступор из-за моей занятости. Если есть возможность, пиши на мыло, обязательно отвечу.

[Alex/AT]

Когда драйвер файловой системы использует процедуры вроде blockRead и blockWrite, какого размера блоки должны передаваться?
ФС сама определяет под себя размер блока и работает с LBA-номерами блоков. Все остальные различия нивелируются блочным драйвером и кешем. Как отформатирован диск - здесь не столь важно.

[Alex/AT]

А есть какие-нибудь предложения по выбору основной ФС?
Transactional FAT. Если извращаться - можно ext2, но накладные будут неслабыми...