Как посмотреть файловую систему на андроиде
Содержание
Файловая система представляет собой своего рода структуру того или иного накопителя. Она отвечает за то, какой максимальный объем файла можно сохранить в памяти, длину их названий, а также за организацию циклов записи или чтения. Файловые системы выступают в роли посредников между программным кодом и физическим вместилищем.
Для разных операционных систем и типов устройств существуют отдельные ФС и гаджеты на ОС Android, не являются исключением. Давайте разберемся, какие файловые системы поддерживает Android и для каких целей используется каждая из них?
Файловые системы Android
1. Yaffs и Yaffs2
Создателем файловой системы Yaffs (Yet Another Flash File System) является Чарльз Мэннинг, родом из Новой Зеландии. Данная ФС предназначается для организации работы флеш-накопителей и оперативной памяти. Основным ее преимуществом является повышение сроков эксплуатации модулей памяти, так как система автоматически пропускает ячейки, предназначенный для однократной записи. Yaffs2 использовалась для организации работы внутренней памяти гаджетов Android версии 2.2 и 2.3.
2. VFAT
Vfat не является полноценной самостоятельной файловой системой, а представляет собой расширение FAT. Доработанная версия позволяет сохранять файлы с длинными именами, но по всем остальным характеристикам является морально устаревшей. Vfat может использоваться на картах памяти, а операционные системы на базе ОС Андроид полностью их поддерживают. В основном, это файловая система флешки android.
3. F2FS
F2FS (Flash Friendly File System) – файловая система, которая предназначена в первую очередь на работу с флеш-памятью и SSD-накопителями. Разработал ее сотрудник компании Samsung, Ким Чэ Гык, а после публикации исходного кода она была доработана другими инженерами компании. F2FS может использоваться на картах памяти SD/MMC, а также со множеством других типов памяти. Для полноценной кастомизации существует целый набор утилит. Из преимуществ можно отметить хорошую гибкость в настройке, высокие показатели сохранения жизненного цикла блоков памяти, а также хранение данных в виде журнала. Хорошую скорость работы обеспечивает то, что индексы данных сохраняются в оперативную память, а поддержка F2FS включена в ядро Linux, начиная с версии 3.8.
4. Ext2-Ext4
Ext2-Ext4 – основные файловые системы Android. Именно они используются для организации работы внутреннего хранилища на большинстве современных гаджетов, и если первые устройства работали под версиями Ext2, то начиная с версии Android 4, основными стали Ext3, а потом и Ext4. Основное отличие между вариациями заключается в наличие журналирования. То есть, если в процессе записи или чтения данных происходит системный сбой, например, неожиданное отключение питания, не произойдет потери или повреждения данных. Несмотря на то, что в основном ФС формата Ext используется в основном в блочных накопителях, пользователи могут установить данный тип и для карт памяти, но без сторонних утилит получить к ним доступ из операционных систем, помимо Linux, будет невозможно. Файловая система флэшки Android обычно форматируются в FAT (VFAT) или NTFS, а флеш-память — в Ext3 или Ext4.
5. UBIFS
mSATA SSD 16 GB Sandisk — SDSA3DD-016G
UBIFS – файловая система, предназначенная исключительно для памяти по типу NAND (флеш-накопители, применяемые на мобильных устройствах). Ее основное преимущество — это снижение износа носителей данных. Состоит такая ФС из двух слоев — UBI (отвечает за работу и связь с физическим носителем) и UBIFS (сама файловая система). Разработчиком UBIFS является компания Nokia, но встретить подобную файловую систему можно не только на оригинальных устройствах от данного производителя, но и на других гаджетах, например, китайского изготовления.
6. Samsung RFS
Samsung RFS – разработанная корейской компанией Samsung файловая система для устройств на базе ОС Linux, а одной из разновидностей последнего является Android. Предназначается фирменная ФС для флеш-памяти NAND и используется во многих гаджетах собственного производства. Для облегчения работы с файлами используется таблица формата FAT, что позволяет максимально просто произвести запись файлов на флэш-память и их чтение. Специфика RFS учитывает особенности NAND накопителей, что позволяет увеличить длительность их эксплуатации, а также снизить вероятность потери данных при системных сбоях и случайных отключениях питания.
7. SDCardFS
Компания Google долгое время использовала в своих устройствах файловую систему FUSE, но она имела ряд недостатков, среди которых необходимо отметить малое количество памяти, выделяемой под приложения под приложения, а также большое потребление хранилища при кэшировнии данных. На замену FUSE пришла SDCardFS, которая решала эти проблемы, но представляла собой своего рода оболочку, эмулирующую FAT32. Она отправляет данные файловым системам нижнего уровня, что позволяет оптимизировать работу смартфонов, а также исправляет ошибки, связанные с передачей данных на компьютер и обратно. SDCardFS по своей сути не является классической файловой системой, но значительно сказывается на скорости работы смартфонов или планшетов на Android.
Выводы
Файловые системы Android самые разнообразные. Среди них есть как общие ФС, предназначенные для работы с ОС на базе Linux, так и специфические, которые используются в NAND-накопителях. Несмотря на такое разнообразие, производители все же прикладывают совместные усилия для продвижения и улучшения той или иной файловой системы, так как именно от работы внутренних составляющих зависит будущее рынка Android-гаджетов.
Стоит также отметить тот факт, что над улучшением различных файловых систем могут одновременно работать конкурирующие концерны, и именно такое объединение заставляет цифровые технологии развиваться, независимо от того, насколько яростна борьба на потребительском рынке. И только производители смартфонов определяют, какая файловая система на Android работает лучше при тех или иных обстоятельствах.
Иногда пользователю устройства с системой от Google приходится столкнуться с нетривиальными задачами, решение которых требует сначала найти папки data и system, где находятся важные файлы. Как это сделать на Android, мы расскажем в статье.
В первую очередь, пользователю понадобится файловый менеджер, который показывает не разбивку по мультимедийным данным, а реальное содержание диска. Иногда такие менеджеры встроены в прошивку, в противном же случае можно обратиться в Play Store, где есть и бесплатные варианты.
Далее с помощью него выходим в корень системы, обозначенный как «/». В ряде менеджеров для быстрого доступа к оному есть отдельный пункт в Action Bar, а где-то нужно просто нажать на знак «..» или выбрать «Корень файловой системы». Именно тут на Android и можно обнаружить папки data и system, имена их, кстати, тоже начинаются с косой черты.
Стоит обратить внимание, что данные разделы, особенно второй, содержат критически важную информацию. Если у пользователя имеется root‑доступ и он удалит файлы в папках data и system, это может вызвать проблемы с работоспособностью устройства.
Заметили ошибку? Выделите её и нажмите Ctrl+Enter или сообщите здесь.
Вступление
В этой статье я попробую рассмотреть безопасность чуть-чуть повыше ядра, а именно: как работает безопасность в Native user space. Мы коснемся темы процесса загрузки операционной системы и рассмотрим структуру файловой системы Android. Как я уже говорил, я не очень силен в Linux, поэтому если заметите неточности, то исправляйте — меня научите и статью улучшите. Так как эта тема довольно обширная, я решил разбить её на две части. В первой части мы рассмотрим процесс загрузки операционной системы и особенности файловой системы. Всем кому интересно, добро пожаловать!
Список статей
Что подразумевается под Native user space
Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel.
Файловая система Android
Для начала давайте рассмотрим структуру файловой системы Android. Хотя Android и базируется на Linux kernel, привычную нашему глазу структуру файловой системы мы здесь не увидим. Давайте запустим эмулятор и посмотрим, что у нас есть. Для этого выполним комманду:
В моем терминале для эмулятора на Android 4.2 я вижу следующий результат:
Я отмечу здесь только главные директории и те, которые нам пригодятся в будущем. В Интернете можно найти описание и предназаначение других директорий. Можно заметить, что некоторые директории такие же, как и в Linux, например, /dev, /proc, /sys, /mnt, /etc И их предназначение в основном такое же, как и в Linux. Кстати, отметьте, что мы не видим /bin и /lib директорий. Где они скрылись, я расскажу чуть позже.
C другой стороны можно заметить директории, которых в Linux вообще нет. Среди них нас интересуют /data, /system, /cache, /init, /init.rc Давайте рассмотрим их назначение поподробнее.
/system Это главная директория, где хранятся неизменяемые компоненты Android системы. Если проводить аналогию, то эта папка похожа на папку C:windows, доступную только для чтения. Т.е. изменять данные в этой директории мы не можем. Как раз здесь можно найти директории /bin и /lib, где хранятся различные исполняемые файлы и shared libraries. Кроме того, здесь же лежат системные приложения, которые встроены в операционку и которые, по умолчанию, нельзя удалить. Содержимое этой директории формируется во время компиляции операционной системы.
/data Т.к. /system у нас доступна только для чтения, то должна быть директория где хранятся изменяемые данные. /data как раз ею и является. Например, в эту директорию в /data/app сохраняются apk файлы устанавливаемых приложений, а в /data/data хранятся их данные (эту директорию мы подробно рассматривали в прошлой статье).
/cache Это просто временное хранилище. Также в эту директорию сохраняются, а потом из неё запускаются системные обновления.
Чтобы понять, что такое /init файл и для чего нужны непонятные файлы с расширением *.rc, рассмотрим процесс загрузки системы.
Процесс загрузки Android
Давайте рассмотрим несколько шагов процесса загрузки операционной системы Android. Эта картинка взята из книги «Embedded Android», там же можно найти и более детальное описание. Хотя в целом я и понимаю процесс, но для меня это больше магия 🙂
CPU. Когда вы нажимаете на кнопку включения, на процессор вашего устройства начинает подаваться напряжение. Так как до этого момента процессор был выключен, и так как он не способен сохранять свое состояние без подачи напряжения, то сразу после старта он находится в некотором неинициализированном состоянии. В данном случае процессор считывает из своего специального регистра некоторый жестко зашитый адрес и начинает выполнять инструкции начиная с него. Чаще всего, этот адрес указывает на чип, в который зашит bootloader (загрузчик).
Bootloader. Bootloader инициализирует RAM и загружает в неё Linux kernel. Кроме того Bootloader создает RAMdisk.
Linux kernel. Ядро инициализирует различные подсистемы, встроенные драйвера и монтирует root filesystem (корневую файловую систему). После этого ядро может запускать первую программу.
На этом магия заканчивается и дальше всё становится более-менее понятно.
Первой программой в случае Android является init. Исполняемый файл находится в корневой директории (/init). Именно эту программу стартует ядро после своей загрузки. Её исходники находятся в папке system/core/init/ Давайте в них слегка покопаемся. Нас интересует system/core/init/init.c:
Вначале мы создаем и монтируем некоторые необходимые для работы директории, а потом парсим файл /init.rc и выполняем то, что распарсили. Формат /init.rc файла очень хорошо описан в readme, там же можно найти и пример. Если кратко, то этот файл представляет собой набор actions (секций — именнованная последовательность комманд). Каждая последовательность команд срабатывает по определенному trigger (триггеру). Например, следующая последовательно — это action, в которой trigger — это fs, а последовательность команд — это набор mount команд:
Исходный файл /init.rc находится в system/core/rootdir/init.rc Давайте рассмотрим некоторые основные его части, хотя я вам очень советую просмотреть его полность. После этого многие вещи вам должны стать понятны. Итак, начинается наш файл следующими строками:
Они означают, что кроме init.rc файла нужно также импортировать настройки из файлов init.usb.rc, init.trace.rc и из файла с непонятным именем init.$.rc Впрочем, $ — это просто переменная, значение которая определяет тип железа. В случае эмулятора, её значение, например, — goldfish. Далее определяются переменные окружения:
После этого происходит инициализация переменных, необходимых для работы устройства. Если вас заинтересует эта тема, то вы легко найдете информацию о той или иной комманде. Давайте подробно рассмотрим следующий блок (который я уже приводил в этой статье):
MTD — Memory Technology Devices. Если в общих чертах, то MTD — это специальный чип с энергонезависимой (т.е. данные на этом чипе сохраняются после перезагрузки или выключения) flash-памятью (типа NOR или NAND), на который сохраняются образы дисков. В этой статье более подробно рассказывается об этом типе устройств, а также об ограничениях. Специально для этих разновидностей flash-памяти были разработаны специальные файловые системы, например, YAFFS. Одно из самых важных ограничений этих типов памяти заключается в том, что для того чтобы записать данные в сектор, куда уже записаны какие-то данные, вам надо полностью сначала стереть весь сектор. Поэтому производители стали переходить на новый тип блочной flash-памяти (eMMC), на которые можно поставить обычную ext4 файловую систему и избавиться от указанного ограничения. Т.к. я показываю пример init.rc файла для эмулятора, где вся работа эмулируется, то в нем по умолчанию используется файловая система YAFFS2 (думаю, что это пережитки прошлого, т.к. YAFFS2 использовалась для всех устройств до Android 2.2). В реальном устройстве (это как раз один из примеров, когда необходимо использовать init.rc файл для определенного железа) эти комманды будут перезаписаны. Например, в случае устройства herring (Google Nexus S), в файле init.herring.rc эта секция выглядит следующим образом:
Где fstab.herring — это файл, содержимое которого выглядит следующим образом:
Как вы могли заметить, /system, /data, /cache — это просто mounting points (точки монтирования файловой системы), которые указывают либо на MTD устройства (в случае эмулятора), либо на блочные устройства (в случае настоящего устройства), куда записаны соответствующие дисковые образы (system.img, userdata.img и cache.img). Я не уверен, но думаю, что внутри смартфона находится один единственный чип с flash-памятью, разделенный на partitions (тома), в каждый из которых записан соответствующий образ. Этот чип с flash-памятью — то, что мы знаем под именем Internal storage (внутренняя память), объем которой — один из основных параметров смартфона.
Следует заметить, что /system смонтирован read-only (только для чтения). Это означает, что содержимое данного раздела не изменяется в процессе работы устройства, а только когда вы, например, обновляете систему на вашем устройстве (используя системные обновления).
Продолжим рассматривать наш init.rc. По триггеру post-fs-data формируется базовая структура файловой системы /data раздела. Там, в общем всё понятно — набор mkdir, chown, chmod команд.
Далее init.rc запускает несколько демонов. Если вернуться к рисунку в начале статьи, то они перечислены в блоке Native daemons. На этом мы пока остановимся. Как вы могли заметить из рисунка, я не полностью рассмотрел процесс загрузки операционной системы. Некоторые непокрытые этапы я рассмотрю в следующих статья.
Заключение
В следующей части я расскажу, откуда берутся образы system.img, userdata.img и cache.img и рассмотрю безопасность на уровне Native user space. Как всегда приветствуются исправления, дополнения, а так же предложения, о чем написать. И хотя у меня уже есть некоторый план, о чем писать в следующих статья, я готов его подкорректировать.
Ссылки
Update
- Комментарий от пользователя bmx666 про различные варианты размещения загузчика на MTD устройствах.
- Комментарий от пользователя SamOwaR про инициализацию CPU на разных SoC
Загрузка...