Разъяснить (разжевать) задание. Программа моделирования работы файловой системы

[RAZOR1703]

Привет всем. Хочу сразу сказать: я ни в коем случае не прошу написать мне программу. Есть задание по курсовому, есть, собственно, несколько вопросов по заданию. Преподавателя-руководителя, мягко говоря, невозможно выцепить, чтобы объяснил. Посему вся надежда на вас, форумчане.
Поехали.
Разработать программу, которая моделирует работу файловой подсистемы. Дисковое устройство должно выглядеть как массив блоков одинаковой длины (размер блока выбрать самостоятельно). Файлами считать абстрактные структуры, предназначенные только для моделирования. Для сохранения информации про файлы использовать только корневой каталог (отдельная структура, которая не входит в дисковое пространство). Предусмотреть возможность создания, удаления и изменения размеров файлов в интерактивном режиме работы программы. Размер одного файла не должен превышать 10 блоков. Определить необходимые поля записей корневого каталога, структуры учета блоков согласно с заданием - физическая организация файла - непрерывная, структура учета - карта памяти. Результаты работы программы (состояние корневого каталога, блоков на диске, структуры учета свободных и занятых блоков) отображать в графическом режиме.
Собственно, вопросы. По ходу дела, будут возникать новые.
1. Как реализовать это самое дисковое устройство и как оно должно выглядеть (ответ из условия не принимается )?
2. Собственно, что за корневой каталог?
3. Если структура файла - непрерывная, значит ли это что можно не учитывать возможность фрагментации?
4. Что значит структура учета - карта памяти?
И вообще, ребята, если вам не трудно, распишите, как можно подробнее, как бы вы это реализовывали сами.
Если кто-то может посоветовать литературу/статьи/все, что угодно по данной теме - я буду более, чем рад вашим рекомендациям.
Спасибо.

[Stilet]

Как реализовать это самое дисковое устройство

Ну например это файл, имеющий некую структуру типа:

struc fs {
 char* data
 char* namefile
}

Т.е. допустим ты создаешь файл. Размещаешь в памяти указатель на эту стркутуру, задаешь имя файла, и часть данных пишешь в полe data.

Собственно, что за корневой каталог?

Это файл содержащий в себе массив fs структур, которые будут описывать твои "диски".

Если структура файла - непрерывная, значит ли это что можно не учитывать возможность фрагментации?

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

Что значит структура учета - карта памяти?

Ну ты хранишь в отдельной переменной список с адресами структур fs каждого файла, чтоб можно было быстро к ним добраться. В этой же структуре их размеры можно хранить - это называется каталогами.

как бы вы это реализовывали сами.

Я бы доверился Ораклу, Сиквелу, файерберду... Любой из существующих СУБД.

[RAZOR1703]

Спасибо, что откликнулся на зов
И сходу вопрос: можешь посоветовать какого-нибудь чтива по данной теме, чтобы свести количество глупых вопросов с моей стороны к минимуму?
Разъясни, пожалуйста, поподробнее, о взаимоотношениях этого самого дискового устройства, блоков и файлов, которые мы будем записывать.

фрагментация будет обязательно

В таком случае, что значит - структура файла - непрерывная?

Я бы доверился Ораклу, Сиквелу, файерберду... Любой из существующих СУБД

И вот здесь, пожалуйста, поподробнее, ибо все, что знаю о базах данных - это прошлогодний курс по Access, который являл собой больше введение в тему СУБД.

[Stilet]

И сходу вопрос:

Сходу ответ - нет.

поподробнее, о взаимоотношениях

Это одним словом не опишешь. Но все это можно реализовать динамическими списками. Теми самыми. что втирают преподаватели в моск студентов. Правда в этом случае все будет чуть посложнее, и пожалуй стоит работать с классами.
Со списками то умеешь работать?

что значит - структура файла - непрерывная?

Все что угодно. Предположительно - все байты файла попадают в один и тот же массив. Да, файл сам не фрагментируется, фрагментируется место в системе после множественных удалений и внесений. В ней появляются дырки, что не оч хорошо, хотя и допустимо.

И вот здесь, пожалуйста, поподробнее

А че тут говорить? Я тебе предлагаю вместо разработки своей системы опереться на СУБД. Тупо хранить в ней - пусть сама разбирается как записывать в устройстве твои файлы. Правда придется продумать структуру базы - далеко не все СУБД иерархические. Кстати я бы выбрал для иерархического складирования данных Cashe. Он как раз подходит. Однако думаю твоему преподу врядли понравится такой вариант. Уверен что он заставит тебя писать свое вместо того чтоб воспользоваться благами человечества.

[RAZOR1703]

Так, я вернулся. Люблю своего провайдера.
В общем, подчитал я немного литературы (все еще в прогрессе). Уяснилось несколько вопросов, появилась пара идей. Сейчас попробую изложить.
Касательно структура файла - непрерывная. Имеется ввиду просто массив блоков одинаковой длины, в который файлы, занимающие n-ное количество блоков, записываются сначала в конец, а потом, если были удалены какие-либо файлы в середине и если размер освободившейся области подходящий, то пишутся именно туда. А чтобы избежать фрагментации можно будет просто предусмотреть большую, красную кнопку под названием "дефрагментация".

Правда в этом случае все будет чуть посложнее, и пожалуй стоит работать с классами.

Ну, я, в общем-то, так себе это и представлял - сделать файлы объектами класса, а дисковое устройство - как массив объектов, только не совсем понятно в этом случае - как учитывать свободное место между файлами. Да и вообще, как мне кажется, не очень правильно это. Здесь, видимо, списки как раз и понадобятся, хотя в этом случае я не знаю, как их прилепить сюда.

Со списками то умеешь работать?

Приходилось как-то. Правда, я от них не в восторге, помнится, был Хотя если для дела будет нужно - могу и полюбить.
Пока что я не совсем вижу связь "массив блоков - файл". Каким способом это можно реализовать?

[RAZOR1703]

Попал-таки к преподавателю, уточнил еще пару деталей. Под структура учета - карта памяти имеется ввиду использование бит-карты - массива битов, каждый из которого соответствует блоку дискового устройства. В зависимости от состояния - занят или свободен - его элементы принимают значения 1 и 0 соответственно. Используется для ускорения подсчета свободной памяти и занятых блоков.
В связи с вновь открывшимися обстоятельствами, я тут прикинул схему, как это все выглядеть, по идее, должно. Просьба проверить, верно ли я все понимаю.
За Пэйнт не бейте

В случае, если все правильно, объясните пожалуйста, каким образом реализовать это самое дисковое устройство и, если у меня файлы являются абстрактными структурами и не записывают фактических данных - зачем оно мне вообще нужно? Нельзя ли обойтись только бит-картой? И как отделить данные от прочей информации, идущей в корневой каталог?

[RAZOR1703]

Есть у кого-нибудь какие-нибудь мысли по этому поводу?