Укажите программу которая создает файловую структуру на дисках

Укажите программу которая создает файловую структуру на дисках

A Файловая система это методы и структуры данных, которые используются операционной системой для хранения файлов на диске или его разделе. О файловой системе также говорят, ссылаясь на раздел или диск, используемый для хранения файлов или тип файловой системы.

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

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

У большей части файловых систем UNIX сходная структура, а их некоторые особенности очень мало различаются. Основными понятиями являются: суперблок (superblock), индексный дескриптор (inode), блок данных (data block), блок каталога (directory block) и косвенный блок (indirection block) . В суперблоке содержится информация о файловой системе в целом, например, ее размер (точная информация зависит от типа файловой системы). В индексном дескрипторе хранится вся информация о файле, кроме его имени. Имя файла хранится в блоке каталога , вместе с номером дескриптора. Запись каталога содержит имя файла и номер индексного дескриптора соответствующего файла. В этом дескрипторе хранятся номера нескольких блоков данных , которые используются для хранения самого файла. В inode есть место только для нескольких номеров блоков данных, однако, если требуется большее количество, то пространство для указателей на блоки данных динамически выделяется. Такие блоки называются косвенными . Для того, чтобы найти блок данных, нужно сначала найти его номер в косвенном блоке . Как видите, в устройстве файловой ext2, типичной для Linux нет ничего сложного.

В файловых системах UNIX обычно имеется возможность создания дыр (hole) в файлах (это можно сделать с помощью команды lseek , см. man-руководство). Это означает, что файловая система предоставляет ложную информацию о том, что в каком-то месте в файле содержатся нулевые байты, но в действительности для этого не выделяются сектора (это означает, что файл будет занимать несколько меньше места на диске). Это часто используется особенно в небольших двоичных программах, библиотеках Linux, в некоторых базах данных и в других отдельных случаях. Дыры реализуются хранением специального значения в косвенном блоке или индексном дескрипторе вместо адреса блока данных. Это специальное значение показывает, что для данной части файла блоки данных не размещены и, следовательно, что в файле есть дыра. Таким образом, довольно примитивное сжатие данных в Linux реализовано непосредственно на уровне файловой системы.

Использование дыр неожиданно эффективно. На компьютере с общим дисковым пространством в 200 Мб, простые измерения показывают, что применение дыр дает экономию в 4 Мб. Однако, эти измерения проводились на системе, где было установлено относительно мало программ и отсутствовали файлы баз данных. Метод измерения дыр рассмотрен в приложении B.

Linux поддерживает несколько типов файловых систем. Наиболее важные из них рассмотрены ниже.

Считается самой старой и самой надежной файловой системой, но достаточно ограниченной в своих возможностях (у файлов отсутствуют некоторые временные параметры, длина имени файла ограничена 30-ю символами) и доступных объемах (максимум 64 Мб на одну файловую систему).

Модифицированная версия системы minix, в которой увеличена максимальная длина имени файла и размер файловой системы, хотя она не pеализует никаких новых возможностей.

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

Предыдущая версия системы ext2, не совместима с последующими версиями. В настоящее время она очень редко включается в пакеты новых поставляемых систем, т.к. большинство пользователей сейчас пользуются системой ext2. В принципе уже есть и ext3, но она пока находится только в стадии бета-ьестирования.

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

Обеспечивается совместимость с системой MS-DOS (а также OS/2 и Windows NT) по файловым системам FAT12, FAT16, FAT32 и VFAT.

Основная файловая система Windows NT.

Расширяет возможности драйвера файловой системы MS-DOS для Linux таким образом, что при работе в Linux, имеется возможность работы с именами файлов нестандартной длины, просмотра прав доступа к файлу, ссылок, имени пользователя, которому принадлежит файл, а также оперирование с файлами устройств. Это позволяет использовать обычную систему MS-DOS, так, как если бы это была система Linux. Таким образом, исключается необходимость создания отдельного раздела для Linux.

Стандартная файловая система для CD-ROM. Довольно популярное развитие стандарта CD-ROM, выполненное Rock Ridge’ем, которое обеспечивает автоматическую поддержку имен файлов нестандартной длины.

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

Файловые системы OS/2.

Файловые системы Apple MacOS.

Файловая система для дисков DVD.

Файловые системы SystemV/386, Coherent и Xenix.

Есть поддержка множества других файловых систем, например, Atari или Amiga. На текущий момент Linux поддерживает порядка 50 файловых систем. Такое возможно благодаря применению технологии IFS (Installable File System), которая позволяет подключать новые системы с помощью драйверов. Нечто подобное сейчас пытается сделать Windows NT, но ее успехи пока незначительны. Набор используемых файловых систем зависит от конкретной ситуации. Для Linux лучшим выбором является ext2. Если Вам нужна совместимость с другими системами, ее можно организовать.

Также существует файловая система proc, которая обычно доступна через каталог /proc . В действительности, она не является файловой системой, хотя по ее структуре сложно обнаружить разницу. Эта система позволяет получить доступ к определенным структурам данных ядра, к таким, как список процессов (process list, отсюда и название) или сведения об аппаратуре. Все эти структуры выглядят как файловая система из каталогов и обычных текстовых файлов и ими можно оперировать обычными средствами работы с файловой системой. Например, для получения списка всех процессов, используется следующая команда: В действительности, должно быть еще несколько файлов, не соответствующих процессам, однако, этот пример немного укорочен. Вы будете удивлены когда поймете, сколько программ активно работают с данной файловой системой. При ее грамотном использовании можно написать программу для вывода практически любой системной информации, какая только есть. Причем, все данные доступны в виде обычного текста!

Хотя система /proc и называется файловой, ни одна ее часть не взаимодействует с диском. Она существует только в представлении ядра и при попытке обращения к какой-либо ее части, создается впечатление, что эта часть где-то существует, хотя в действительности это не так. Даже если существует файл /proc/kcore в несколько мегабайт размером, он не занимает места но диске.

Обычно мало смысла в пpименении нескольких разных файловых систем (разве что для совместимости). В настоящее время наиболее популярной считается система ext2fs и, возможно, она является наилучшим выбором. В зависимости от различных параметров (скорость, производительность, надежность, совместимость и др.) может оказаться, что установка другой файловой системы будет более приемлемым вариантом.

Файловая система устанавливается, т.е. инициализируется, при помощи команды mkfs . В действительности, существуют отдельные программы для каждого типа файловой системы. Команда mkfs только запускает требуемую программу в зависимости от типа устанавливаемой системы. Немножко напоминает выводок дефрагментаторов диска в Windows 2000. Тип файловой системы указывается при помощи опции -t fstype .

Параметры, передаваемые программам, вызываемым mkfs , слегка различаются. Наиболее важные из них рассмотрены ниже (для более подробной информации см. man-руководство).

Указывается тип файловой системы.

Производится поиск плохих блоков и, соответственно, инициализация списка плохих блоков.

Считывается начальный список плохих блоков из файла filename.

Для установки файловой системы ext2 на дискету (камешек в огород Windows NT и Windows 2000: они могут ставить на дискету только разные варианты FAT!), используется следующая последовательность команд: В первую очередь дискета форматируется (параметр -n предотвращает проверку на наличие плохих блоков). Затем производится поиск плохих блоков при помощи команды badblocks , вывод которой перенаправлен в файл bad-blocks . И, наконец, файловая система устанавливается с инициализацией списка найденных плохих блоков.

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

Установка файловых систем на жесткий диск или его раздел аналогична установке на дискету, исключая форматирование.

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

Рассмотрим три различные файловые системы. Если две последние системы (2-ю и 3-ю) соответственно смонтировать к каталогам /home и /usr первой системы, то в итоге образуется файловая система с единой структурой каталогов (4):

В примере, рассмотреном ниже, показано, как это сделать. Команда mount принимает два параметра. Первый их них файл устройства, соответствующий диску или разделу, на котором раположена файловая система. Вторым параметром является имя каталога, к которому будет монтироваться система. После выполнения этих команд содержимое файловых систем отображается в каталогах /home и /usr соответственно. Также можно сказать, что раздел /dev/hda2 смонтирован к каталогу /home , а /dev/hda3 к каталогу /usr . Существует различие между файлом устройства, /dev/hda2 , и монтируемым каталогом, /home . Файл устройства предоставляет доступ к ‘сырым’ данным, расположенным на диске, а монтируемый каталог к файлам. Такой каталог называется узлом или точкой монтирования (mount point) .

Linux поддерживает много файловых систем. Команда mount пытается сама определить тип файловой системы для монтирования, но не всегда у нее это получается. В таком случае Вы можете ей помочь параметром -t fstype , который задает тип файловой системы однозначно. Например, чтобы сммонтировать дискету MS-DOS скомандуйте:

Монтируемый каталог не обязательно должен быть пустым, хотя он должен существовать. Однако все файлы, в нем расположенные, будут недоступны после монтирования файловой системы. Открытые ранее файлы будут также доступны, а файлы, являющиеся жесткими ссылками из других каталогов, будут доступны с использованием имен ссылок. Таким образом, никакого ущерба не наносится и это даже может быть полезно. Например, некоторые делают каталог /tmp символической ссылкой на каталог /var/tmp . При загрузке системы, когда файловая система /var не смонтирована, каталог размещается в системе root . После того, как /var смонтирована, каталог /var/tmp , расположенный в файловой системе root , становится недоступным. Если же /var/tmp не существует в системе root , то перед монтированием /var создание и pабота с временными файлами будет невозможна.

Для защиты файловой системы от записи, команда mount запускается с опцией -r , после чего монтирование производится в режиме read-only . После этого ядро пресекает любые попытки записи, включая модификацию времени доступа к файлам в индексном дескрипторе. Монтирование с защитой от записи используется при работе с такими устройствами, как CD-ROM.

Возникает вопрос: каким же образом монтируется корневая файловая система (т.е. система root), так как очевидно, что она не может быть смонтирована на какую-либо другую. Система root монтируется во время загрузки, поэтому считается, что она всегда установлена (если бы она не была установлена, то компьютер не смог бы загрузиться). Название файловой системы, используемой для монтирования root, либо встроено в ядро, либо устанавливается при помощи LILO или rdev .

Обычно сначала система root монтируется в режиме read-only. Затем запускается программа fsck для проверки ее целостности и если все в порядке, то система перемонтируется (re-mount) в режиме read-write. fsck не следует запускать на смонтированной файловой системе, так как изменения, произведенные при ее выполнении, могут привести к повpеждению системы. Так как система root сначала монтируется в режиме read-only, то после ее проверки все неполадки могут быть полностью устранены при повторном монтировании.

На многих системах существуют и другие файловые системы, которые должны быть смонтированы во время загрузки. Их список содержится в файле /etc/fstab (см. man-руководство к fstab(5)). Детали монтирования могут сильно отличаться на каждой системе. Ряд советов можно получить в главе 6.

Если файловая система для работы больше не требуется, то она может быть размонтирована. Для этого используется команда umount с одним параметром. Это может быть как файл устройства, так и узел монтирования. Например, для демонтирования каталогов, рассмотренных в предыдущем примере, используются следующие команды:

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

Для выполнения операций монтирования и демонтирования требуется наличие прав доступа пользователя root. Причин к тому много, но главное то, что разрешение монтировать кому угодно что угодно приведет к появлению ловушек для администратора. Например, загрузки с дискеты программы /bin/sh с правами root. Однако, многие пользователи довольно часто работают с дисководом и для решения этой проблемы существует несколько способов:

Сообщить всем пароль пользователя root. Это самый простой, но далеко не лучший выход. Он может использоваться на некоторых системах, не нуждающихся в защите (обычно не подключенных к какой-либо сети). Правда, я пока не видел таких Linux-систем.

Применять какую-либо программу (например, sudo ), позволяющую всем использовать команду mount. Это также не лучший способ по причине плохой защиты, хотя его применение не предоставляет напpямую права root каждому пользователю.

Применение пакета mtools , используемого только для работы с файловой системой MS-DOS без выполнения операции монтирования. Используется только в тех случаях, когда дисковод применяется для работы с дисками системы MS-DOS.

Поместить список файлов устройств, используемых при работе с гибкими дисками, и доступных узлов монтирования вместе с нужными опциями в файл /etc/fstab. .

Опция noauto запрещает автоматическое монтирование при начальной загрузке системы. Команда mount -a не смонтирует такую файловую систему. Опция user позволяет любому пользователю монтировать указанную файловую систему и, по причине защиты системы, запрещает выполнение программ и работу с файлами устройств, расположенных на смонтированной системе. После этого, любой пользователь может выполнить следующую команду: Для демонтирования системы используется команда umount с соответствующими параметрами.

Если нужно работать с дискетами, имеющими различные типы файловой системы, создайте разные точки монтирования. Опции для каждой точки будут своими. Например, для обеспечения работы с дискетами в форматах MS-DOS и ext2 внесите в /etc/fstab строки: Для файловой системы MS-DOS (не только для дискет), ограничьте доступ опциями uid , gid , и umask подробно рассмотренных в man-руководстве по команде mount .

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

Большинство систем сконфигурировано таким образом, что команда fsck запускается автоматически при загрузке системы, поэтому возможные неполадки будут обнаружены (и, возможно, исправлены) перед тем, как система будет использоваться. Работа с поврежденной файловой системой может привести к потерям данных и другим нарушениям ее функционирования. Однако, если файловая система довольно большая по объему, то ее проверка может занять некоторое время, а так как неполадки случаются очень редко, то если система была выключена корректно, пpименяются определенные методы для избежания проверки файловой системы. Первый из них связан с тем, что если существует файл /etc/fastboot , то никаких проверок не производится. Второй метод заключается в том, что в файловой системе ext2 существует специальный флаг, раположенный в суперблоке, который используется для выявления коppектности демонтирования системы пpи последнем выключении системы. Эта возможность используется в программе e2fsck (версия команды fsck для файловой системы ext2fs) для избежания излишней проверки файловой системы, если флаг ее целостности установлен (то есть система была коppектно демонтирована). Фунционирование метода, используещего файл /etc/fastboot , зависит от файлов, запускаемых при загрузке системы, в то время как применение команды e2fsck работает в любом случае (см. man-руководство по e2fsck для более подробной информации о такой проверке).

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

Если fsck находит неисправность, не подлежащую восстановлению, то могут потребоваться глубокие знания и понимание работы файловых систем и их типов. Также могут потребоваться резервные копии. Некоторую информацию по тем или иным вопросам можно найти через телеконференции, связанные с системой Linux. Также может потpебоваться программа debugfs , созданная Theodore T. Впрочем, как показывает практика, такое бывает редко.

Команда fsck должна использоваться только для демонтированных систем (за исключением системы root, смонтированной в режиме read-only во время загрузки), так как при ее работе используется прямой доступ к диску и информация о внесении каких-либо изменений в файловую систему может быть недоступна операционной системе, что, обычно, приводит к нарушению ее работы.

Периодически следует проводить поиск плохих блоков при помощи команды badblocks . При ее выполнении выводится список номеров найденных плохих блоков. Этот список может быть использован программой fsck для внесения изменений в структуру файловой системы во избежание использования этих блоков для хранения информации. В следующем примере показано как это сделать. Если badblocks сообщает, что блок который уже использовался плохой, e2fsck пробует переместить блок в другое место. В ряде случаев содержимое файла может быть повреждено, хотя обычно перемещение проходит вполне успешно.

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

Файловая система ext2 пытается уменьшить фрагментацию, храня все блоки в файле близко друг к другу, даже если они не могут быть сохранены в последовательных секторах. Ext2 действительно всегда распределяет свободный блок, который является самым близким к другим блокам в файле. Для ext2, следовательно редко нужно беспокоиться относительно фрагментации. Имеется программа для дефрагментации файловой системы ext2, но необходимость в ней бывает редко.

Имеется много MS-DOS программ дефрагментации, которые перемещают блоки в файловой системе, чтобы удалить фрагментацию. В последнее время программы сильно поумнели: например, файлы, которые редко нужны, сдвигаются в конец диска, а часто используемые в начало. Для других файловых систем дефрагментация может быть выполнена путем резервирования, пересоздания файловой системы и восстановления файлов из резервных копий, что больше похоже на стрельбу из пушки по воробьям. Однако, резервирование файлов является рполезным, поскольку при дефрагментации всегда есть вероятность, хоть и очень маленькая, потери данных.

Есть ряд простых утилит для управления файловыми системами. df показывает свободное место на диске для одной или нескольких файловых систем. du показывает как именно используется диск (размеры файлов и каталогов).

sync принудительно записывает все оставшиеся в буфере блоки (см. раздел Кэш-буфер в главе 5) на диск. Прроцесс-демон update вызывает его автоматически. sync часто помогает избежать крупных проблем, например, если update или его вспомогательный процесс bdflush повис, или если Вы должны выключить питание сейчас и не можете ждать, пока сработает update .

В дополнение к программе создания файловой системы ( mke2fs ) и программе для ее проверки ( e2fsck ) файловая система ext2 имеет еще ряд полезных утилит.

tune2fs настраивает тонкие параметры файловой системыa, Вот некоторые из них:

Максимальный счетчик монтирования. e2fsck выполняет проверку файловой системы после исчерпания данного счетчика, даже если установлен флаг целостности файловой системы. Если Вы занимаетесь разработкой, может быть полезным увеличить данный лимит.

Максимальное время между проверками. e2fsck может также иметь максимальное время между двумя проверками, даже если установлен флаг целостности файловой системы и не выбран лимит количества монтирований. Эта опция может быть заблокировано.

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

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

Примерный вывод для команды dumpe2fs

debugfs является отладчиком файловой системы. Он дает прямой доступ к структурам данных файловой системы, сохраненным на диске, и может использоваться для ремонта диска, который так поврежден, что fsck не может отремонтировать его автоматически. Он также может использоваться, чтобы восстановить удаленные файлы. Однако, debugfs очень требует того, чтобы Вы понимали то, что вы делаете; сбой может уничтожить все Ваши данные. Кто работал с программой Disk Editor в DOS меня поймет.

dump и restore могут использоваться для резервирования и восстановления файловой системы ext2. Они являются специфические версиями для ext2 традиционных для UNIX инструментальных средств. См. главу 10 для подробностей по резервированию.

Как создать файловую систему Ext4 с помощью Mkfs 4 мин для чтения

Ext4 стала файловой системой по умолчанию для многих дистрибутивов Linux и теперь является стандартом де-факто для ядер Linux 2.6.28 и выше.

Что мы узнаем?

В этой статье мы увидим базовый обзор файловой системы Ext4 и то, как мы можем использовать ее для создания файловой системы Ext4 с помощью mkfs?

Файловая система Linux Ext4

В отличие от 32-битной файловой системы ext3, которая просто добавила несколько функций к предыдущей файловой системе ext2 и сохранила ту же структуру данных, что и файловая система ext2, файловая система ext4 включает в себя более значительные улучшения, чем ext3, например:

1. Улучшенная структура данных и улучшенные функции.
2. 64-битная файловая система.
3. Поддерживает размеры файлов до 16 ТБ.
4. Одновременное выделение нескольких единиц.
5. Быстрый fsck (проверка файловой системы).

История файловой системы EXT

Хотя файловая система EXT была создана для Linux, ее происхождение восходит к ОС Minix и файловой системе Minix. Линус Торвальдс использовал файловую систему Minix для своей первой версии Linux. Файловая система EXT появилась в Linux в 1992 году, чтобы компенсировать некоторые ограничения размера, связанные с файловой системой Minix. Однако вскоре файловая система EXT была вытеснена ее преемницей файловой системой EXT2.

Файловая система EXT2 имела большой успех. В течение многих лет она использовалась в системах Linux. Файловая система EXT2 имеет те же структуры метаданных, что и файловая система EXT, но EXT2 является более продвинутой, поскольку оставляет больше места на диске между структурами метаданных для будущего использования. Одна проблема с файловой системой EXT2 заключалась в том, что восстановление после сбоя может занять много часов, поскольку инструменту fsck (проверка файловой системы) потребовался долгий путь, чтобы найти и исправить любые нарушения в файловой системе.

Файловая система EXT3 была разработана с учетом большого количества времени, необходимого инструменту fsck для правильного восстановления структуры диска, нарушенной ошибочным завершением работы во время действия по обновлению файлов. Он был добавлен к основному ядру Linux версии 2.4.15. Журнал, который заранее записывает изменения в файловой системе, был единственным улучшением файловой системы EXT. Остальная структура диска остается неизменной по сравнению с EXT2.

Файловая система EXT4 была представлена ​​в 2006 году и была принята в основное ядро ​​Linux версии 2.6.28 в 2008 году. Файловая система Ext4 работает так же, как и Ext3. Тем не менее, он добавляет поддержку больших файловых систем, повышенную устойчивость к фрагментации, превосходную производительность, а также лучшие временные метки.

Создание файловой системы Ext4 с помощью mkfs

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

Разделы в Linux монтируются в определенных точках дерева каталогов, что делает их доступными как подкаталоги.

Давайте переместимся и посмотрим, как мы можем создать файловую систему EXT4 с помощью инструмента GNU Parted:

Шаг 1 . Во-первых, давайте перечислим раздел, доступный в нашей системе:

Или вы также можете использовать:

Шаг 2 . Используйте следующую команду для изменения целевого диска (в нашем случае /dev/sdb):

Вы увидите сообщение, подобное приведенному ниже:

В этом новом приглашении мы можем использовать различные команды GNU parted, такие как help, mklabel, mkfs, mkpart и т. д.

ВАЖНОЕ ПРИМЕЧАНИЕ: GNU Parted немедленно применяет свои модификации. С помощью fdisk вы можете отменить изменения с помощью команды «q». Это очень полезно, если вы допустили ошибку во время операции с разделом. Однако с GNU Parted выхода нет. Поэтому при использовании GNU Parted следует проявлять крайнюю осторожность.

Шаг 3. Теперь мы будем использовать здесь команду print, чтобы отобразить информацию о файловой системе для нашего целевого диска «sdb»:

Таким образом, мы можем подтвердить, что работаем с правильным диском. Вы можете использовать команду mklabel, чтобы дать метку вашему диску.

Шаг 4 . Теперь мы выполним команду mkpart:

Это подскажет нам разные значения:

Partition type? primary/logical? primary Enter primary here.

Partition name? []? Enter some name like Andreyex.

File system type: Use ext4 here.

Start? Enter some value here like 100MB.

End? Enter some value here like 21GB.

Здесь мы используем ТБ для единицы «terabyte». Мы также можем использовать другие единицы и форматы, такие как GB, GiB, kB, KiB и т. д. Теперь снова запустите команду «print», чтобы увидеть детали раздела:

Шаг 5. Простого создания разделов недостаточно, чтобы сделать их функциональными. Чтобы использовать их, вам нужно сначала создать файловую систему на разделе (это процедура, известная как «форматирование» раздела). Теперь выйдите из разделенного приложения.

Отформатируем наш раздел утилитой mkfs. Мы также можем использовать mke4fs для этой цели:

Здесь /dev/sdb1 — это блочное устройство в нашем случае.

В приведенной выше команде block_device — это раздел, в котором будет храниться файловая система Ext4, которая будет создана на следующих шагах.

Шаг 6. На этом шаге мы создадим точку монтирования файловой системы, на которую будет монтироваться:

Теперь смонтируйте файловую систему в указанной выше точке монтирования:

Проверьте вышеуказанные шаги с помощью команды df :

Шаг 7 . Наконец, измените файл fstab для постоянного монтирования новой файловой системы:

Введите следующее содержимое здесь, в этом файле:

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Создание Файловых систем в Linux

Мы уже делали обзор популярных Файловых систем в Linux и разобрались как они работают. Для того что бы размещать файлы на жестком диске или другом носителе например флешке нам нужно как минимум проделать несколько этапов а именно — разбить диск на разделы (создать таблицу разделов) и создать файловую систему (формотирование) с последующим монтированием в систему.

Разбитие диска на разделы и создание ФС в Linux делается при помощи специальных утилит — cfdisk fdisk sfdisk mke2fs mkfs mkfs.ext2 mkfs.ext3 mkfs.ext4 mkswap partimage parted указывая им в качестве аргумента конкретное блочное устройство (/dev/***).

Блочные устройства HDD вида /dev/sda можно использовать целиком для единственной ФС, но это редко применяется на практике. Лучше разделить все пространство на разделы меньшего размера и использовать их под разные задачи.

Обзор блочных устройств:

Посмотреть какие есть блочные устройства в системе можно так

# ls -l /dev/sd*
brw-rw—- 1 root disk 8, 0 Мар 11 19:03 /dev/sda
brw-rw—- 1 root disk 8, 1 Мар 10 21:23 /dev/sda1
brw-rw—- 1 root disk 8, 2 Мар 10 21:23 /dev/sda2
brw-rw—- 1 root disk 8, 5 Мар 10 21:23 /dev/sda5
brw-rw—- 1 root disk 8, 16 Мар 10 22:31 /dev/sdb
brw-rw—- 1 root disk 8, 17 Мар 10 21:23 /dev/sdb1
brw-rw—- 1 root disk 8, 18 Мар 10 21:23 /dev/sdb2
brw-rw—- 1 root disk 8, 21 Мар 10 21:23 /dev/sdb5
brw-rw—- 1 root disk 8, 32 Мар 11 19:05 /dev/sdc
brw-rw—- 1 root disk 8, 33 Мар 11 17:59 /dev/sdc1

b — блочное устройство, судя по выводу у нас 3 физических диска.

Вывестии информацию о жестком диске можно так

hdparm -I /dev/sdХ
smartctl -a /dev/sdХ

Рассмотрим на примере диска /dev/sda

/dev/sda1
/dev/sda2
/dev/sda5

Названия соотвуют их разделам. Раньше рограммы разметки диска могли делать максимум четыре раздела. В некоторых случаех этого было недостаточно и для обхода ограничения был придуман расширенный раздел (Extended). Расширенный раздел засчитываются в лимит для 4 первичных разделов и может содержать любое количество логических разделов внутри себя. У меня его нету поэтому не покажу как он выглядит.

Способы разметки диска:

Посмотреть таблицу разделов диска можно при помощи fdisk (p вывести таблицу разделов диска).

Command (m for help): p

Disk /dev/sdc: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdf87df87

Device Boot Start End Blocks Id System
/dev/sdc1 * 1 7297 58613121 83 Linux

Disk /dev/sdc: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdf87df87

Device Boot Start End Blocks Id System
/dev/sdc1 * 1 7297 58613121 83 Linux

Давайте переразобьем диск /dev/sdc (у меня это пустой ssd диск)
Внимание! Все данные на диске будут удалены =)

Вариант при помощи fdisk

Справка команд fdisk

a переключение флага загрузки
b редактирование метки диска bsd
c переключение флага dos-совместимости
d удаление раздела
l список известных типов файловых систем
m вывод этого меню
n добавление нового раздела
o создание новой пустой таблицы разделов DOS
p вывод таблицы разделов
q выход без сохранения изменений
s создание новой чистой метки диска Sun
t изменение id системы раздела
u изменение единиц измерения экрана/содержимого
v проверка таблицы разделов
w запись таблицы разделов на диск и выход
x дополнительная функциональность (только для экспертов)

Command (m for help): d
Command (m for help): 1
Command (m for help): w

я выбрал удаление раздела d, раздел 1 и записал изменения на диск, теперь он не содержит разделы.

Разабьем диск /dev/sdc

Command (m for help): n
p primary partition (1-4)
Partition number (1-4): 1
First cylinder (1-7297, default 1):1
Last cylinder, +cylinders or +size (1-7297, default 7297): +10G
Command (m for help): w

Мы создали раздел размером 10гб, если вывод аналогичен то все получилось

Disk /dev/sdc: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdf87df87

Device Boot Start End Blocks Id System
/dev/sdc1 1 1306 10490413+ 83 Linux

Таким макаром можно делать остальные разделы, по умолчанию тип фс Linux если нужен другой то

Command (m for help): t
Hex code (type L to list codes): ХХХ — номер.
Command (m for help): w
Command (m for help): l

Вариант при помощи cfdisk

Тут все еще проще визуально все понятно, например:

для создания раздела выберите New
для удаления delete
по окончанию работы нажмите Write что бы применить изменения.

Are you sure you want to write the partition table to disk? (yes or no): yes — пишите yes.

Ну и для полного счастья осталось только отформатировать созданные ранее разделы.

Формирование диска

Формотировать и создовать новую фс будем при помощи утилиты mkfs, можно посмотреть что у нас есть

# mkfsmkfs mkfs.cramfs mkfs.ext3 mkfs.ext4devmkfs.bfs mkfs.ext2 mkfs.ext4 mkfs.minix

Файловые системы типо XFS команда mkfs не поддерживает для этого надо поставить пакет xfsprogs.

Будем форматировать /dev/sdc1 в ext4.

# mkfs.ext4 /dev/sdc1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
3670016 inodes, 14653280 blocks
732664 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
448 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

SWAP делается так (тип созданного раздела должен быть специальным 82 Linux swap)

mkswap /dev/sdc5
swapon /dev/sdc5

# mkswap /dev/sdc5
Setting up swapspace version 1, size = 9783548 KiB
no label, UUID=fe193ed2-6e46-45f0-82ee-9fc6b652a6b5
root@debian

# swapon /dev/sdc5
root@debian

# swapon -s
Filename Type Size Used Priority
/dev/sdc5 partition 9783544 0 -1
root@debian

Создание своей файловой системы для Windows

В Linux, как известно, многие вещи реализованы как файлы в файловой системе. А если и не реализованы, то их можно реализовать самому с помощью FUSE, мы уже об этом писали в статье «Создание файловой системы на FUSE и Swift». В Windows это реализовать труднее, но если все же очень хочется смонтировать что-то как файловую систему, то это возможно. В этой статье я покажу, как этого добиться, используя C# и библиотеку Dokan.

Если вы уже знакомы с утилитой CyberSafe Top Secret, то вы, наверное, тоже столкнулись с тем, что добавлять файлы в контейнер не совсем удобно. Совсем другое дело — VeraCrypt: монтируется локальный диск, и файлы шифруются на лету. Именно так будет работать и наш проект.

Теория

Каждый раз, когда вы открываете папку «Компьютер», файловый менеджер отправляет запрос ядру с просьбой сказать, какие есть диски. Как происходит общение с драйвером? Через диспетчер ввода-вывода. Любое приложение может отправить ему пакет с запросом (IRP, I/O Request Packet) и информацией, кому он предназначен. Диспетчер принимает этот запрос и передает его нужному драйверу.

Получив список занятых букв, файловый менеджер последовательно опрашивает систему о том, какие метки тома у этих дисков, сколько на них осталось места, какая файловая система и так далее. Каждый такой запрос передается первому драйверу в цепочке. Если тот не знает, что ответить, он спрашивает следующий, тот в свою очередь — дальше. И так, пока какой-либо из них не ответит, что нужные данные найдены (или не найдены). На самом деле эта схема работает чуток посложнее, но для общего понимания этого достаточно.

Передача данных между драйверами по цепочке позволяет существовать руткитам и прочим вредоносам.

Любой драйвер средствами все того же диспетчера ввода-вывода может что-нибудь спросить у любого приложения, работающего в user-mode, что и используется в драйвере FUSE.

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

Результат создания своего драйвера файловой системы

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

Dokan

В теории существует версия FUSE для Windows, однако заставить ее работать мне не удалось. Возможно, это было бы само по себе интересным опытом, но я избрал другой путь.

Есть такой проект — Dokan. По сути, это тот же FUSE, но с кучей приятных дополнительных функций. Во-первых, он ни разу за время его использования у меня не выдал ни одного синего экрана смерти. Во-вторых, есть библиотеки, которые позволяют работать с ним из самых разных языков, включая Delphi, Ruby, C# и Java (их вы найдете на GitHub по ссылке выше). И в-третьих, разобраться с ним почти так же просто, как и с FUSE. Так что будем использовать его, библиотеку под C# и немного фантазии.

От изначального проекта Dokan сейчас осталось очень мало. После версии 0.6.0 появился серьезно доработанный форк под названием Dokany. Теперь жив только Dokany, и, соответственно, мы будем использовать его. В дальнейшем, говоря о Dokan, я буду подразумевать именно Dokany.

Подготовка

Чтобы использовать Dokan, нам потребуется драйвер. К нашему счастью, есть уже готовые собранные драйверы, которые нужно всего лишь установить. Тут есть три способа.

• Первый — воспользоваться автоматическим установщиком.
• Второй — скачать собранные бинарники (они уже подписаны) и встроить их в свой установщик.
• Ну и третий — скачать исходный код, благо он открыт (часть проекта распространяется по лицензии LGPLv3, часть — по MIT), и собрать все самостоятельно. Плюс такого подхода в том, что мы можем подписать готовый драйвер своей подписью, но на этом плюсы заканчиваются.

Я выбрал первый вариант. Скачать установщик вы можете здесь. Мастер в конце попросит перезагрузить компьютер, что вы и должны сделать. Если после перезагрузки вы увидите драйвер dokan1 . sys , то все сделано правильно. Если нет — можно попробовать установить вручную.

Загруженный драйвер dokan1.sys

Чтобы установить вручную, необходимо скачать более объемный файл. Кроме драйверов, он содержит и нужные вам библиотеки (если вы знаете C++), так что не спешите удалять его после установки.

Нас же сейчас интересует папка x64 (у вас ведь 64 бита?). В ней — набор папок, как на картинке.

Содержимое папки x64

У меня Windows 8.1, так что иду в соответствующую папку (рекомендую Release) и, кликнув по inf-файлу правой кнопкой мышки, выбираю «Установить». Подтверждаю проверку UAC и жду окончания процесса, после чего перезагружаю машину.

Теперь установка должна пройти успешно. Если что-то не получилось — убедитесь, что устанвавливаете ту версию драйвера.

Кроме библиотеки Dokan, нам еще понадобится Visual Studio. Недавно вышла новая версия 2019, так что, даже если у вас уже установлена, очень советую обновиться. С приготовлениями закончили, переходим к кодингу.

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

Кодинг

Итак, открываем Visual Studio и создаем новый проект типа Console App (.NET Framework). На скриншоте видно, что целевой фреймворк — 4.5.2, но минимально поддерживаемый — 4.0. Так что, если ваш компьютер не поддерживает 4.5.2, вы знаете, что делать.

Проект создан, и теперь нашему взору предстала заглушка метода Main. Вы ведь установили NuGet вместе со «Студией»? Если нет, устанавливайте. Оттуда мы ставим пакет DokanNet (Tools → NuGet Package Manager → Manage NuGet Packages for Solution). Любители командной строки могут открыть PowerShell-консоль NuGet (Tools → NuGet Package Manager → Package Manager Console) и выполнить Install — Package DokanNet .

Чтобы создать свою файловую систему, нам нужен класс, реализующий IDokanOperations . Создаем новый класс ( Ctrl + Shift + A ) и добавляем туда using DokanDet ; . Наш класс должен реализовывать интерфейс IDokanOperations , так что исправляем class XakepFSClass на class XakepFSClass : IDokanOperations .

Как вы видите, в 10-й строке ошибка. Конечно, мы же унаследовали кучу методов от интерфейса, но не реализовали их. Я знаю, вы не хотите объявлять каждый метод вручную, поэтому поставьте курсор на неугодное выражение ( IDokanOperations в 10-й строке) и нажмите Alt-Enter. В появившемся меню выберите Implement interface.

Теперь порядок! Но все методы выкидывают исключение NotImplementedException, что нам никак не подходит. Давайте реализуем Hello World, а затем — файловую систему, хранящую все данные в JSON.

HelloWorldFS

Поскольку это просто Hello World, мне не хочется изменять файл, который мы только что создали. Сделаем его копию, переименуем для лучшего восприятия (для переименования выберите файл в правой панели и нажмите F2). Теперь откроем наш новый класс и переименуем и его, а то компилятор не поймет наши фокусы. У вас должно получиться как на скриншоте.

Если попробовать запустить сейчас, то ничего не выйдет. Файловую систему сначала нужно смонтировать. Давайте добавим в Program . cs такую строчку:

Это смонтирует нашу файловую систему на диск M : . У вызова Mount есть дополнительные параметры, которые я рассмотрю в конце статьи.

Если запустить теперь, то спустя несколько секунд мы получим ошибку, гласящую, что метод public NtStatus CreateFile , который вызывается при каждой попытке записать или прочитать файл, не реализован, и это нужно исправлять. Вообще, для корректной работы файловой системы необязательно реализовывать все функции, но некоторые придется. Список таких функций:

• CreateFile;
• Mounted;
• GetFileInformation;
• GetDiskFreeSpace;
• Cleanup;
• CloseFile;
• GetVolumeInformation;
• FindFilesWithPattern;
• DeleteDirectory;
• DeleteFile;
• Unmounted.

Теперь пройдемся по реализации. Функции Cleanup и CloseFile не несут решительно никакой полезной нагрузки, так что просто удаляем из них весь код. GetDiskFreeSpace (как ни странно!) отвечает за отображение свободного и занятого места на диске. Я сделал просто возврат статических значений, однако в реальной ситуации (мы ее рассмотрим позже) уже будем вычислять и отдавать актуальные данные.

Функции CreateFile , DeleteDirectory , DeleteFile , Mounted и Unmounted нас тоже пока что не интересуют. Во всех них мы напишем просто return NtStatus . Success ; , чтобы не выпадали ошибки. А вот от GetFileInformation , GetVolumeInformation и FindFilesWithPattern мы так просто не отвяжемся. Они требуют результаты через переменные с модификатором out , так что мы даже не сможем их скомпилировать. Чтобы заставить замолчать и их, придется поместить следующий код:

GetFileInformation

FindFilesWithPattern

GetVolumeInformation

Эта последняя функция интересна тем, что мы можем сами задать любую метку тома (строка 1), название файловой системы (строка 3) и максимальную длину пути (строка 4). Я не стал ломать традиции и оставил максимальную длину пути равной 256 символам, но это ограничение мы уберем, когда дойдем до более реального примера.

Теперь можно все сохранить и запустить. Если вы все сделали правильно, то красивое черное окошко вывалит вам кучу текста, как на скриншоте, а в папке «Компьютер» появится новый локальный диск!

Результат запуска

У новоиспеченного диска даже можно просмотреть свойства (см. скриншот ниже), но не пытайтесь его открыть, так как получите NotImplementedException в ReadFile .

Чтобы исправить эту досадную проблему, придется реализовывать не только метод ReadFile (это само собой), но и FindFiles , FindFilesWithPattern , FlushFileBuffers , GetFileSecurity и GetFileInformation . Поскольку это всего лишь Hello World, давайте будем возвращать только один текстовый файл с содержимым «Hello World from HelloWorldFS!\r\nThis is just a test file.» .

В FindFiles напишем вот такую заглушку:

В FindFilesWithPattern напишем return FindFiles ( null , out files , null ) ; , а в FlushFileBuffers — return NtStatus . Success ; .

GetFileInformation

GetFileSecurity

ReadFile

После этих ухишрений программу можно запускать и открывать наш новый диск. Теперь там лежит файл HelloWorld . txt . Он даже открывается, хотя мы и не сможем сохранить его, если изменим ( WriteFile выдаст NotImplementedException ). Это вы сможете реализовать сами, так как сохранение данных не входит в задачи нашего простого примера.

Наш Hello World работает!

Если у вас что-то не получилось — посмотрите готовый код HelloWorldFS на Pastebin.

XakepFS

Переходим к «боевому» проекту! Для интереса будем не просто сохранять файлы, а превращать их в JSON. Зачем хранить файлы в JSON? Ну например, чтобы сохранить атрибуты и метаданные при сохранении в каком-нибудь сервисе, который их не поддерживает. Для примера возьмем GitHub, но в реальности таких сервисов масса.

Как правило для сохранения метаданных файлов в такой системе пришлось бы паковать все в архив или вытаскивать метаданные и хранить отдельно (и потом возвращать их на место — тот еще гемор). Нам же будет достаточно смонтировать нашу папку на какой-нибудь диск.

Работа с JSON в .NET

Думаю, рассказывать, что такое JSON, излишне, поэтому поговорим о том, как с ним работать в .NET. Как вы (наверное) знаете, в стандартной библиотеке нет средств для работы с ним. Конечно же, существует стороннее решение, оно называется Json.NET. Плюс этой библиотеки в том, что она умеет запаковывать в JSON и распаковывать из него все, что угодно, а не только строки и числа.

Скачать библиотеку Json.NET можно из NuGet.

Использовать JSON мы будем следующим образом.

1. Создадим объект корневой директории и монтируем диск.
2. При обращении к файлу на чтение или запись вытаскиваем из JSON-хранилища адрес файла с данными запрошенного объекта виртуальной файловой систему и отдаем или пишем уже его данные. Это нужно для того, чтобы при копировании на наш диск, например фильма, мы сбрасывали в JSON только метаданные. Файл не будет разрастаться до неимоверных размеров.
3. При необходимости можно добавить любые функции. Например, шифрование: добавляем в JSON поле для хеша ключа шифрования, его соль и сам зашифрованный ключ. А процедуры чтения и записи будут проверять и использовать эти поля. Можно даже сделать шифрование не для всех файлов. В общем, большой простор для фантазии!

Структура объекта файловой системы

Каждая запись об объекте файловой системы должна хранить:

• имя объекта;
• тип объекта (файл/папка);
• путь к объекту;
• дату и время создания;
• дату и время последнего доступа;
• дату и время последнего изменения;
• размер;
• права доступа;
• атрибуты;
• метаданные (автор, комментарий, подпись, версия и так далее).

Чтобы можно было расширять и переименовывать объекты нашей файловой системы, мы не станем указывать абсолютные пути к файлам, а будем хранить индекс родительского объекта. Такой подход используется во всех современных файловых системах, таких как NTFS и ext4, и, как видите, работает. При удалении мы просто пометим запись как удаленную, не удаляя ее саму. В общем, все как у больших. Приступим к написанию.

Реализация объекта файловой системы

Создадим еще один класс (Ctrl-Shift-A) и назовем его, например, XakepFSObject .

Теперь добавляйте следующие поля (все с модификатором public ; также их нужно инициализировать пустыми значениями — «» для строк, для чисел, false для булевых и DateTime . Now для DateTime ):

• String Name
• bool IsDirectory
• int Parent
• int ObjectID
• DateTime CreatedTime
• DateTime LastWriteTime
• DateTime LastAccessTime
• long Length
• FileAttributes Attributes (нужен System . IO )
• FileSystemSecurity AccessControl (нужен using System . Security . AccessControl )
• String DataLocation

Теперь подумаем. Наша файловая система будет работать в один поток (пока что) и, значит, при каждом обращении парсить весь JSON будет слишком медленно. Поэтому мы пожертвуем компактностью JSON в пользу скорости работы. Каждый объект нашей файловой системы будет иметь метод, упаковывающий его в строку JSON, и еще один, который будет распаковывать его. Мудрить с названиями не будем: назовем эти методы PackJson и UnpackJson соответственно. Вот их код.

PackJson

UnpackJson

Внимательный читатель, конечно, заметил странные функции PackObject и UnpackObject . Я про них не упоминал, так как они содержат всего по одной строчке кода.

PackObject

UnpackObject

Для чего это нужно? Не знаю, как у вас, но у меня при использовании словаря типа Dictionary < String , Object > после десериализации операции приведения к нужному типу возвращали null для многих типов, в то время как хранение каждого объекта отдельно и десериализация при инициализации объекта проходит нормально. Из-за этой проблемы я и решился на такой ход. Также у меня возникла проблема с десериализацией объектов типа FileSystemSecurity , поэтому пока что чтение/запись прав доступа будут отдавать null . Впрочем, пока эта файловая система управляется нашей программой, плевать нам хотелось на любые права доступа. Наша же программа с легкостью переназначит их, когда это будет нужно.

От простых объектов, вроде тех, что мы сейчас накодили, толку мало. Поэтому

можете удалять этот класс

создавайте еще один класс, который будет хранить дерево файловой системы и реализует основные операции с файлами. Назовем мы его XakepFSTree . Готовую реализацию вы сможете найти на GitHub.

Как прикрутить все это к нашему основному классу XakepFSClass ?

Банальный Hello World у нас уже был, на этот раз реализовывать придется все. Ну или почти все. Часть кода я позаимствовал из RegistryFS и слегка адаптировал, поэтому он может пересекаться с существующим.

Пример главной функции вы можете посмотреть в файле XakepFSClass.cs. Это — главная функция. Она отвечает за создание и открытие файлов, проверку существования файлов и много чего еще. Самое интересное тут не то, как мы создаем файл или проверяем его существование, а то, как мы обрабатываем переименованные файлы.

Сами файлы хранятся отдельно, а в JSON мы пакуем лишь метаданные. Вот только при переименовании файла в файловой системе записи в JSON обновятся, а на диске файлы-хранилища — нет. Поэтому, если мы создадим, например, файл example . txt , переименуем его и попробуем создать там еще один example . txt , мы получим ошибку, гласящую, что файл уже существует и создать новый с таким именем нельзя. Так не пойдет, поэтому я решил сделать очередной костыль: файлы-хранилища будут называться случайными именами без расширений.

Чтобы сделать действительно случайное имя, я беру относительный путь к файлу в виртуальной файловой системы, дописываю в конец текущую дату и время и беру от этой строки хеш MD5. Все, теперь создание множества файлов с одинаковыми именами не вызывает проблем! Естественно, этот же финт работает и для папок. Если нет жеалния изобретать велосипед, можете взять мою функцию хеширования, мне не жалко!

public NtStatus FindFilesWithPattern

В этом методе — шикарный пример того, как делать не стоит. По сути, это просто обертка вокруг «обычной» FindFiles , только эта оболочка проверяет, что было передано в маску для поиска. За время тестирования я обнаружил, что чаще всего там (в searchPattern ) лежит звездочка либо имя файла. Вот только у меня, когда передавалось имя файла, префикс мог быть / , мог быть \ , а мог и вообще отсутствовать. Не знаю, с чем это связано, но я перестраховался и сделал проверку на случай всех трех вариантов.

public NtStatus GetFileInformation

Из названия метода понятно, что мы отдаем метаданные о файле, подтягивая их из JSON. Самой работы с JSON вы здесь не увидите, она спрятана под капотом объекта класса XakepFSTree , который у меня называется FSTree и содержит среди прочего методы для создания и удаления файлов в одну строку. Прошу прощения, если это осталось непонятным при изучении кода двух прошлых методов.

Предпоследняя строка этого метода может вызвать справедливые вопросы у читателя. Поясняю: во время работы мы как правило не очищаем память за объектами, которые не используем. Поскольку функция GetFileInformation вызывается часто, имеет смысл поместить код очистки памяти (на самом деле просто вызов штатного сборщика мусора) здесь. Если вы хоть раз имели дело со средой CLR, то знаете, что на время работы сборщика мусора приостанавливается вообще вся программа, а не только поток, его вызвавший. Поэтому в этом методе мы вызываем сборщика с шансом 1/9.

public NtStatus ReadFile

Этот метод — святая святых нашей файловой системы, поскольку именно он отвечает за чтение данных. Тут все вроде бы просто: сначала создаем поток, затем читаем из него. При возникновении ошибки (обычно — файл занят другим потоком) повторить попытку. Но даже в таком простом методе я благополучно допустил ошибку, из-за которой вы не увидели эту статью еще неделю назад. Суть — лучше не изобретать велосипед и воспользоваться готовым решением, что я в итоге и сделал.

public NtStatus WriteFile

И на закуску — последний на сегодня и почти не уступающий по важности предыдущему метод. Он отвечает за запись в файлы. Тут все по аналогии с ReadFile , только доступ к файлу (последний аргумент конструктора FileStream ) мы указываем Write .

Параметры монтирования Dokan

При помощи Dokan вы можете создавать новые диски, монтировать существующие и делать многое другое. Особого внимания заслуживает возможность создания дисков любого типа (да, не только локальные!) и разграничивать к ним доступ. Можно разрешить вашей файловой системе использовать несколько потоков. Все это передается в параметрах вызова Mount в классе Dokan . Рассмотрим эту процедуру подробнее.

Вообще, Dokan — штука потрясающе многофункциональная. Можно монтировать как файловую систему что угодно, даже системный реестр.

Первый параметр — это объект класса файловой системы, реализующий интерфейс IDokanOperations . Тут нет ничего запредельного, просто передаем new XakepFSClass ( ) , и дело с концом.

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

Третьим параметром идет нужная комбинация элементов перечисления DokanOptions . Когда мы не указываем этот параметр, он по умолчанию становится равен нулю, что соответствует DokanOptions . FixedDrive . Это значение предписывает драйверу Dokan смонтировать обычный локальный диск. Другие значения позволяют выбрать другой тип диска. Самые интересные параметры — это NetworkDrive и RemovableDrive .

Естественно, из трех этих параметров в один момент времени можно использовать только один. С ними можно комбинировать CurrentSession , который заставит смонтировать этот диск только для текущего пользователя, MountManager , который сделает диск доступным для системного менеджера монтирования, и WriteProtection , чтобы заставить Dokan пометить диск как доступный только для чтения. По факту операции записи все равно могут передаваться в наше приложение, так что не забудьте дописать return NtStatus . Error ; в метод WriteFile .

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

В пятом аргументе мы передаем версию. Какую? Я передаю туда Dokan . Version , но есть подозрение, что этот аргумент вообще ни на что не влияет.

В шестой параметр можно положить информацию о промежутке времени (объект TimeSpan ), по прошествии которого файловая система будет автоматически отмонтирована, если пользователь не совершает с ней никаких действий.

Ну и наконец, седьмой параметр — путь к сетевой шаре в формате UNC ( \ SERVER \ Share ). Этот аргумент имеет смысл выставлять, только если в третьем аргументе указано, что это NetworkDrive . В противном случае он будет проигнорирован.

Тестируем

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

Теперь фотографии: я взял одну в JPG, а другую в PNG. Они также успешно записались на диск и нормально открылись.

Но все эти файлы не превышали мегабайта по объему. Как же наша файловая система поведет себя с большими файлами? Проверим, положив туда PDF-файл. Скопировался он очень быстро, я едва успел сделать скриншот, и открылся тоже нормально.

Как видите, все работает.

Выводы

Сегодня мы рассмотрели создание несложной (по возможности!) файловой системы. В отличие от FUSE, с Dokan нельзя написать всего пару строчек кода, чтобы заставить файловую систему работать. Зато логи ведутся подробнейшие прямо в консоли, что позволяет в случае чего без особых трудностей выловить ошибку и исправить ее. Лично мне это очень пригодилось, так что будьте готовы!

Также Dokan позволяет настроить любую мелочь, чего не сказать про FUSE, и, конечно же, стабильная и беспроблемная работа в Windows — несомненный плюс. Проект активно развивается, так что не забывайте своевременно обновляться. И еще один момент: если тоже будете делать что-то с Dokan (особенно на C++), не забудьте запостить в комментарии к статье ссылку на свой проект!