| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Идеология проекта | |||
|
|||
 много критикиПерейти к странице Предыдущая -1-2-3 Следующая |
| Автор | Отправлено |
| Linker |
|
||
 
Сообщений - 12 |
Еще хотелось бы покритиковать 3OSFS. Извиняюсь, сразу, если чего-то не так понял из документации, я просто высказал свое мнение так, как я понял спецификацию ФС, поэтому не судите, если моя критика ошибочна. Базовой "элементарной" ячейкой для наивысшего уровня вложенности будет являться файл (см. рисунок), который будет состоять из трех секций: данных файла, описателя контента (содержимого) файла и реестра файла. Эти секции предполагается хранить в одном месте в виде "параллельных" цепочек данных. Причем в двух последних будет содержаться вся необходимая информация о параметрах и типе внутренних и внешних связей файла. Ну файл наврядли можно назвать элементарным, сектор - вот элементарный и неделимый элемент. Зачем все так усложнять, зачем менеджеру фс знать о типе файла, тем более зачем ему знать о содержимом файла. Задачи менеджера фс - предоставить сервисы для работы с файлами: открыть, закрыть, создать, удалить, читать, записать, установить аттрибуты, установить дату создания и т.д. Ваша фс очень похожа на будущую WinFS, да это кульно работать с файлами как с базой данных, но извините, скорость работы упадет на порядок. По поводу контента, будет очень сложно с анализом, это хорошо если на диске нет ничего кроме тестовиков, бмпэшек и авишек, да их легко определить и составить описание контента, но посмотрите на диск, большую его часть занимают далеко не текстовые файлы или картинки, а файлы со структурой придуманной разработчиками стороннего ПО, а там и текст и белеберда и все что угодно. А значит по вашей спецификации описателем контента будет поток байтов и смысла все усложнять нету. Может я не так что-то понимаю. Данные файла, в зависимости от их содержания, могут быть представлены несколькими уровнями вложенности. Так, например, текстовый файл может состоять из страниц, абзацев, строк и символов ('токенов'). Графический - из заголовка, потока данных, 'токенов', и т.д. Причем, для текстового файла в этом случае 'токеном' будут служить 2 байта Unicode, а для графического файла BMP - 3 байта RGB. Зачем фс знать о таких элементах, как строка, абзац? Зачем ей знать о форматах файлов? Например, 24-х битные BMP не имеют таблицы RGB. Для обеспечения быстрого доступа к данным, все необходимые сведения о файлах сводятся в единую файловую таблицу Я считаю это заблуждением, т.к. по части скорости, подобная таблица будет достаточно громадной, правда завист от размеров каждой из записи. Хранить такую таблицу в памяти достаточно проблематично, кэшировать только по частям, тогда понадобится обращение к диску, а это уже замедляет. Хотя я не против таких таблиц, они действительно ускоряют, но при малых размерах каждой из записи в ней. И не стоит такой массив данных использовать в качестве основного элемента для доступа к файлам, порушится такая таблица и усе. Но вас кажется это не касается, судя по имеющимся полям "описатель контента" и "реестр", но опять же, получается некое подобие единого хранилища, а это по моему не есть гуд, почему см. ниже. Реестр файла - содержит информацию, регистрирующую файл (программу) в системе 3OS. Также, реестр файла хранит информацию о параметрах файла, которые не смогли уместиться в таблице файлов (например, в случае, когда файл имеет слишком длинное имя, оно повторяется в начале реестра). А поподробнее, что это за регистрационная информация? Имена файлов лучше ограничивать длинною в 256 байт - обычная 8-разрядная строка, этого достаточно. На основе данных взятых из описателя контента система формирует представление о содержимом файла. Описатель контента имеет вполне конкретный формат и состоит из двух секций: первая - список классов используемых при обработке файла; вторая - индивидуальное дерево классов файла. Кошмар!!!!!!!! А если это не четыре абзатца, а целая диссертация выпускника аспирантуры???????? Я сочувствую, скока придется ждать, прежде чем менеджер фс составить описание контента. Следует отметить, что такие операции как дефрагментация, проверка и форматирование раздела файловой системы, проводятся самим драйвером и недоступны для пользовательских приложений. Во-первых, я бы выбрал другое именование, не драйвер, а менеджер. Если планируется совместить драйвер диска и менеджер в единое целое, то это мо моему глупо. Хе-х, а какже менеждер фс узнает, что пора форматировать или дефрагментировать? Пойдет запрос от пользователя на операцию форматирования, система обработает сообщение, увидит, что источником является приложение пользователя и отвергнет его. Лучше если подобные операции (проверка, форматирование, дефрагментация) будут производить привелигированные приложения, запушенные от привелигированного пользователя, это избавит менеджер фс от лишнего кода. Т.е. если стандартная цепочка: диск->драйвер диска->менеджер фс->приложение, то при выполнении таких операций цепочка становится короче: диск->драйвер диска->приложение. Безопасность от этого НИКАК не страдает. Если же это обращение приложения к файловой системе, то оно помещается в стек входящих сообщений Стэк, надеюсь это только именование, а не настоящий стэк, т.к. концепция стэка - "последним пришел - первым ушел", т.е. при достаточно частых запросах, существует вероятность, что самые первые сообщения очень и очень долго не будут обработаны. Выполнять запросы необходимо в поступающей последовательности, иначе получиться белеберда, похуже простоя запросов. Т.е. длинну полной информации о файле мы предсказать не можем, т.к. не знаем четкой длинны имени файла. Это очень плохо, очень плохо, все эти динамические поля ухудшают производительность, т.к. требуют дополнительных записей, обращений к ним, хоть это в некоторой степени и экономит память, но что значат 32 и 256 байт, по сравнению с 128 мегабайтами и более. Лучше по возможности жестко фиксировать размеры, это сэкономит код, а значит и производительность выше и меньше ошибок. запись в кэше может содержать еще и реестр и описатель контента, если они имеют достаточно маленькитй размер (порядка 200байт). Сомневаюсь, что описатель контента сможет уместиться в 200 байт, например, упомянутая RGB - 256 записей по 3 байта. DML - новый язык для работы с объектами данных, интегрированный в драйвер файловой системы. Вы хотели сделать быструю файловую систему, но чувствую этого не случиться, сама ОС работает как интерпретатор, да еще и менеджер фс тоже что-то пытается интерпретировать. Надежность хранения обеспечивается возможностью восстановления таблицы файлов при ее крахе. Записи о файлах могут быть восстановлены по записям которые храняться вначале блока. Единственное что мы теряем оригинальные имена файлов и некотрые атрибуты. А где надежность? Уже теряется достаточно важная и критическая (аттрибуты) информация. По информации лежащей в начале блока мы можем установить: длинну файла, цепочки кластеров данных файла (реестра, описателя контента), его положение в таблице файлов (идентификационный номер). Это все хорошо, но порушился подобный блок, что делать, цепочки кластеров утеряны, все труба, собирать файл в ручную - полный геммор. Пока существуют всякие цепочки, массивы данных, фс не является надежной. Чтобы хоть как-то обезопасить данные, можно использовать операции ввиде транзакций (модель менеджера фс QNX), любой сбой приведет к отмене транзакции, а следовательно данные восстановятся в первоначальном виде. Правда любую фс не спасет физическое повреждение диска (bad blocks). Так же для повышения надежности мы можем использовать зеркалирование FS. Актуально для аппаратных рэйд-массивов, с возможностью зеркалирования, программный путь - уменьшит производительность в двое и более. Ну и немного пройдемся по формату раздела: 1. Идентификатор раздела, зачем так много, достаточно 2-х байт, ну максимум 4 байта (поместится в 32-х разрядный регистр), этого достаточно чтобы идентифицировать раздел. 2. Размер блока, 4000 чего? Вот и все. Мои выводы не утешительны. |
||
| Наверх |
|
| Linker |
|
||
|
Сообщений - 12 |
Отвечаю на вопрос Dreamer'a: Работает же Линух, на других архитектурах? Работает! Однако он не представляет собой виртуальную машину, или QNX - где устанавливаются только те компоненты, которые необходимы для конкретной архитектуры. По моему разумению, переписать один из компонентов проще, нежели переписывать виртуальную машину. |
||
| Наверх |
|
| Linker |
|
||
|
Сообщений - 12 |
А кто-нибудь прокомментирует мой пост? Просто интересно, редко когда разработчики ОС создают свою ФС, обычно опираются либо на FAT, либо на ext2. Так ли я понял документацию, вот в чем вопрос, если нет, то плиз прокомментируйте. | ||
| Наверх |
|
| Roman I Khimov |
|
||
 Местоположение: Россия, Санкт-Петербург Сообщений - 178 |
Linker, процитированный Вами документ порядком устарел. Хотя многие идеи высказанные в нем живы.
Греби и улыбайся!
|
||
| Наверх |
|
| Neitron |
|
||
Сообщений - 4 |
Я бы использовал изначально файловую систему ext3, но не базировался бы на ней. Зделайте как Товальдс виртуальную фс подрубать другие фс будет легче. |
||
| Наверх |
|
| Neitron |
|
||
|
Сообщений - 4 |
А теперь к критике, вы работаете на сколько я понимаю уже 2 года, да я понимаю все расписали и довольны, но результатов я не вижу, сам думаю о написании операционки, тока мозги не доходят, ищу документацию по фс, загрузке и другим вещам, пока к нормальному результату не пришел, копаюсь 2 месяца. | ||
| Наверх |
|
| indigo |
|
||
|
Сообщений - 4 |
я в одном из форумов внес вопрос о 2 различных фс... я конечно не настаиваю но подумайте.... Ведь представлять всю хранимую информацию как БД имеет смысл тока для документов пользователей - так действительно удобней хранить и работать с ними.. А вот например зачем это например конфигурационным или исполняемым файлам (или обьектам как вы их называете)? | ||
| Наверх |
|
| HandleX |
|
||
Сообщений - 18 |
Тут вот Indigo спрашивает, зачем хранить исполняемые файлы как объекты. А затем, что... К примеру, посмотрите на формат PE32. Типичный объектный формат, структурированный, древовидный... Ну и зачем его хранить в "плоском" виде? А сколько гемора возникает, когда нужно модифицировать такой файл? К примеру, ресурс (иконку) заменить или "вытащить"? Сколько народу свой бобос поимело, только из-за того, что "разобрались" с этим форматом и выпустили в свет платные проги вроде PE32 Explorer, Restorator и т.п.? IMHO, PE32 мало отличается по сложности от того же документа Word. Те же persistent objects, вываленные в плоский файл данных. Основной принцип систем - "не плодить новых сущностей" и "всё едино". Так что есть повод для размышлений. Удачи всем! |
||
| Наверх |
|
| Freeman |
|
||
 
Местоположение: Зеленоград, Россия Сообщений - 74 |
indigo писал(а): ... А вот например зачем это например конфигурационным или исполняемым файлам (или обьектам как вы их называете)? Хотя бы затем, чтобы можно было дать запрос, и вытащить все данные, относящиеся к той или иной программе. При такой возможности написание деинсталлятора не представляло бы никакого труда. Точнее, такого класса программ вообще не было бы, если все делается одним запросом  Например, была бы такая функция в Винде - продвинутые пользователи забыли бы даже слово "переустановка". [ Редактирование четверг 19.08.2004 08:57 ] |
||
| Наверх |
|
| Linker |
|
||
|
Сообщений - 12 |
HandleX писал(а): ... А затем, что... К примеру, посмотрите на формат PE32. Типичный объектный формат, структурированный, древовидный... Ну и зачем его хранить в "плоском" виде? Маразм. Не обижайтесь, но это действительно маразм. По большей части, файло, которое лежит на харде, это далеко не exe, txt, doc, поэтому смысла представления фс, как объектной базы данных, я не вижу. Я просто не понимаю, зачем менеджеру файловой системы знать о форматах файлов. Формат файла важен для программы, которая с ним работает, так же как, например, драйверу видеокарты не надо знать о всяких окнах, кнопках и т.п. Зайдем с другой стороны, даже если PE32 объектный, значит он уже хранит в себе все необходимое для доступа к своим объектам, дык зачем на уровне фс знать и интерпретировать их? Пускай этим занимается тот модуль, который будет с этим файлом работать, например, менеджер процессов, запускающий этот файл на выполнение. Или вордовый документ, пускай его интерпретирует та программа, которая его откроет, зачем делать одинаковые действия на уровне фс и процессов. Или ваша цель зашить в менеджер фс знания обо всех существующих форматах? Это еще один маразм. Повторюсь, не надо делать из каждого модуля ОС всезнайку, пускай все занимаются только своим делом, сказано менеджеру фс открыть файлом, пускай выполняет и не пытается понять формата открываемого файла, сказано менеджеру окон создать окно, пускай создает и пускай не пытается понять, каким образом пикселы на экран выводятся. Все это только упростит задачу, а значит ускорит. Вообщем мое мнение, все эти симуляции, интерпретации, избыточный анализ и т.п. прилично тормозят систему и ничего быстрого, безопасного, надежного из этого не выйдет никогда. |
||
| Наверх |
|
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |