Каждый раз, когда пользуюсь либой FatFs думаю, что неплохо бы разобраться с тем, как все устроено внутри. Долго откладывал этот вопрос, наконец лед тронулся. Итак, глобальная цель это раскуривание карт памяти, если получится то детально, текущая цель разобраться с файловой системой.

Сразу скажу, у меня не было цели писать свой драйвер или детально разбираться в тонкостях, мне было просто интересно. Задача довольно простая для понимания, поэтому «кодов» здесь не будет.

Итак, первое что мы должны понять, при общении с картой памяти напрямую, мы можем либо прочитать, либо записать 512 байт, других действий не дано. Так как файлы мы постоянно что то копируем, удаляем, а размеры файлов всегда разные, то на карте будут образовываться пустые участки в перемешку с записанными. Чтобы пользователю не запариваться с размещением данных, существует прослойка которая берет на себя эти заботы, это и есть файловая система.

Как было уже выше сказано, записать и прочитать можно только кратно 512 байтам, т.е. 1 сектор. Также есть понятие — кластер это тупо несколько секторов, например если размер кластера 16кБ, то значит что в нем 16000/512 = 31.25, точнее 32 сектора, а реальный размер кластера 16384 байта. Все файлы занимают размер кратно размеру кластера. Даже если файл размером 1кБ, а кластер 16кБ, то файл будет занимать все 16кБ.

Логично было бы делать кластеры, маленького размера, то тут вступает в дело ограничение на максимальное количество файлов и на их размер. FAT16 оперирует 16 битными данными, поэтому нельзя запихать больше чем 2^16 кластеров. Поэтому чем меньше их размер, тем более эффективно используется место под мелкие файлы, но тем меньше информации можно запихать на диск. И наоборот, чем больше размер, тем больше информации можно впихать, но тем менее эффективно используется место под мелкие файлы. Максимальный размер кластера 64кБ, поэтому максимум для FAT16 64кб*2^16 = 4Гб.

Исходные данные: имеется карта памяти micro SD на 1Гб. Имеет метку MYDISK, отформатирована полностью, размер кластера 16кБ.
fdisk

Понадобится Hex редактор, но любой не подойдет, нужен такой, который может просматривать диск целиком, а не только файлы на диске. Из того что мне удалось найти: WinHex самый годный, но платный; HxD простой, бесплатный, но мне так и не удалось заставить его сохранять изменения на диске; DMDE — немного не user friendly, бесплатный и позволяет сохранить изменения. В общем я остановился на HxD.

Для начала стоит рассмотреть структуру FAT16, картинка показывает в каком порядке расположены различные части файловой системы.
fat16_struct

В загрузочном секторе хранится вся служебная информация. Внутри области FAT хранится инфорция о том, как расположены данные файлов на диске. В корневом каталоге информация о том, какие файлы есть в корне диска. Область данных содержит информацию содержащуюся внутри файлов. Все области строго следуют друг за другом подряд, т.е. после загрузочного сектора сразу начинается область FAT. Подробности рассмотрим ниже.

Задача: понять по какому принципу располагаются имена файлов и их содержимое. Поэтому начнем с поиска корневого каталога, чтобы понять какие файлы у нас есть в наличии. В этом нам помогут данные из загрузочной области.

boot_sector

Наиболее интересные данные указаны в таблице

Смещение Размер в байтах Описание
0x0D 1 количество секторов в кластере = 0x20 или 32
0x0E 2 количество зарезервированных секторов = 0x0004 или 4
0x10 1 0x02 количество таблиц FAT
0x11 2 0x0200*32 размер корневой директории
0x16 2 количество секторов для одной таблицы FAT = 0x00EE или 238
0x36 8 используется FAT16
0x1FE 2 0x55AA конец загрузочного сектора

Первое что нам нужно, это узнать размер загрузочной области. Смотрим адрес 0x0E и видим, что под загрузочную область выделено 4 сектора, т.е. с адреса 4*512 = 0x800 начинается область FAT.

Количество таблиц FAT можно определить по адресу 0x10 загрузочной области. В нашем примере их две, почему две, потому что каждая таблица дублируется резервной, что бы в случае сбоя можно было восстановить данные. Размер таблицы указан по адресу 0x16. Таким образом размер фата 512*2*0xEE = 0x3B800, а корневой каталог начинается с адреса: 0x800 + 0x3B800 = 0x3C000

Внутри корневого каталога все элементы разбиты по 32 байта. Первый элемент, это метка тома, а вот последующие элементы это файлы и папки. Если название файла начинается с 0xE5, то это значит что файл удален. Если название начинается с 0x00, то это значит, что предыдущий файл был последним.

Довольно интересная структура корневого каталога получилась у меня. Карта была отформатирована полностью, затем создано 2 текстовых файла, которые переименованы в MyFile.txt и BigFile.txt.
data_fat16

Как можно увидеть, что помимо моих двух файлов, создалось еще куча левых, о происхождении которых можно только догадываться.
root_dir

Самое важное, что можно здесь подчерпнуть, это адрес первого кластера, с которого начинаются данные нашего файла. Адрес всегда находится по смещению 0x1A. Например, имя нашего файла MyFile.txt расположено по адресу 0x3C100, к нему прибавляем 0x1A, там видим номер первого кластера. = 0x0002 т.е. второй кластер. Для файла BigFile.txt, данные начинаются с третьего кластера.

Также в корневом каталоге можно узнать еще дату и время, последнего редактирования файла, мне этот вопрос был не очень интересен, поэтому обойду его стороной. Последнее полезное, что может сказать корневой каталог, это свой размер, дабы мы могли найти то, откуда начинаются данные.

Размер указан в загрузочном секторе по адресу 0x11(2байта) = 0x0200*32 = 0x4000 или 16384 байт.

Прибавим к адресу корня его размер: 3С000 + 4000 = 40000 это адрес первого кластера данных, но нам нужен второй, чтобы найти MyFile.txt. Количество секторов в кластере 32, размер кластера = 32*512 = 16384 или 0x4000, поэтому прибавим к адресу первого кластера, его размер т.е. с 0x44000 по идее должен начаться второй кластер.

Идем по адресу 0x44000 и видим, что данные принадлежат BigFile.txt (в нем просто мусор)
cluster2

Оказывается есть небольшая тонкость, нумерация кластеров начинается со второго, не понятно зачем так сделано но факт, т.е. на самом деле мы перешли на третий кластер. Вернемся на один кластер назад на адрес 0x40000 и видим ожидаемые данные.
cluster1

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

Приведем пример, в файле BigFile.txt запихано куча рандомного мусора, чтобы занимал не один кластер, а несколько. Идем туда, где начинается таблица FAT и смотрим ее содержание.
fat16_table

Первые восемь байт 0xF8FFFFFF это идентификатор начала таблицы фат. Дальше идет 2 байта, которые относятся к MyFile.txt, то что в них записано 0xFFFF означает, что файл занимает всего один кластер. А вот следующий файл BigFile.txt начинается в третьем кластере, это мы помним из корневой директории, продолжается в четвертом, далее идет в 5,6,7… и заканчивается в 12, т.е. занимает 10 кластеров.

Проверим, действительно ли это так. Файл весить 163кБ, т.е. занимает 163000/(32*512) = 9.9 кластеров, что вполне походит на ожидаемое. Повторимся еще раз, что один элемент в таблице FAT занимает 2 байта, т.е. 16 бит, отсюда и пошло название FAT16. Соответственно максимальный адрес равен 0xFFFF, т.е. максимальный объем для FAT16 0xFFFF*размер кластера.

Перейдем к FAT32. Загрузочная часть немного изменена.
fat32_boot

Смещение Размер в байтах Описание
0x52 8 Имя файловой системы
0x24 4 Количество секторов занимаемых одной FAT
0x0E 2 количество резервных секторов
0x10 2 число таблиц FAT
0x0D 1 секторов в кластере
0x2C 4 номер первого кластера корневого каталога

Есть некоторые принципиальные изменения. Имя файловой системы перекочевало по адресу 0x52, размер корневого теперь игнорируется. Область данных находится сразу за таблицами FAT, корневой каталог находится внутри области данных. Кроме того корневой каталог не имеет фиксированного размера.

Адрес области данных вычисляется:
размер загрузочного сектора + таблицы FAT, в моем случае получилось:
746496 + (3821056 * 2) = 0x800000

Адрес корневого каталога вычисляется:
(номер первого кластера корневого каталога — 2) * размер кластера + адрес начала области данных,
т.е. в данном примере он будет совпадать с началом области данных.

Как и прежде данные в корневом занимают 32байта, как и прежде «удаленные» магические файлы, предполагаю это временные файлы блокнота.
root_fat32

А вот начало первого кластера в MYFILE.txt определяется теперь двумя байтами, старший по смещению 0x14, младший как и прежде 1A. Поэтому номер первого кластера данных для файла будет:
8000A0 + 0x14 = 0x8000B4 — старший байт
8000A0 + 0x1A = 0x8000BA — младший байт
В моем случае карта была всего с одним файлом, поэтому это третий кластер.

Таблица FAT ищется как и в предыдущем случае, только теперь элементы занимают 4 байта, отсюда и название FAT32. Идеология расположения элементов в точности как в предыдущем случае.
fat32_table

Полезняшки для таблицы
F8 FF FF F0 — первый кластер
FF FF FF 0F — последний кластер
FF FF FF F7 — поврежденный кластер

Где же находятся данные?
начало области данных + размер кластера * (номер кластера корневого — 1)
= 0x800000 + (2*4096) = 0x801000

Надеюсь в общих чертах стало понятно, вроде как ничего сверхестественного нет. Кто прочитал и повторил может скушать печеньку :)

4 комментария: Файловая система FAT

  • Там какая-то фишка и длинными именами, afaik. При создании нового файла венда создала файл типа «new text document.тхт», который больше чем 8.3. А это длинное имя записалось в volume label (Microsoft implemented support for LFNs in the FAT filesystem by using hidden directory entries—of the volume label type—to store the longer names; this scheme is known as VFAT, and it was chosen for compatibility, as volume labels are generally ignored by programs and operating system components.). Останки этих имен мы и наблюдаем, видимо.

  • Да похоже на то, просто этот момент как то вскользь везде упоминается, поэтому я решил тоже его не затрагивать

  • Почему в программе по адресу 0х0Е написано значение 04, по адресу 0х0F 00 соответственно 0400, а вы пишите 0х0004? Здесь запутался как располагаются байтики по адресам в памяти?

  • если число двухбайтное то справа налево, поэтому 0x04 младший байт, а 00 старший байт

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Последние комментарии
  • Загрузка...
Архивы
Счетчик
Яндекс.Метрика