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

Программы для создания разделов на жестком диске

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

Acronis Disk Director

Комплексный программный продукт для работы с HDD, SDD и внешними накопителями, предоставляющий широкие возможности для управления ими. Acronis Disk Director позволяет создавать новые разделы, изменять размер существующих, объединять их, перемещать, копировать, переименовывать, менять тип и атрибуты, скрывать, форматировать, удалять, конвертировать файловую систему без потери данных и решать многие другие задачи.

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

Active Partition Manager

Значительно более скудная в плане функциональности программа, если сравнивать ее с предыдущей, но все же предоставляющая возможность решения нашей сегодняшней задачи. К созданию нового тома на диске можно перейти прямо из главного окна Active Partition Manager. Там же представлен менеджер разделов, позволяющий менять их размер, атрибуты и имя, а также выполнять форматирование. Помимо установленных в компьютере накопителей, поддерживается работа с внешними устройствами, в числе которых флешки, CD, DVD.

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

AOMEI Partition Assistant

Еще одно многофункциональное приложение для выполнения различных операций над дисковыми разделами. В числе таковых создание новых, изменение размера, разделение и объединение, копирование, перемещение, распределение свободного пространства, конвертирование файловой системы и многое другое. AOMEI Partition Assistant содержит в своем составе десять Мастеров – утилит для быстрого решения специфических задач по типу переноса операционной системы с HDD на SSD, ее резервного копирования и восстановления, а также создания загрузочных накопителей и записи образа Windows To Go.

Интерфейс рассматриваемой программы мало чем отличается от Acronis Disk Director и большинства других представителей данного сегмента. Он состоит из трех областей – основная рабочая во многом напоминает стандартное для Windows средство «Управления дисками», выше расположена панель с инструментами, а слева – меню быстрых действий. Как и уже упомянутый конкурентный продукт, этот является платным, однако основные и необходимые действия могут быть выполнены и в пробной версии.

EaseUS Partition Master

Мощная программа для работы с устройствами хранения данных и их разделами, которая, как и рассмотренный выше продукт AOMEI, наделена собственными Мастерами. С их помощью можно клонировать операционную систему, перенести ее с одного диска на другой, копировать раздел, очистить, а также полностью затереть данные, после чего их будет невозможно восстановить. Конечно же, EaseUS Partition Master позволяет создавать новые разделы, объединять и/или расширять существующие, скрывать их, менять буквы, метки, атрибуты, а также редактировать некоторые другие параметры.

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

Eassos PartitionGuru

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

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

Macrorit Disk Partition Expert

Софт для работы с дисковыми устройствами, который, как и рассмотренный выше Eassos PartitionGuru, позволяет создать новый том путем «отделения» области от существующего. Конечно, это далеко не единственная функция программы. С ее помощью можно разбить диск на разделы, изменить их размер, выполнить копирование, удаление, изменить букву, добавить атрибут и т.д. В составе Macrorit Disk Partition Expert имеется инструмент для проверки накопителя на ошибки и битые сектора, есть конвертер MBR в GPT (без удаления данных).

Приложение поддерживает работу с дисками всех известных производителей, в том числе и имеющими объем более 2 Тб, а также с файловыми системами FAT32 и NTFS. Позволяет их форматировать, безвозвратно стирать сохраненные данные, выполнять дефрагментацию. Как и Active Partition Manager, этот софт распространяется бесплатно (для домашнего пользования). Доступен исключительно английский язык интерфейса, но ввиду простоты и сходства с большинством подобных решений, разобраться с ним не составит труда.

MiniTool Partition Wizard

Продвинутое и многофункциональное программное решение, которое, как и рассмотренные выше продукты Acronis, AOMEI и EaseUS, содержит в себе все необходимые инструменты для эффективной работы с HDD и SSD. В этой программе можно управлять дисковыми разделами и делать абсолютно все – от создания новых до полного удаления существующих. MiniTool Partition Wizard предоставляет возможность изменения файловой системы тома и размера кластера, содержит в своем составе утилиту для тестирования поверхности накопителя. Есть набор встроенных Мастеров как в Partition Assistant, с которым это приложение имеет много общего.

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

Paragon Partition Manager

Менеджер для работы с дисками, который отличается от большинства подобных программ, по крайней мере, если говорить исключительно об интерфейсе. В функциональном плане этот софт близок к Active Partition Manager и Eassos PartitionGuru – не слишком богато, но для решения базовых задач, в числе которых и создание нового тома, его будет достаточно. Среди дополнительных возможностей стоит отметить инструменты для создания загрузочных накопителей и виртуальных HDD.

Данная программа поддерживает распространенные файловые системы (FAT32, NTFS, Apple NFS и HFS+) и содержит в своем составе продвинутый конвертер. С помощью последнего можно преобразовать используемый в среде Windows формат в стандартный для macOS и/или наоборот, благодаря чему данные, сохраненные на компьютере с одной ОС, могут быть легко просмотрены в среде другой. Интерфейс приложения переведен на русский язык, а распространяется оно на платной основе. Имеется пробная версия, наделенная необходимой для работы с дисками функциональностью.

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

Создание своей файловой системы для 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++), не забудьте запостить в комментарии к статье ссылку на свой проект!

Как создать файловую систему 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.

DGFS — быстрая файловая система своими руками

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

Есть мнение, что специализированная read-only файловая система при прочих равных обладает преимуществами перед оной общего назначения т.к:

1. не обязательно управлять свободным пространством;
2. не надо тратиться на журналирование;
3. можно не заботиться о фрагментации и хранить файлы непрерывно;
4. возможно собрать всю мета-информацию в одном месте и эффективно ее кэшировать;
5. грех не сжимать мета-информацию, раз уж она оказалась в одной куче.

Задача

100 млн небольших файлов (по

Железо

В первую очередь, диск: все эксперименты проводятся на выделенном Seagate Barracuda ST31000340NS емкостью 1 Tb.
Операционная система — Windows XP.
Процессор: AMD Athlon II X3 445 3 Ггц.
Память: 4 Гб.

Характеристики диска

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

На представленном графике отображены гистограммы времен чтений с диска в произвольных позициях. По оси абсцисс отложена длительность позиционирования и чтения. По оси ординат — число попаданий в корзину шириной в 0.1 msec.

Обращения к диску производились штатным образом:

• открытие через CreateFile(«\\\\.\\PhysicalDrive1». );
• позиционирование через SetFilePointer;
• и чтение посредством ReadFile.

• all — позиционирование идет по всему диску;
• ½ — только по его младшей половине и т.д.

А здесь показаны мат. ожидания и ошибки из предыдущего графика, ось абсцисс в логарифмической шкале, например, 1/16 соответствует 4 (1/2**4).

Какие выводы можно сделать?

1. В худшем случае (случайный поиск) матожидание одного чтения составляет 13 msec. То есть больше 80 случайных чтений в секунду с этого диска сделать нельзя.
2. На 1/256 мы впервые видим попадания в кэш.
3. На 1/1024 в кэш начинает попадать ощутимое количество чтений

Попробуем создать файл размером с диск и получить временные характеристики работы с ним. Для этого создадим файл соизмеримого с файловой системой размера и будем читать его в случайных местах штатными _fseeki64/fread.

На графике аналогичные представленным ранее гистограммы. А две из них, помеченные как (disc), взяты из предыдущего графика. Парные же им гистограммы, помеченные как (file), получены на основании замеров файловых чтений. Что можно отметить:

1. Времена близки.
2. Хотя файл составляет 90% от файловой системы (9хЕ11 байт), чтение из него на полном размере в среднем почти на миллисекунду медленнее.
3. Дисковый кэш для файла работает лучше, чем для диска.
4. Появились хвосты в

NTFS с иерархией

Вспомним уже про нашу тестовую задачу и попробуем решить ее в лоб — средствами файловой системы. Тут же выясняется, что:

1. Это занимает довольно много времени, на создание одной ветки из миллиона файлов уходит около получаса с тенденцией к постепенному замедлению по мере заполнения диска в соответствии с нашим первым графиком.
2. Создание всех 100 млн. файлов, следовательно, заняло бы 50+ часов.
3. Поэтому мы сделаем замеры на 7 млн файлов (

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

• Две серии -— 7 млн как 1/16 задачи и 1 млн для калибровки.
• В серии 10000 измерений, в корзине 0.5 msec.
• Общее время 1/16 теста — 7’13’’ то есть матожидание — 43 msec.
• Общее время 1/100 теста — 5’20’’ то есть матожидание — 32 msec.

А теперь взглянем на то же в единицах условных seek’ов:

• Что 1/16, что 1/100, слишком велики, чтобы их сколь-нибудь эффективно кэшировать. А файлы наши слишком малы для фрагментации.
• Поэтому 1 seek мы должны заплатить за чтение собственно данных. Все остальное — внутренние дела файловой системы.
• Максимумы приходятся на 3.5 (для 1/100) и 4 (для 1/16) seek’а.
• А матожидания вообще на 4. 5.
• То есть, чтобы добраться до информации о том, где хранится файл, файловой системе (NTFS) приходится делать 3-4 чтения. А иногда и больше 10.
• В случае полной задачи, надо полагать, ситуация не улучшится.

Прототип

Построим прототип нашей read-only файловой системы:

1. Состоит он из двух файлов — данных и метаданных.
2. Файл данных — просто записанные подряд все файлы.
3. Файл метаданных — В-дерево с ключом — идентификатор файла. Значение — адрес в файле данных и его размер.
4. Под идентификатором файла понимается закодированный путь к нему. Вспомним, что наши данные расположены в трехуровневой системе директорий, где каждый уровень кодируется числом от 0 до 100, аналогично и сам файл. Вся эта структура упаковывается в целое число.
5. Дерево записано в виде 4К страниц, применяется примитивное сжатие.
6. Для того, чтобы избежать фрагментации, указанные файлы приходится создавать в разных файловых системах.
7. Просто дописывать данные в конец файла (данных) оказывается неэффективно. Чем больше файл, тем дороже обходится файловой системе (NTFS, WinXP) его расширение. Чтобы избежать этой нелинейности, приходится предварительно создать файл нужного размера (900 Гб).
8. Занимает это предварительное создание больше 2 часов, всё это время уходит на заполнение этого файла нулями, видимо, из соображений безопасности.
9. Столько же времени занимает и заполнение этого файла данными.
10. Построение индекса занимает около 2 минут.
11. Напомним, всего 100 млн файлов, каждый размером около 8К.
12. Файл индекса занимает 521 Мб. Или

5 байт на файл. Или

• «alone» — под этой меткой идет файл данных, расположенный отдельно от индексного файла, на другом физическом диске;
• «ogether» — и файл данных и индекс расположены в пределах одной файловой системы на одном физическом диске;
• «index only» — осуществляется только поиск информации о файле в индексе без чтения собственно данных;
• «with compr. index» — то же, что и «together», но со сжатым индексом;
• «compr. index only» — то же, что и «index only», но со сжатым индексом;
• всего 10000 чтений, шаг гистограммы 0.1 msec.

Выводы:

1. Качество сжатия индекса почти не влияет на скорость работы. На разжатие страниц тратится процессорное время, но зато лучше работает кэш страниц.
2. Чтение индекса выглядит как одно чтение из файла соответствующего размера (см. первый график). Так как 512 Мб — это 1/2000 диска, среднее время seek’а должно быть около 6.5 msec, плюс надбавка за то, что мы читаем из файла, а не напрямую с диска. Судя по всему, это оно и есть. Дерево индекса трех-уровневое, верхние два уровня очень быстро оказываются в кэше, а нижний уровень страниц кэшировать бессмысленно. В результате, любой поиск в дереве вырождается в единственное чтение листовой страницы.
3. Если файл данных и индексный файл расположены на одном физическом диске, общее время поиска равно двум случайным seek’ам на полное расстояние. Один на чтение данных и один на переход к индексному файлу, который расположен либо в самом начале, либо в самом конце диска.
4. Если же файлы разнесены по разным устройствам, мы имеем один полный seek на чтение данных и один короткий на поиск в индексе. Учитывая, что индексный файл относительно невелик, напрашивается естественное решение — если нам нужно хранилище в несколько (десятков) терабайт, надо готовить выделенный диск под индекс (SSD) и несколько дисков под данные. Это может быть оформлено как JBOD и внешне выглядеть как обычная файловая система.
5. Эта схема обладает важной особенностью — гарантированным временем ответа, чего трудно добиться в обычных файловых системах, например, для использования в системах реального времени.

Ответ такой — принципиально ничего не изменится. По-прежнему будет один основной индекс. Но устроен он будет немного по-другому.

Выше идентификатором файла (ключом индекса) был закодированный путь к нему. Так и будет, ключ — строковый полный путь к файлу. Всё остальное в значении — размер, положение, владелец, группа, права…

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

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

Но ведь пути файлов занимают кучу места? Да, но файлы в одной директории имеют общий префикс, который можно хранить только один раз. Общий суффикс тоже частое явление. Чтобы понять объем данных, которые надо хранить, был проделан ряд экспериментов с путями файловой системы, которые показали, что они с помощью bzip2 (BWT+suffix sort + huffman), сжимаются в среднем в 10 раз. Таким образом, остается 5-6 байт на файл.

Суммарно можно рассчитывать на 10-16 байт на файл, или

2 байта на килобайт данных, (если средний файл 8К). На терабайтный файл надо 2 гигабайта индекса, обычный 64-гигабайтный SSD-диск, следовательно, способен обслужить 32 терабайта данных.

Аналоги

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

Примерным аналогом можно считать использование СУБД для хранения данных. В самом деле: храним содержимое файлов как BLOB’ы, а метаданные, как атрибуты таблицы. Просто и изящно. СУБД сама заботится о том, как поэффективнее расположить файлы в доступном ей дисковом пространстве. Сама создает и поддерживает все нужные индексы. Плюс приятный бонус — мы можем менять наши данные без ограничений.
Однако:

• В конечном счете, СУБД всё равно обращается к диску, напрямую или через файловую систему. А это таит опасность, стоит недоглядеть и — бац! время работы замедлилось в разы. Но, допустим, у нас идеальная СУБД, с которой этого не произойдёт.
• СУБД не сможет сжать префиксы столь же эффективно просто в силу того, что не рассчитана на read-only режим.
• То же самое можно сказать и про метаданные — в СУБД они будут занимать гораздо больше места.
• Больше места — больше чтений с диска — медленней работа.
• Использование хэш-кодов от пути файла не решает проблемы т.к. соответствие пути хэш-коду всё равно надо где-то хранить просто для того, чтобы обеспечить возможность просмотра содержимого директории. Выльется всё в то, что придется воспроизвести структуру файловой системы средствами СУБД.
• Файлы размером больше страницы будут принудительно разбиты СУБД на части, и произвольный доступ к ним будет осуществляться в лучшем случае за логарифмическое от размера файла время.
• Если мы можем просто разместить все метаданные на выделенном SSD диске, в случае СУБД сделать это будет намного сложнее.
• Про гарантированное время отклика можно забыть.

Транзакционность

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

Итого

Итак, представлен прототип read-only файловой системы, который прост, гибок, решает тестовую задачу и при этом: