Прилепите тему, пока желающие не найдутся.

Продолжая тему.
Есть ещё набирающий популярность в производительном секторе SAS, поддерживающий устройства SATA.
Есть желающие?

Ghost

Проблема в том как состыковать новый код с файловой системой.

Serge
Ну ты сам знаеш что у нас всегда проблема состыковать что то новое... В часте вещей думаю надо отказыватся от обратной совместимости, и переписывать с возможностью расширения.
Кстати вроде в файловой системе используется таблица сопоставления имени /hd/* и процедур работы с этим hd, так что думаю здесь особых проблем не должно быть, только с кешем надо разобраться.

Состыковка нового кода с файловой системой так, чтобы, скажем, /sdN соответствовало N-му SATA-диску при наличии функций чтения/записи и получения списка в каком-нибудь смысле - не проблема, можно сделать аналогично /bdN.

diamond

Я об интерфейсе между файловой системой и драйвером устройства. А различать sata и pata диски имхо только запутывать пользователей.

Можно и объединить SATA и ATA, только тут есть вопрос насчёт нумерации. В текущей ситуации есть каноническая нумерация, когда /hd0 = Primary Master, ..., /hd3 = Secondary Slave независимо ни от чего. В SATA настолько канонической нумерации вроде бы нет. И как это объединять, несколько непонятно.
Казалось бы, я тоже об интерфейсе... Все запросы от файловой системы нижележащему коду проходят через функции hd_read и hd_write (eax = номер сектора, ebx = указатель на буфер), за исключением перечисления дисков в 70.1 - там ещё нужна функция, которая по строке с именем определяет, входит ли указанный диск в соответствующий класс (сейчас /hdX или /bdX) и если входит, то какому конкретно устройству внутри класса это адресовано, а также функция перечисления всех устройств данного класса. Соответственно при наличии перечисления и критерия принадлежности остаётся только дописать в hd_read и hd_write несколько строчек, которые переадресуют запрос на чтение/запись.

diamond

Согласить, что читать устройства по одному сектору не очень хорошо. Может есть смысл разработать новый API vfs<->драйвер с учётом подключения сменных накопителей ?

В текущей ситуации есть каноническая нумерация, когда /hd0 = Primary Master, ..., /hd3 = Secondary Slave независимо ни от чего.

А насколько важна каноническая нумерация ? Она влияет на что-то в Колибри ?

Serge

Согласить, что читать устройства по одному сектору не очень хорошо.

Для PIO - в самый раз, а для DMA (а также для доступа через BIOS, которая обычно тоже DMA использует) реально (фактически уже на уровне драйвера устройства) чтение идёт по 16 секторов во внутренний буфер, а при дальнейших запросах, попадающих в прочитанную область, просто возвращается соответствующий сектор из внутреннего буфера (константа IDE_DMA ядра).

Может есть смысл разработать новый API vfs<->драйвер с учётом подключения сменных накопителей ?

Смысл, безусловно, есть, но учитывая, что это (кажется) третье предложение на моей памяти и все предыдущие загнулись, выглядит несколько нереалистично... Но я только за.

А насколько важна каноническая нумерация ? Она влияет на что-то в Колибри ?

Для работы не важна и ни на что не влияет. Но приятно, что при добавлении нового жёсткого диска не сбивается нумерация старых. Подобный вопрос уже обсуждался здесь: viewtopic.php?f=1&t=876

От Mario79.

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

Что было в Менуэт:

1.Одновременная работа только с одним разделом жесткого диска. Ни о каком копировании файла с раздела на раздел без дополнительных телодвижений со стороны пользователя не могло быть и речи.
2.Один единственный буфер кэширования на 1 Мб. При переключении на другой раздел жесткого диска (даже одного физического диска) происходило полное очищение кэша.
3.Исключительно PIO режим работы с жестким диском.
4.Буфер при записи на жесткий диск скидывается по 1 сектору.

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

Как это прирастало в Колибри.

1.Изначально дисковая система была идентична Менует.

2.Поскольку было большое желание работать хотя бы с двумя разделами, а лучше со всеми без дополнительных телодвижений была введена модернизация имен жестких дисков, позволившая обращаться к более чем одному жесткого диска без дополнительных телодвижений с программой SETUP. В процессе экспериментов было выявлено, что определение параметров раздела при каждом обращении к дисковой подсистеме тормозит скорость работы. По этой причине эта часть кода была вынесена в отдельную процедуру которая вызывается при загрузке системы и определяет все наличествующие разделы на жестком диске, а затем сохраняет их в специальном буфере (просмотреть его можно функцией 18.11). Из этого буфера во время работы эти данные извлекаются и используются по мере обращения к определенным разделам.

3.Было внедрено использование режимов DMA и UltraDMA (максимального который установил BIOS при загрузке компьютера).
3.1 В ходе разработке кода выяснилось, что чтение по 1 сектору как и запись скашивают весь прирост скорости в DMA режиме. По этой причине с целью минимизации изменения существующего кода был введен предбуфер чтения DMA на 16 секторов жесткого диска (каждый физический сектор 512 байт). При запросе 1 сектора производится считывание не только 1 сектора а еще 15 последующих, поскольку считывание производится за один запрос к физическому устройству, то никаких дополнительных задержек это не вызывает. Поскольку обращения к жесткому диск по большей части последовательное (разумеется мы не рассматриваем очень сильную фрагментацию данных, это повод для запуска дефрагментатора), то прирост скорости по сравнению с посекторным считыванием колоссален. Если в предкэше нужного сектора не окажется то производится его считывание вместе с последующими 15, т. е. Кэш полностью обновляется. С одной стороны максимальный «штраф» может быть в 15 секторов, но в ходе поставленных опытов выяснилось что 16 секторов это оптимальная величина, считывание 32 сектора было медленней и «штраф» тоже был больше, с другой стороны при считывании 8 секторов наблюдался резкий провал производительности, который выравнивался только к 4, то это уже было заметное снижение производительности. По этим причинам 16 стало опорным значением.
3.2 Для ускорения записи был применен несколько иной подход. Поскольку кэшу же был и совершать дополнительные телодвижения задействуя процессор для сортировки нужной последовательности секторов, чтобы слить их единым блоком не лучший выход. По этой причине есть две процедуры записи для DMA — одна записывает по одному сектору, другая от 2 до 64 секторов за раз. Поскольку в кэше данные могут располагаться как последовательно так и вразнобой, то соответственно алгоритм кода если не находит последовательных секторов общим числом больше 1, т.е. 2 и более вплоть до 64, записывает по одному сектору. Как только найдено два последовательных сектора начинается подсчет последовательных секторов вплоть до 64 секторов. Когда последовательность оборвется или достигнет 64 — этот кусок сбрасывается за один заход DMA на жесткий диск. Затем процедуры повторяются вплоть до того как весь кэш (те из его секторов которые помечены для записи) не будет записан по месту назначения. Такой подход позволил поднять скорость записи без дополнительных затрат для центрального процессора.

4.Поскольку буфер был один на все устройства и разделы, то сначала возникла идея доработать код чтобы он не очищался если чтение или запись производятся на разные разделы одного физического устройства. Это было реализовано и некоторое время система функционировала в таком виде. Однако провал в скорости при копировании на разные физические устройства был очень сильным. По этой причине было введена система независимых кэшей — каждому физическому устройству по кэшу. Первоначально их было максимум 4 потом стало больше но об этом позже. Изначально планировалось динамическое выделение памяти при старте системы, но в ходе экспериментов выяснилось что при размере кэша боле 1 Мб перебор всех секторов в таком кэше занимает много времени и замедляет скорость доступа к жесткому диску. Проблему решил бы алгоритм «хеширования», но по некоторым (неважным в контексте этой статьи) причинам он так и не был реализован. По этому размер кэша был ограничен 1 Мб — это максимальное значение, минимальное значение каждого кэша это 128 Кб. Минимальное значение взято приблизительно и исключительно для работы на старых компьютерах с недостаточным количеством оперативной памяти (16, 12, 8 Мб). Разумеется при уменьшении размера буфера скорость работы с файловой подсистемой падает ,но это меньшее зло чем совсем не работать с ней.
Дополнительная мера для повышения скорости работы — это сделать так чтобы служебные данные раздела и данные директорий - которые бывают нужны часто, а обновляются редко не выбивались из кэша новыми данными. Для этого планировалось разделить кэш на две неравны части — одну меньшую часть для служебных данных, другую большую часть для данных считываемых файлов. Также по некоторым причинам это было реализовано лишь для ATAPI устройств, поскольку для них требовалось только читающая часть кода, то написание кода было немного проще. После внедрения этого механизма — MP3 плеер перестал заикаться при непосредственном проигрывании CD и DVD дисков (раньше заикался потому что у него нету собственного кэша для файла, а сейчас система обеспечивает своевременную подачу порции данных), хотя ATAPI устройства до сих пор работают в PIO режиме. Реализация пакетного DMA режима для ATAPI устройств более сложная задача чем реализация DMA для жестких дисков.
В ходе экспериментов с кэшами также выяснилось, что код работы с кэшем внедренный в Менуэт ,который лежал в основе системы кэширования содержал фатальную ошибку, из-за которой первые реализации кода в DMA режиме вызывали порчу данных на жестком диске. Область дан