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

Kernel architecture questions
  • Mario79
    > В Линукс давно используют автомонтирование.

    Ну не совсем. Монтирование работает на уровне ядра, но только через /etc/fstab.
    Просто при инстале системы формируется этот самый fstab.
    Другое дело removable drives. Там другая система и работает она уже не при старте системы, это делает специальный демон.

    Так что я с тобой соглашусь:) Да и тем более это наброски были, я не предлагаю системе работать именно так!
  • Gluk

    А что толку всё время знать? Подавляющему большинству это нафиг не надо. Вот у меня устройства c: d: e: g: j: k: Windows Commander сразу показывает g:-CDROM, k:-Removable disk. "Мой компьютер" тоже. Ну и что с того что я буду знать где какой диск и где какой раздел ? Только лишние буквы печатать. Если уж на то пошло намного полезнее знать где какая файловая система. Потому что на ntfs нельзя писать, а ext2 и т.п. вообще не видны. Наконец в Линуксе /hd0/1/ смонтирован как /windows. Получается как хочешь так и называй, только не форматируй :)

    Вообще я за то чтобы были альясы типа c1 - hd0/1, c2 - hd0/2 d1 - hd1/1 и т.д. Конечно это немного усложнит разбор пути, но по-моему здесь надо обязательно сохранить обратную совместимость.
  • k@sTIg@r wrote:Разговор о том, стоит ли абстрагировать работу с файлами, файловую систему и интерфейс работы с у-вом.
    Да ну? В желательности абстрагирования (кода поддержки файловой системы от кода работы с устройствами) никто не сомневается. Жаркие споры идут про пути к устройствам - некоторые стоят за сохранение текущей схемы именования (я в их числе), некоторые против.
    Ушёл к умным, знающим и культурным людям.
  • > А теперь ответь, зачем это рядовому пользователю? Насколько я таких знаю /hd1/ /hd2/ им понятней, потому что проще. А то что диски не по порядку идут, могут даже панику вызвать - /hd1/ /hd3/, "а где же /hd2/???"

    Вопрос в том что если название устройства будет формироваться относительно его физической и логической природы (hda1, hda2, hdb1), то при добавлении нового устройства в систему, имена уже существующих не изменятся и ты без проблем найдешь один из своих дисков. Проблема возникнет если ты перенесешь содержимое диска на другой раздел или просто переставишь диск. Для решения этой проблемы все же нужно использовать "виртуальные" имена, но при этом нужно контролировать (в какой-то степени вручную) на какие устройства будут разрешаться эти имена:
    • hda1 -> C
    • hda2 -> D
    • hdb1 -> E
    Для этого я бы предложил не заменять текущую файловую систему, имеется ввиду представление имен разделов, а создать отдельную, виртуальную. Через новый набор функций ядра или через сервис уровня пользователя. Тогда таблица разыменования в виртуальную ФС может выглядеть так:
    • /rd/1 -> /sys
    • /fd/1 -> /floppy1
    • /hd0/1 -> /programs
    Еще раз обращаю внимание, на то что устройства слева растут из другого корня, нежели устройства справа, в приведенном списке. Справа фактически не устройства, а виртуальные директории, но это уже тонкости терминологии. Ениственное но, часть имен все же должно быть стандартизовано. Если у всех пользователей будут одинаковые имена "устройств" в системе, то им будет проще объяснить, что где лежит и для чего это нужно.

    > Мнение пишущего код программиста всегда приоритетнее остальных.
    diamond, можно я буду тебя цитировать :-) ?

    ..bw
  • Serge>но по-моему здесь надо обязательно сохранить обратную совместимость.
    diamond>некоторые стоят за сохранение текущей схемы именования (я в их числе), некоторые против.
    bw>Для этого я бы предложил не заменять текущую файловую систему, имеется ввиду представление имен разделов, а создать отдельную, виртуальную.

    Ога! Тогда такое решение(что-то похожое на bw).
    У нас уже есть набор ф-ций для работы с файловой системой. При переделке дисковой подсистемы, старые ф-ции логически не изменятся. Изменится только код, логика останется та же. Т.е. также происходит чтение файла, используются такие же пути. А для новой подсистемы добавятся новые функции, которые будут работать по новой схеме. И волки сыты и офцы целы. Хотя может что не доглядел.
    Может быть постепенно какая-нибудь из подсистем вымрет :)
  • bw wrote:> Мнение пишущего код программиста всегда приоритетнее остальных.
    diamond, можно я буду тебя цитировать :-) ?
    Можно, конечно :-) Только не увлекайся, а то если программист пишет явный бред, то другие тоже могут вспомнить, что они сами умеют писать код :-)
    Serge wrote:А что толку всё время знать? Подавляющему большинству это нафиг не надо.
    А вот в настройках Total Commander ("Операции->Операции с файлами") есть специальное поле "Следующие логические диски находятся на одном жёстком диске (например: CDE,FGH):" То есть Total Commander не может это определять сам, но считает такое знание полезным.
    Ушёл к умным, знающим и культурным людям.
  • Total Commander не может это определять сам, но считает такое знание полезным
    То есть это полезно для Total Commander (возможно для оптимизации многопоточного доступа к дискам) и для тех кто в этом разбирается. Плохо что Win не даёт такой информации.

    Мой сосед типичный "непродвинутый" юзер. Иногда играет на компе. Его жена распечатывает накладные и работает с почтой. Три года они работали в "Проводнике", потом я для удобства поставил им Commander.
    Для них все эти физические устройства и логические разделы абсолютный тёмный лес. Я подозреваю что таких пользователей абсолютное большинство. И им досовская система имён может быть даже удобней чем информативная Колибри.
  • Мне более понятно как сейчас утроена система:
    т.е. hd0/1/
    hd1/1/
    hd1/2/ ....
    В виндовс часто наблюдал картину, как после перестановки ОС, вдруг D диск становиться E и т.д.
    То что все привыкли к С,D,E,F и т.д., не должно быть приоритетней здравой логики, можно переучиться ИМХО это дело привычки.
  • Serge wrote:И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?
    А в чём проблема?
    Дискеты обозначаются /fd/1, /fd/2
    usb-носители можно обозначать /usb/1, /usb/2, ...
    сетевые диски - /net/1, /net/2, ...
    примонтированные образы - /mounted/1, /mounted/2, ...
    k@sTIg@r wrote:У нас уже есть набор ф-ций для работы с файловой системой. При переделке дисковой подсистемы, старые ф-ции логически не изменятся. Изменится только код, логика останется та же. Т.е. также происходит чтение файла, используются такие же пути. А для новой подсистемы добавятся новые функции, которые будут работать по новой схеме. И волки сыты и офцы целы. Хотя может что не доглядел.
    Может быть постепенно какая-нибудь из подсистем вымрет
    Не понял, какие "новые функции"?
    Если функция чтения принимает пути типа "/hdx/y/...", а функция, скажем, получения метки диска требует путей совершенно другого типа, это маразм.
    Ушёл к умным, знающим и культурным людям.
  • Мне более понятно как сейчас утроена система:
    т.е. hd0/1/
    hd1/1/
    hd1/2/ ....
    В виндовс часто наблюдал картину, как после перестановки ОС, вдруг D диск становиться E и т.д.
    То что все привыкли к С,D,E,F и т.д., не должно быть приоритетней здравой логики, можно переучиться ИМХО это дело привычки.
    Первое - лишний уровень иерархии. Второе - плохо что дискам и разделам невозможно присвоить какие-либо псевдонимы - это усложняет конфигурирование системы, но зато позволяет облегчить проблемы, связанные с изменением физического порядка следования дисков (например, когда диски физически меняют местами), в случае использования программами полных имен файлов и каталогов. Второе кстати частично имеет место и в Windows. В маках, например, в качестве имени раздела выступает метка раздела, т.е. имя раздела хранится в самом разделе. При таком подходе даже конфигурацию править не нужно. Здесь также следует сказать, что пространство физических имен дисков и разделов следует отделить от пространства имен объектов файловой системы, через которые происходит доступ к данным на этих дисках и разделах на логическом уровне. Конечно в никсах имена устройств тоже являются частью файловой системы, но это только потому, что там вообще много чего делается через файловую систему. Главное, вы же не ищете к примеру объект sda1, чтобы прочитать с этого раздела файлы. Не нужно также смешивать понятие файловой системы и устройства, на котором эта файловая система находится. Ну не должен драйвер устройства отвечать за логическую структуру информации, которая на этом устройстве хранится. Хотя конечно драйвер устройства и драйвер одной или нескольких файловых систем могут находиться в одном программном модуле. Имена вида hd0 по-моему должны присутствовать в файловой системе либо когда пользователь явно их задаст в качестве имен объектов для лог. доступа, либо в крайнем случае когда в процессе автоконфигурирования нужен доступ к данным на вновь обнаруженных устройствах на логическом уровне.
  • Мне представляется, что драйверу устройства вообще фиолетово, какие имена используются в системе. Драйвер устройства должен уметь исполнять запросы типа "прочитать/записать такие-то секторы", "узнать параметры устройства", а конкретные имена устройств назначаются на более высоких уровнях иерархии.
    Запихивать в один модуль драйвер устройства и драйвер файловой системы не имеет никакого смысла.
    Ушёл к умным, знающим и культурным людям.
  • Мне представляется, что драйверу устройства вообще фиолетово, какие имена используются в системе. Драйвер устройства должен уметь исполнять запросы типа "прочитать/записать такие-то секторы", "узнать параметры устройства", а конкретные имена устройств назначаются на более высоких уровнях иерархии.
    В большинстве операционных систем драверы устройств оперируют именами устройств - фактически через имена происходит доступ к их функциям с более высоких уровней.
    Запихивать в один модуль драйвер устройства и драйвер файловой системы не имеет никакого смысла.
    Ты прав, особой необходимости обычно нет, но смысл все-таки есть, например, можно собрать в одном модуле драйвер жесткого диска и драйверы наиболее распространенных файловых систем именно для жесткого диска. Хотя логичнее всего это сделать для тех устройств и ФС, которые практически всегда однозначно связаны друг с другом.
  • diamond wrote:Не понял, какие "новые функции"?
    Если функция чтения принимает пути типа "/hdx/y/...", а функция, скажем, получения метки диска требует путей совершенно другого типа, это маразм.
    Не так понял. При такой системе придется поменять и функции для работы с файлами (не спрашивай зачем).
    Так вот я предлагаю старые оставить для совместимости. По старой системе диск будет определятся по первым 2-м уровням пути, в моей по монтируемому имени и т.д.
    Я так понял вы не любите глобальные изменения, поэтому останется совместимость. Это будет тестовое ядро. Поработаем вместе на нем и посмотрим что окажется лучше и удобней.

    ЗЫ. Может все таки сведем к 1-му уровню? ну маразм получается /hd1/1 /net/1 /usb/1, не ужели вы так не считаете? Это не удобно, вы просто привыкли. Если б изначально в минуэте было /hda1/ /cd1/ и т.п. а кто-то кричал про /hd1/1/, получилось бы тоже самое. К аргуметам добавился б еще и "нафиг 2 уровня, с одним быстрее и удобней".
    Кстати затрону вашу больную тему. Таким образом(не монтируемые имена, а 1 уровень) на каждый путь тратиться на 1 байт меньше :) А я думаю на рамдиске они не редко встречаются ;)
  • Так вот я предлагаю старые оставить для совместимости. По старой системе диск будет определятся по первым 2-м уровням пути, в моей по монтируемому имени и т.д.
    Я так понял вы не любите глобальные изменения, поэтому останется совместимость. Это будет тестовое ядро. Поработаем вместе на нем и посмотрим что окажется лучше и удобней.
    Если файловые менеджеры будут показывать старые пути, то не совсем понятно, для чего нужны новые пути - всё-таки большинство операций делается через файловые менеджеры. А если файловые менеджеры будут показывать новые пути, то они сойдут с ума. Все три.
    на каждый путь тратиться на 1 байт меньше А я думаю на рамдиске они не редко встречаются
    Мимо :twisted: Или, по крайней мере, сильно запоздало :twisted: SPraid заменил во всех программах /rd/1 на /sys, а явно прописанных путей на жёстких дисках нет.
    Ушёл к умным, знающим и культурным людям.
  • Who is online

    Users browsing this forum: No registered users and 4 guests