Дисковая система

Kernel architecture questions
  • Если можешь, а также хочешь или считаешь нужным - делай. Я не возражаю, думаю, остальные тоже.
    А файловые системы должны быть реализованы без привязки к устройствам. Файловая система будет использовать лишь функцию плоского доступа.
    Под плоским доступом я подразумеваю "получить n байт по такому-то смещению".
    1. Не факт, что функции плоского доступа будет достаточно. Мне с ходу приходит в голову, что у разных устройств, вообще говоря, разные размеры сектора (дискета, жёсткий диск - 0x200 байт, CD-ROM - 0x800 байт), причём существующий код поддержки файловых систем более или менее жёстко завязаны на 0x200 байт, кроме UDFS - там, наоборот, 0x800 байт.
    2. Функции работы с устройствами по идее всегда выдают целое число секторов.
    3. А как же запись? Нужны две функции (одну общую функцию, принимающую дополнительный параметр и делающий switch по нему, не предлагать).
    со структурой до конца не определился, т.к. плохо знаю как устроены файловые системы. Там должны быть указатели функций для работы с фс и доп инфа.
    В текущей реализации информация, нужная для работы коду поддержки файловой системы, хранится в fs_dependent_data_start (fs/part_set.inc) (где описана структура) для текущего обращения к диску и в DRIVE_DATA для всех дисков (куда/откуда она копируется при резервировании раздела). Плюс некоторое количество неинициализированных глобальных переменных ядра.
    По поводу путей: не совсем понял, текущие пути (/rd/1/somefile.dat, /hd0/1/somefile.dat) сохранятся или изменятся? Если изменятся, то как?
    Ушёл к умным, знающим и культурным людям.
  • diamond wrote: 1. Не факт, что функции плоского доступа будет достаточно. Мне с ходу приходит в голову, что у разных устройств, вообще говоря, разные размеры сектора (дискета, жёсткий диск - 0x200 байт, CD-ROM - 0x800 байт), причём существующий код поддержки файловых систем более или менее жёстко завязаны на 0x200 байт, кроме UDFS - там, наоборот, 0x800 байт.
    хм, не знал что файловая система привязывается к секторам. Насколько я читал про FAT там идет понятие блока, и вроде никакой привязке к секторам. Про остальные не знаю. Да и к тому же, как устроены флешки? У меня на флешке стоит FAT32, что не ужели на флешках тоже есть сектора?
    Вот тут я не до конца разобрался(может плоский досуп будет сводится не к байтам а к секторам). Система получается очень похожа на юниховую. В ней девайсы представлены в виде файлов, при маунте любого диска, файловая система через этот файл(точнее иноду) получает доступ к данным на диске, при этом не важно как этот диск устроен физически.
    diamond wrote:2. Функции работы с устройствами по идее всегда выдают целое число секторов.
    Ответ либо в пункте 1, либо никто не мешает обрезать т.к. требуется.
    diamond wrote:3. А как же запись? Нужны две функции (одну общую функцию, принимающую дополнительный параметр и делающий switch по нему, не предлагать).
    Без проблем. Только почему не катит switch?
    Можно сделать 2 варианта:
    1) просто в таблицу еще один указатель
    2) указатель будет не на ф-цию, а на массив ф-ций. Это более гибче, особенно в плане добавления новых ф-ций.
    diamond wrote:В текущей реализации информация...
    Спасибо за инфу, будет полезно!
    diamond wrote:По поводу путей: не совсем понял, текущие пути (/rd/1/somefile.dat, /hd0/1/somefile.dat) сохранятся или изменятся? Если изменятся, то как?
    изменятся. В текущей реализации уходило 2 уровня на определение диска(/hd1/1/). Я предлагаю свести к одному.
    Как именовать не суть важно. Можно hd1,hd2,hdn. Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю? Еще можно что-то вроде линуха hda1,hda2,hdb1, или BSD ad1s1... Опять же - это не суть важно. По моей задумке можно будет вообще именовать /c/, /d/ и т.д.
  • k@sTIg@r
    Насколько я читал про FAT там идет понятие блока, и вроде никакой привязке к секторам.
    Под блоком подразумевается кластер. Из блоков соответственно состоят файлы и директории, но вот служебная информация (собственно сам FAT) ориентирован на работу с секторами.
    Да и к тому же, как устроены флешки? У меня на флешке стоит FAT32, что не ужели на флешках тоже есть сектора?
    Флешка эмитирует дисковое устройство с минимальным размером сектора 512 байт.
    изменятся. В текущей реализации уходило 2 уровня на определение диска(/hd1/1/). Я предлагаю свести к одному.
    Как именовать не суть важно. Можно hd1,hd2,hdn. Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю? Еще можно что-то вроде линуха hda1,hda2,hdb1, или BSD ad1s1... Опять же - это не суть важно. По моей задумке можно будет вообще именовать /c/, /d/ и т.д.
    А вот с этим я не согласен. В том же Линукс, по пути можно определить какое физическое устройство используется. Для отладки очень удобно. И к томуже мне не очень нравится излишняя абстракция системы от железа.
  • Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю?
    А вот с этим я не согласен. В том же Линукс, по пути можно определить какое физическое устройство используется.
    У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ? Так и хочется спросить а где hd1, hd2, cd1 ? (В Ubuntu логические разделы выглядят не лучше - sda2 sda5 sda6). Это раньше было 4 ide устройства, а теперь чёрт ногу сломит. И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?

    Вообще давно пора сделать файловую систему с дескрипторами файлов, и стандартный интерфейс к драйверу физического устройства. Здесь хорошо подойдёт ООП подход. Нужны функции получения параметров устройства, инициализации, сброса при ошибке, чтения и записи n-го количества секторов. Получается вируальный базовый класс физического устройства а дальше уже будут свои производные классы для каждого типа устройств.
  • Serge
    > Получается вируальный базовый класс физического устройства а дальше уже будут свои производные классы для каждого типа устройств.

    Собственно это я и хочу сделать :) Правда я не думал о классах, но к этому шло, покрайней мере логика таже
  • "И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?" - не могу не фспомнить, что ни того, ни другого Колибри не поддерживает) да и мне лично подход изменения жутко не нравится, хорошо как есть. Про работу через дескрипторы и проч. - это надо писать(переписывать) всю файловую систему, хотя это несомненно приблизит нас к большей высокоуровневости.. но оно надо такое чудо? кстати лично я не против и идеи, и насчет помочь) просто спросил)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Gluk
    Может потому и не поддерживает :)
    Ладно, usb на асме вещь непростая. Пусть будет драйвер виртуального диска. Это проще. Будет удобно работать с образами и в эмуляторе и в реальной системе. И как монтировать и именовать такие диски?
  • Serge
    А что собственно нам мешает иметь 2 разных наименования для дисков?
    Я высказал свое мнение с учетом своего личного опыта работы с дисковыми системами в Винде. Зачастую очень сложно бывает ориентироваться в номерах букв, потому что все разделы очень редко имеют уникальные имена, а судить по размеру логического диска - все равно, что гадать на кофейной гуще. Приходится лезть в свойства и искать - "А на каком это физическом диске расположен искомый логический?".
    А так по внешнему виду пути можно с большей уверенностью сказать, что за зверь перед нами, потому что такое название будет неизменным, пока не будет создан новый логический диск посредине уже имеющихся или существующий не будет разбит на 2 или более. А Винда совершенно от балды может повесить диски вперемешку. У меня есть большое подозрение, что и здесь в выбранном направлении развития получится та же хрень...
    Надо взвесить все за и против, прежде чем так кардинально менять систему для уровня приложений - опять будем, плюясь переписывать кучу программ. ИМХО я этому не рад.
  • k@sTIg@r wrote:Меня посетила такая мысль.
    Может стоит переделать немного дисковую подсистему?
    Основная идея разделить драйвер файловой системы от драйвера устройства.
    Ты не первый, кого посещает эта мысль. Было также предложение halyavin'а: http://shade.msu.ru/~msu-se/driversystem.html
    viewtopic.php?f=2&t=356
    k@sTIg@r wrote:В текущей реализации уходило 2 уровня на определение диска(/hd1/1/). Я предлагаю свести к одному.
    Как именовать не суть важно. Можно hd1,hd2,hdn. Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю?
    Вообще лучше сохранять совместимость, если нет веских причин этого не делать. Далее, физическое размещение партиции рядовому пользователю не нужно, но это не значит, что его вообще бесполезно знать. В винде я в принципе умею это определять программно (при наличии прав админа), но понятия не имею, как это сделать пользователю, а иногда это нужно.
    С другой стороны, в словах
    Serge wrote:У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ? Так и хочется спросить а где hd1, hd2, cd1 ? (В Ubuntu логические разделы выглядят не лучше - sda2 sda5 sda6). Это раньше было 4 ide устройства, а теперь чёрт ногу сломит. И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?
    тоже что-то есть.
    Mario79 wrote:Под блоком подразумевается кластер. Из блоков соответственно состоят файлы и директории, но вот служебная информация (собственно сам FAT) ориентирован на работу с секторами.
    Ну вообще-то сам FAT тоже содержит информацию о кластерах. Но от необходимости знать размер сектора это не освобождает: некоторые критические параметры файловой системы выражены в секторах. Кроме того, код поддержки файловой системы, как уже было сказано, существенно использует размер сектора.
    Ушёл к умным, знающим и культурным людям.
  • Gluk
    >Хорошо как есть....

    Для чего хорошо? для текущей ситуации - да, лучше не бывает, все работает и хорошо. А если смотреть в будущее? Придется приходить ко всяким ухищрениям, чтоб прикрутить те же флешки. а про сетевые я молчу.
    Так зачем делать сразу ущербно? Тем более на данный момент переделывать не так уж и много.

    Maro79
    Как бы тебе объяснить. То что я скажу растроит многих. Автоматического монтирования не будет! Автоматически будет монтироваться только рамдиск. Вот тут уже есть несколько путей:
    1) для продвинутых юзеров. Будет конфиг файл, который будет маунтить такой-то такой-то диск туда-то туда-то.
    2) для простых. Будет програмка, которая будет детектить фс на диске (должна быть ф-ция файловой системы) и монтировать автоматически под определенными именами (по типу текущей реализации)
    Тут есть много вариантов и нюансов.

    Давайте выясним все за и против. Я "против" не вижу :) А все "за", как я вижу, вроде бы все понимают.
  • diamond wrote: Ты не первый, кого посещает эта мысль. Было также предложение halyavin'а:
    Черт, плагиатчик :)
    Тока не понял, почему все загнулось? Хотя в моем представлении все работает немного по другому.
    diamond wrote:Вообще лучше сохранять совместимость, если нет веских причин этого не делать.

    Это понятно. Но такой вид по крайней мере некрасиво и неудобно. Да и не вижу проблем. Проблемы будут если какие-либо приложения использовали полные пути (например /rd/1/...). Просто придется такие перебить на /rd/... Собственно и все. Зато дальше удобней будет.
    diamond wrote:Далее, физическое размещение партиции рядовому пользователю не нужно, но это не значит, что его вообще бесполезно знать. В винде я в принципе умею это определять программно (при наличии прав админа), но понятия не имею, как это сделать пользователю, а иногда это нужно.
    Да, не спорю, нужно знать. Но не по монтируемому имени же? Будет доп функция, которая по имени диска выдаст тебе инфу.
    diamond wrote:Ну вообще-то сам FAT....
    Да, тут пардон, полез в дебри которые не знаю. Ща кое-что почитал и понял. Для примера в том же линухе, есть понятие блочный девайс (а не так как я думал раньше, что это обычный файл и писец).

    Придется мои какракули переписать...
  • Тока не понял, почему все загнулось?
    У нас хорошие идеи обычно загибаются от того, что некому писать код :(
    Хотя в моем представлении все работает немного по другому.
    Пожалуйста, пиши как представляешь. Мнение пишущего код программиста всегда приоритетнее остальных.
    Проблемы будут если какие-либо приложения использовали полные пути (например /rd/1/...). Просто придется такие перебить на /rd/... Собственно и все. Зато дальше удобней будет.
    Проблемы будут с файловыми менеджерами. kfar, например, считает во многих местах, что пути выглядят именно так, как они сейчас выглядят (/имя устройства/раздел/путь на устройстве). sysxtree использует структуру существующих путей при показе значков и отображении типа элемента на первых двух уровнях файловой иерархии. Насчёт kfm не знаю.
  • "Для чего хорошо? для текущей ситуации - да, лучше не бывает, все работает и хорошо. А если смотреть в будущее?" - хорошо по простой и банальной причине что мне это удобно, и по моему лучше не надо, просто потому что не нужно, не имеет смысла, и лучше будет означать хуже)

    "У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ?" - уточню твою задачку. sata у тебя наверное не просто hd0, ф /hd0/1/ + /hd0/2/ , то же с ide. абсолютно видно какой раздел где лежит по крайней мере об этом тебе "это говорить")
    А теперь реши мою задачку - у меня в винде один sata, один флоппик, один сидиром, один кардридер. логически это диски A, C, D, E, F, G, H, I, J, M. итак, что мне об этом говорит? ;) а ты как я понял хочешь добиться примерно того же в нашей птичке.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • diamond
    KFM не меньше чем KFAR завязан на вид пути. Так что переделка предстоит немалая.

    k@sTIg@r
    Как бы тебе объяснить. То что я скажу растроит многих. Автоматического монтирования не будет! Автоматически будет монтироваться только рамдиск. Вот тут уже есть несколько путей:
    1) для продвинутых юзеров. Будет конфиг файл, который будет маунтить такой-то такой-то диск туда-то туда-то.
    2) для простых. Будет програмка, которая будет детектить фс на диске (должна быть ф-ция файловой системы) и монтировать автоматически под определенными именами (по типу текущей реализации)
    Тут есть много вариантов и нюансов.
    Нафига козе баян, а лысому расчестка?
    Почему какое-то приложение определяет наличие дисков? В Линукс давно используют автомонтирование. Но зачем плодить лишний код, который, безусловно, будет содержать ошибки?! ИМХО такие вещи доверять уровню приложения просто глупо!
    Я не спорю после загрузки можно иметь возможность примонтировать, и размонтировать какой либо логический диск. Но при загрузке это обязательно должно делать ядро!
    Если тебя не устраивает то, что я написал, то вот аргумент - скорость. При переносе на уровень приложения загрузка системы замедлится. Если ты будешь оспаривать этот аргумент - значит ты плохо изучил ситуацию.
  • Who is online

    Users browsing this forum: No registered users and 3 guests