На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! правила раздела Алгоритмы
1. Помните, что название темы должно хоть как-то отражать ее содержимое (не создавайте темы с заголовком ПОМОГИТЕ, HELP и т.д.). Злоупотребление заглавными буквами в заголовках тем ЗАПРЕЩЕНО.
2. При создании темы постарайтесь, как можно более точно описать проблему, а не ограничиваться общими понятиями и определениями.
3. Приводимые фрагменты исходного кода старайтесь выделять тегами code.../code
4. Помните, чем подробнее Вы опишете свою проблему, тем быстрее получите вразумительный совет
5. Запрещено поднимать неактуальные темы (ПРИМЕР: запрещено отвечать на вопрос из серии "срочно надо", заданный в 2003 году)
6. И не забывайте о кнопочках TRANSLIT и РУССКАЯ КЛАВИАТУРА, если не можете писать в русской раскладке :)
Модераторы: Akina, shadeofgray
  
> файловая система #2
    привет :)
    я на днях поразмыслил. как вы думаете, имеет ли право на жизнь вот такая вот идея:
    вместо привычного (?) разделения "file_allocation_table + данные" сделать структуру вот какую - весь раздел состоит из небольшик блоков данных по 1-2 килобайта и по несолько байт (для каталогов), однако в начале каждого хранятся 2 32-битных числа и одно - 1 байт. первое - номер предыдущего в цепочке блока, второе - следующего. 0 - если такового нет. 3-е - типа блока - данные\инфо о записи (файле, каталоге)
    используя такую структуру, можно обойтись без таблицы размещения файлов: в самом первом блоке (маленьком) разместить инфо о корневом  каталоге - указатели на файлы\каталоги. в блоке, на который указывает ссылка из корневого блока - инфо о файле\каталоге (имя, типа, дата и проч.) + ссылка на первый блок данных. в первом блоке данных - ссылка на следующий и т.д.
    что-то вроде этого :)
    тогда можно будет легко вставлять дополнительные блоки в файл, вырезать их, удалять файлы - просто заменив ссылки. и, как мне кажется, более рационально использоваться место - не нужно хранить инфо о всех файлах\каталогах. получится что-то вроде дерева :) правда я пока только в общих чертах себе это представляю. из плюсов - удобно, из минусов - скорее всего понизится произодительность

    а каково ваше мнение? -)
    Сообщение отредактировано: DEiL -
      Так или иначе тебе придется хранить где-то инфо о всей файлоструктуре. Т.е. аналог ФАТ неизбежен. Потому, что представь, что приходит нечто и затирает первый блок (всего 1-2кБ!) на диске, благодаря чему вся инфа о диске исчезает форева. ;)
      Поэтому на дисках с FAT-16, FAT-32 есть две такие таблицы (одна запасная), наверное в NTFS, Ext тоже есть подобное.
        а мы это нечто не пустим :)

        во многих файловых системах сделано так - таблица представляет собой дерево, в каждом узле которого хранится ссылка на первый кластер файла. а далее просто блоки данных...
        а почему бы _всю_ структуру диска не превратить в дерево? тогда после каждого узла будет следовать ветвь, в которой содержится сам файл. что-то вроде:
                                                    "/"
                                        |--------|-------|
                                       usr        doc       a.txt - "this is a.txt!"
                                 |----|---|                           |
               "this is f1!" - f1    f2  dir1                         |
                      "and it is f2"-|     |-----|                  |
                                             dir2    b.txt ---------|

        по-моему клёво :)
        и можно будет легко делать ссылки на файл (b.txt -> a.txt)
        и если какой-нибудь засранец потрёт первый блок, то умная :) программа восстановления заметит, что у нас появилось три корневых ветви (usr, doc, a.txt), чего быть в принципе не может, и соединит их в одну :)

          _
          Сообщение отредактировано: fog -
          1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
          0 пользователей:


          Рейтинг@Mail.ru
          [ Script execution time: 0,0172 ]   [ 14 queries used ]   [ Generated: 20.05.24, 13:06 GMT ]