ZXNet эхоконференция «zxnet.soft»

Hello, captain cobalt

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

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

Hello, captain cobalt

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

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

Hello, captain cobalt

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

Тогда надо определится с терминологией.
В CP/M минимальный блок для ОС называется логическим сектором и имеет размер
128 байт.

Hello, captain cobalt

cap> Какой размер блока использовать?

Чаще всего приходится ориентироваться на максимально возможный размер
физического блока (сектора).
Если говорить например о CP/M, то размер блока рационально выбрать равным 1
кбайту.

Hello, captain cobalt

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

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

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

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

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

Hello, All

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

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

Hello, captain cobalt

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

:) :) :)

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

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

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

Hello, psb

используй тот размер блока, который удобнее (проще) для организации файловой
системы. Усложнять ни к чему. Да и, в сущности, какая разница? Если умеешь
работать с любым размером сектора, то потом допишешь утилиту для работы с
прочими форматами. Чтобы один то раз перегнать данные с с TRDOS на нормальную
файловую систему и забыть про нее навсегда как про кошмарный сон. :) Есть, к
примеру, уже реализованный на ZX формат CP/M (к вопросу о велосипедах) -
имплементируется на любой размер блока именно описанным способом - читается NNN
байт (физический сектор), из них выделяется NN байт (логический сектор). И,
кстати, при лог. секторе 128байт и физическом 512/1к хорошим тоном в версиях
BIOS СP/M было за раз читать в буфер аж по 2к :) , что существенно ускоряло
среднестатистический процесс (на линейном чтении в особенности) работы с HГМД.
Это если не усложнять. А если хочешь приключений, то сразу планируй модульность
файловой системы, где при общем API допускается подключение модулей разных
файловых систем, а уж что они там внутри себя будут делать - их сугубо личное
дело.
Кстати, большинство файловых систем уже написано и существуют в открытом коде.
Вот, например, адаптированная для микроконтроллеров (по размеру кода) версия
для FAT12/16/32, нужно только процедуры работы с секторами кастомизировать - и
всё:
http://elm-chan.org/fsw/ff/00index_e.html

Hello, AlexCrush

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

Hello, jdigreze

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

Hello, captain cobalt

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

Мы говорим о программном интерфейсе между блочными драйверами и драйверами
файловых систем.

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

Hello, captain cobalt

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

Hello, captain cobalt

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

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

Hello, captain cobalt

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

Hello, Alex/AT

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

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

Hello, jdigreze

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

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