У меня есть консольный доступ к встроенному устройству Linux. Это устройство имеет флэш-память, часть которой разделена как файловая система FAT.
Он работает под управлением linux-2.6.31.
Однако в наши дни я вижу эти ошибки на консоли, и файловая система FAT становится доступной только для чтения.
111109:154925 FAT: Filesystem error (dev loop0)
111109:154925 fat_get_cluster: invalid cluster chain (i_pos 0)
111109:154925 FAT: Filesystem error (dev loop0)
111109:154925 fat_get_cluster: invalid cluster chain (i_pos 0)
Я не могу понять, почему это произошло? В чем основная причина? А что исправить? Я был бы признателен за ответы, которые укажут мне, как исследовать возможную первопричину этой проблемы на устройстве.
На самом деле на уровне битов и байтов произошло то, что 4 байта (или более) таблицы распределения файлов были перезаписаны 0x00
байтов.
Я кратко объясню, как работает таблица размещения файлов. Его можно рассматривать как массив, значения которого являются индексами того же массива. Итак, если мы знаем, что номер первого кластера файла i
, то следующий номер кластера fat[i]
, а следующее после этого - fat[fat[i]]
, и так далее. (Это немного упрощено). Чтобы сигнализировать о достижении конца цепочки, вместо действительного номера кластера используется специальное значение EOC.
Чтобы прочитать файл FAT с диска, вам нужны номера кластеров, в которых хранится файл, по порядку. Запись каталога дает номер первого кластера (i
). Остальные можно найти по цепочке fat[i]
, fat[fat[i]]
и т. д. до тех пор, пока не встретится значение EOC. Затем выполняется простой расчет, позволяющий получить положение каждого кластера на диске из номеров кластеров, прочитать каждый кластер в памяти и объединить их.
В fat_get_cluster: invalid cluster chain
происходит ошибка когда значение 0x00000000
находится следуя такой цепочке. Этого не должно происходить. Это должен быть новый действительный номер кластера или значение EOC. Когда это произойдет, больше нельзя будет прочитать файл, так как нет возможности продолжить цепочку. (The 0x00000000
значение используется, чтобы пометить кластер как свободный. Кластер 0
никогда не используется для хранения данных, поэтому нет двусмысленности)
Ваш случай может быть особенным, так как i_pos
дается как 0. Когда я получил это сообщение, это было большое число. Источник ядра говорит:
loff_t i_pos; /* on-disk position of directory entry or 0 */
Итак, i_pos - это не номер кластера, а позиция на диске. Что это значит, когда он нулевой, я не знаю.
РЕДАКТИРОВАТЬ: Что касается того, что могло быть причиной этого, я могу только предполагать, но вот некоторые возможности:
dd if=/dev/zero of=/dev/sda1 bs=512 count=1 seek=32
- не пробуйте это дома!)Драйверы файловой системы FAT фактически поддерживают в актуальном состоянии две таблицы FAT для избыточности, вторая - сразу после первого. Проверка, идентичны ли они, может дать ключ к разгадке того, что могло произойти. Если бы они отличались только значением, которое разрывает цепочку кластеров, я думаю, это сделало бы прямое вмешательство в той или иной форме более вероятным, поскольку как минимум 1 и 3 должны выполнять свою работу «правильно».
Однако мне кажется вероятным, что большинство современных драйверов будут хранить всю таблицу FAT в ОЗУ и записывать части, которые изменяются, обратно в обе копии на диске. Таким образом, даже если когда-то разница была, она могла быть быстро и незаметно «исправлена» при нормальном использовании. Обратите внимание, что это только обоснованное предположение.
В конце концов, очень трудно узнать с какой-либо уверенностью без дополнительной информации об обстоятельствах, и даже тогда это, скорее всего, предположения. Идеальные обстоятельства были бы, если бы вы могли надежно воссоздать проблему. Затем я бы сравнил таблицы FAT «до» и «после» (и заголовки FAT), чтобы точно увидеть, что и что было изменено, ища подсказки в размещении и содержании изменений.
Ваш FAT32 по какой-то причине поврежден. Моя USB-флешка часто заканчивается повреждением FS, потому что в настоящее время я отлаживаю проблему с USB-хостом на платформе ARM. После тестов я запускаю со своего настольного компьютера (Ubuntu 11.04) следующие команды:
$ sudo fsck.msdos -aw /dev/sdb1
Ссылка: https://askubuntu.com/questions/31614/how-to-delete-edit-files-from-readonly-filesystem
Ошибки, которые вы получаете неверная цепочка кластеров и ошибка файловой системы ясно показывает, что это ошибка файловой системы.
В Википедии о FAT говорится:
Раздел делится на кластеры одинакового размера, небольшие блоки непрерывного пространства. Размеры кластера различаются в зависимости от типа используемой файловой системы FAT и размера раздела, обычно размер кластера составляет от 2 до 32 кБ. Каждый файл может занимать один или несколько из этих кластеров в зависимости от его размера; таким образом, файл представлен цепочкой этих кластеров (называемых односвязным списком). Однако эти кластеры не обязательно хранятся рядом друг с другом на поверхности диска, а часто вместо этого фрагментированы по всей области данных.
В Таблица размещения файлов (FAT) - это список записей, которые сопоставляются каждому кластеру в разделе. Каждая запись записывает одну из пяти вещей:
- номер следующего кластера в цепочке
- запись о конце цепочки кластеров (EOC), которая указывает конец цепочки
- специальная запись, чтобы отметить плохой кластер
- ноль, чтобы отметить, что кластер не используется
это ссылка говорит, что кто-то решил аналогичную проблему с картой памяти с помощью fsck.