Serial ATA

Drive subsystem, filesystem drivers
  • Прилепите тему, пока желающие не найдутся.
  • Продолжая тему.
    Есть ещё набирающий популярность в производительном секторе 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 режиме вызывали порчу данных на жестком диске. Область данных кэша содержавших указатели номеров содержащихся секторов была на 1 единицу больше чем сам размер кэша, пока кэш был стабилен по местоположению видимо затирались не особо важные данные, а когда он стал динамическим это вылезло большими проблемами. Впоследствии ситуация была разрешена и баг «как бы» сам исчез с внедрением отдельных кэшей для каждого физического устройства.

    5.Система доступа через PIO режим по прежнему осталась посеторной, ее вышеописанное с DMA в плане ускорения работы не коснулось. В принципе можно доработать код аналогично DMA — для ATA контроллеров есть команды поддерживающие считывание за один запрос более 1 сектора, но судя по сравнению с работой Виндовс прирост по скорости будет максимум 10-30% и то только при последовательном чтении большого объема данных. Относительно этого делаем вывод что «овчинка выделки не стоит» потому что режимом PIO пользуются только в исключительных случаях, когда DMA режим не работает, а объем изменяемого кода весьма существенен.

    6.В дальнейшая доработка производилась Diamond'ом. Была она связана с добавлением дополнительных буферов для видимых из БИОС, но не видимых пока в самой Колибри устройств. Для тех дисков которые уже обнаружены самой ОС кэш не дублируется, а используется совместно при обащении к HD и BD дискам. Подробнее думаю он сам может рассказать.

    Возможность применения SATA и вообще новых дисков на сегодня ограничена 2 факторми:

    1.Прерывания построены на старой модели, где их максимум 15 штук (1 используется для каскадирования, хотя реально никакого каскадирования нету, но это сделано для совместимости со старым железом). Новые контроллеры SATA любят садится на прерывания выше 20-го, либо не садятся вообще, а это PIO режим.

    2.Отсутствует поддержка LBA48 - а это большой объем переделки кода. В принципе можно обойтись поддержкой 32-х битной адресации, но с современной скоростью развития жестких через 1-2 года это опять упрется в трубу. Дело в коде который в Колибри жестко завязан на максимум 32 бита, расширение до 64-х бит кода работы с ФС потребует большой переделки, по сути написать с нуля по крайней мере на 50-70% кода.

    P.S. by Ghost
    продублировал в "Ядро - концепция работы"
  • diamond

    Не уверен что и для PIO хорошо.

    Я не хочу лезть на логический уровень работы vfs, но заняться драйверами физических устройств могу.
    В моём представлении драйвер находит устройство, создаёт для него структуру данных, получает логический номер и сообщает его vfs. Драйвер предоставляет минимальный набор функций: чтение/запись секторов и чтение/запись конфигурации устройства. Между vfs и драйвером тонкая прослойка которая проверяет логическкий номер устройства и передаёт управление непосредственно драйверу. vfs работает с устройством через логический номер и ей всё равно что это за устройство - винчестер, флешка, сетевой диск или образ диска на флешке, поключенный через сеть.
  • Serge
    Адаптацией кода файловых систем к единому интерфейсу с драйверами физических устройств я заниматься в принципе готов.

    Всё так, но нужно продумать ещё два момента:
    1) что должно происходить при подключении нового и отключении старого устройства - то есть помимо обнаружения устройств и назначения логических номеров при загрузке системы должна быть возможность известить vfs о новом устройстве и удалении старого
    2) как именовать эти все устройства из ring-3 - какие пути должна принимать та же функция 70.
    Ушёл к умным, знающим и культурным людям.
  • 1)Нужны две функции vfs - добавление устройства и удаление устройства.
    Драйвер тоже должен поддерживать удаление устройства, это можно делать через конфигурацию устройства.

    2)Это не очень принципиально. Можно все жёсткие как и сейчас именовать /hdN, CD /cdN, сменные /rmN.
  • 1.a. Что бы не переполнять интерфейс (API) то VFS должна работать только с этими функциями, а исключительные случаи, например, устройство не съемное (обычные hd, cd), не должны увеличивать энтропию.
    1.b. Очевидно, нужно различать такие вещи как подключение устройства (флешка, виртуальные по FTP/SSH и т.д.) и "подключение" носителя (диск cd, образ cd).
    1.c. Блин, забыл :-).

    3. Так же будет полезным предусмотреть возможность "создания устройств" в пространстве пользователя (ring3), это те же виртальные сетевые устройства, образы дискет, cd и винтов. (Т.е. без написания драйвера для ring0.)

    ..bw
  • Who is online

    Users browsing this forum: No registered users and 8 guests