Программное обеспечение → Управление файловыми системами и его разработка; Компьютерные системы → Надежность.
Когда функция sparse_super2 включена, и размер параметр для параметра resize2fs больше размера Ext4, расширение файловой системы приводит к повреждению метаданных.
Файловые системы (FS) играют важную роль в современном обществе для управления ценными данными. Для удовлетворения различных потребностей файловые системы часто проектируются с большим набором настроек параметров, управляемых с помощью множества утилит (например, mke2fs [40], resize2fs [53]), что позволяет конечным пользователям настраивать систему с различными компромиссами. Например, файловая система Ext4 содержит более 85 параметров конфигурации с различными типами, комбинация которых составляет более 1037 состояния конфигурации [8].
В то время как параметры конфигурации улучшили систему гибкость, они вносят дополнительную сложность для повышения надежности. Тонкие проблемы корректности часто зависят от конкретных параметров триггеры [13, 69]; следовательно, они могут не поддаваться интенсивному тестированию и негативно влиять на конечных пользователей. Например, в декабре 2020 года пользователи Windows заметили, что средство проверки ChkDsk использовало ошибка файловой системы NTFS уничтожила NTFS на SSD [33, 63]. Позже было подтверждено, что проблема требовала двух конкретных параметров для манифеста: параметр '/f' в ChkDsk и еще один (безымянный) параметр в операционной системе Windows для управления системой (ОС) [62].
Аналогично, на Рис. 1 показана другая конфигурация, связанная с проблемой, связанной с Ext4 и утилитой resize2fs [53]. Два недостатка для запуска ошибки должны сохраняться обозначения: (1) функция sparse_super2 включена в Ext4 (через mke2fs); (2) значение размер параметр из resize2fs должно быть больше размера из Ext4 (т.е. расширение файловой системы). После запуска эта работа будет запущена. ошибка приведет к повреждению метаданных Ext4 неправильными свободными блоками. Основная причина проблемы была логичной, т.е. для конкретных параметров конфигурации учитываются свободные блоки. последняя группа файловой системы была рассчитана перед добавлением. новые блоки в файловой системе во время расширения.
Из-за комбинаторного взрыва конфигурационных состояний и значительное время, необходимое для тщательного изучения файловых систем для каждого состояния конфигурации [11], практически невозможно исчерпать все состояния для тестирования сегодня. Более того, с ожидается появление все большего количества разнородных устройств (например, SmartSSD [59]) и расширенных функций (например, DAX [14]). ожидается, что потенциальные состояния конфигурации файловых систем будут быстрый рост. Следовательно, крайне необходимы эффективные методы, помогающие улучшить работу тестирование, связанное с конфигурацией, и эффективное выявление критических проблем конфигурации.
Существуют практические наборы тестов (например, xfstest [68]) для обеспечения корректности файловых систем в различных конфигурациях. К сожалению, их охват с точки зрения конфигурации составляет ограничено на основании нашего исследования: менее половины конфигурации
На этом рисунке показаны четыре типичных сценария настройки FS: (a) при создании (например, mke2fs) или во время монтирования (монтировать) перед использованием; (b) с помощью сетевых утилит (например, e4defrag); (c) с помощью автономных утилит (например, resize2fs).
Проблемы, связанные с конфигурацией, также возникали в других программные системы и получили большое внимание [9, 12, 34, 69]. К сожалению, существующие усилия в основном касаются только одного единственное приложение, которое принципиально ограничено в отношении файлов конфигурации системы, включающие несколько компонентов (например, зависимость). Большинство (97,0%) проблем в нашем наборе данных для манифестации требуется соответствие таким сложным зависимостям, что подразумевает сложность проблемы, а также потребность в новом решении.
В этом документе представлен один из первых шагов по решению проблемы усложнение конфигурации файловых систем. Вдохновленный недавнее исследование по проблемам конфигурации в облачных системах [9], мы фокусируемся на зависимость конфигурации, который описывает зависимая связь между параметрами конфигурации. Такой зависимость была идентифицирована как ключевой источник сложных многоуровневых зависимостей это приводит к проблемам с конфигурацией и захвату для улучшения существующей конфигурации необходима отсрочка. дизайн и инструментарий [9, 61, 69].
В то время как базовая концепция зависимости конфигурации содержит было предложено (§ 2), понимание конкретных зависимостей плотности и использование в контексте файловых систем все еще ограничено (насколько нам известно). Поэтому мы сначала изучите потенциальную зависимость Ext4 от конфигурации, файловой системы по умолчанию в Linux, путем тщательного изучения исходного кода и 67 случаев ошибок, связанных с конфигурацией. При этом мы ответьте на один важный вопрос: какая критическая конфигурация зависимости существуют в файловых системах?
Наше исследование выявляет распространенную закономерность, называемую многоуровневый зависимости конфигурации. Многие классические ограничения конфигурации (например, диапазон значений [69]) все еще наблюдаются шаблоны изменениям размера могут повредить файловую систему.
Методы настройки файловых систем отличаются от методов настройки многих приложений, что усложняет задачу. Как показано на рисунке 2, типичная файловая система может быть сконфигурирована с помощью набора утилит на четырех различных этапах:
Обратите внимание, что все утилиты имеют разную конфигурацию параметры для управления их собственным поведением, которые в конечном итоге может повлиять на состояние файловой системы. Более того, проверка параметры могут выполняться как на уровне пользователя, так и на уровне ядра.
| FS (операционная система) | Создание | Монтирование | Онлайн | Автономно |
|---|---|---|---|---|
| Ext4 (Linux) | [40] | [44] | [20], [53] | [18], [53], [64], [67] |
| XFS (Linux) | [43] | [44] | [44] | [65], [66] |
| BtrFS (Linux) | [42] | [45] | [4], [6] | |
| UFS (FreeBSD) | [49] | [73] | [29], [54] | |
| ZFS (FreeBSD) | [71] | [46] | [74], [75] | |
| MINIX (Миникс) | [41] | [48] | - | |
| NTFS (Windows) | [21] | [16] | [10], [15] | |
| APFS (macOS) | [16] | [47] | [16] |
Были созданы практические наборы тестов для проверки корректности файловых систем при различных конфигурациях. К сожалению, из-за сложности конфигураций, их охват с точки зрения конфигурации ограничен. Как показано в таблице 2, используется менее половины параметров конфигурации.
| Тестовый набор | Количество использованных параметров |
|---|---|
| xfstest | 29 (< 34,1%) из >85 |
| e2fsprogs-тест | 6 (< 17.1%) из >35 |
| resize2fs | 7 (< 46.7%) из >15 |
Конфигурационные ограничения определяют требования к конфигурации (например, тип данных, диапазон значений) программного обеспечения [69]. Интуитивно, такая информация поможет определить важные настройки государства, и оно оказалось эффективным для решения конфигурации решать вопросы, связанные с широким спектром применения [9, 34, 69, 70]. Конфигурация зависимостей-это особый тип ограничения описания зависимой корреляции между параметрами, которые показали недавно, чтобы иметь решающее значение для решения ком- плекса проблем с конфигурацией, в облачных системах [9]. Для простоты, мы используем ограничения и зависимости взаимозаменяемо в остальной части статьи.
Ключевая проблема при решении проблем, связанных с конфигурацией, заключается в том, что проблемы файловых систем заключаются в том факте, что файловые системы могут быть настраивается на разных этапах с помощью разных утилит (§2). возможные ограничения могут существовать как в рамках отдельных компонента или нескольких компонентов, которые часто не указано в Экосистемы ФС для решения проблемы с конфигурацией. Для простоты будем называть файловой системой и утилитами, поскольку в экосистеме FS.
Как первым шагом к решению проблемы является проведение исследования репрезентативная экосистема Ext4. Мы представляем наш метод логика (§3.1) и ключевые выводы (§ 3.2) в этом разделе.
Наш набор данных состоит из двух частей: (1) исходный код Ext4 mke2fs, mount, e2defrag, и пять важных утилит (т.е. resize2fs, e2fsck, которые описаны в таблице 3); (2) набор из 67 исправлений ошибок, связанных с конфигурацией, из Ext4 экосистема, которые собираются с помощью следующих двух шагов:
На основе набора данных мы анализируем каждый патч и соответствующие подробный исходный код для понимания логики, который позволяет мы определяем сценарии использования конфигурации, а также ограничения конфигурации, которые являются критическими. Мы резюмируем наши выводы в таблицах 3 и 4 и обсудите их ниже.
| Сценарий использования файловой системы | Описание | # of Ошибка | SD | CPD | CCD |
|---|---|---|---|---|---|
| монтирование | Ext4 создайте и смонтируйте FS для использования | 13 | 13 (100%) | 1 (7.7%) | 13 (100%) |
| mke2fs монтирование | оперативная дефрагментация измените размер смонтированной FS | 1 | 1 (100%) | 0 | 1 (100%) |
| mke2fs mke2fs Ext4 - - mount - Ext4 - e4defrag - resize2fs | измените размер смонтированной FS | 17 | 17 (100%) | 4 (11.1%) | 17 (100%) |
| mke2fs umount - - mount - Ext4 - umount - e2fsck | проверьте согласованность FS | 36 | 36 (100%) | 5 (7.5%) | 34 (94,4%) |
| Итого | 67 | 67 (100%) | 5 (7.5%) | 65 (97,0%) |
Вывод №1: В большинстве случаев (97,0%) используются критические параметры более чем одного компонента. Первый столбец в таблице 3 показаны четыре типичных сценария использования Ext4, которые охватывают все случаи ошибок в нашем наборе данных (всего 67). 97,0% из них случаи ошибок требуют определенных параметров по крайней мере из двух ключевых утилиты (выделены жирным шрифтом) для манифеста. Это отражает сложность вопросы конфигурации, и говорит о том, что мы не можем только рассмотрим один компонент.
Вывод №2: Преобладают многоуровневые зависимости конфигурации. Мы классифицируем ограничения конфигурации, полученные из нашего набора данных, на три основные категории следующим образом:
| Многоуровневая конфигурация. Зависимости | Описание | Существует? | Количество |
|---|---|---|---|
| Самостоятельность (SD) | Тип данных параметр 𝑃 должен быть определенного типа данных (например, integer) | Y | 33 |
| Самостоятельность (SD) | Диапазон значений 𝑃 должно быть в пределах определенного диапазона значений (например, 𝑃 < 4096) | Y | 30 |
| Кросс-Параметр Зависимость (CPD) | Контроль 1𝑃 1из 𝐶 включена/выключена | Y | 4 |
| Кросс-Параметр Зависимость (CPD) | Значение 1𝑃 значен2имеозжавеитсибтыотть𝑃включен, если 𝑃 2) < 𝑃 1 значение s | N | - |
| Кросс-Компонент Зависимость (CCD) | Контроль 1из 𝐶 1𝑃 можно включить МКФ 𝑃 2 2из 𝐶 (например, 𝑃 включено/ отключено) | Y | 1 |
| Кросс-Компонент Зависимость (CCD) | Значение 1𝑃 значение зависит от 𝑃 2 от другого компонента | N | - |
| Кросс-Компонент Зависимость (CCD) | Поведенческий поведение компонента 𝐶1 зависит от 𝑃 2 2of 𝐶 | Y | 5/7 |
| Всего | Y | 64 |
Мы создаем статический анализатор на основе фреймворка LLVM [60] и применяем классический анализ заражения [38] для отслеживания распространения каждого параметра конфигурации по пути потока данных в исходном коде. В частности, мы поддерживаем набор для сохранения переменных начальной конфигурации и любых переменных, производных от переменных начальной конфигурации. Когда в набор добавляется новая переменная, мы также добавляем соответствующую информацию в трассировку заражения. Мы поддерживаем карту для отслеживания того, является ли переменная производной от нескольких параметров. Основываясь на следах заражения, мы далее анализируем зависимости между переменными на основе многоуровневых шаблонов зависимостей, описанных в нашем исследовании. Извлеченные зависимости хранятся в файлах JSON, которые описывают как параметры, так и связанные ограничения.
Существуют различные способы использования зависимостей от конфигурации сложности, включая внедрение ошибок конфигурации [34], con- управление графическими правилами [58], обнаружение de, подверженного ошибкам signs [69], рефакторинг кода и т.д. В качестве отправной точки мы рассматриваем использует три конкретных варианта использования:
В таблице 5 обобщены наши предварительные результаты извлечения многоуровневые зависимости конфигурации с использованием статического анализатора. В целом, мы можем автоматически извлекать 64 уникальные зависимости, включая 32 SD, 26 CPD и 6 CCD. Более частота всех ложноположительных результатов составляет 7,8% (5/64), что сопоставимо с cDEP [9]. Обратите внимание, что наше исследование показало важность идентификация ПЗС (например, 97% в таблице 3), в то время как мы извлекаем только относительно небольшое количество ПЗС в экспериментах. Это происходит главным образом потому, что ПЗС представляет собой сложные взаимосвязи, требующие сложного межпроцедурного анализа. Мы ожидаем извлечь больше зависимостей, особенно CCD, после того, как статический анализатор масштабируется за счет более полного межпроцедурного анализа.
| Сценарий использования файловой системы | Самостоятельная зависимость | Извлеченный FP | Определение параметров. | Извлеченный FP | Определение компонентов. | Извлеченный FP |
|---|---|---|---|---|---|---|
| монтирование | 31 | 1 (4.2%) | 24 | 0 | 0 | 0 |
| mke2fs монтирование | 31 | 0 | 24 | 0 | 0 | 0 |
| изменение размера | 32 | 3 (9.4%) | 26 | 0 | 6 | 1 (16.7%) |
| mke2fs umount - - mount - Ext4 - umount - e2fsck | 32 | 3 (9.4%) | 26 | 1 (3.9%) | 6 | 1 (16.7%) |
| Всего Уникального | 32 | 3 (9.4%) | 26 | 1 (3.9%) | 6 | 1 (16.7%) |
На основе 59 извлеченных истинных зависимостей, мы определили выявили 12 неточных проблем с документацией. Например, там есть межпараметрическая зависимость в mke2fs указывающая, что meta_bg и resize_inode не могут использоваться вместе, что в руководстве отсутствует сопоставление параметров различных компонентов. Более того, мы нашли один случай непредвиденной обработки конфигурации, когда resize2fs может повредить файловую систему.
Анализ конфигураций программного обеспечения. Параметры конфигурации были хорошо изучены во многих программных приложениях [9, 12, 13, 34, 69]. Например, ConfErr [34] манипулирует параметрами для имитации человеческих ошибок; ConFu [13] размывает аннотированные переменные в файлах конфигурации и тестирует выбранные функции. Как правило, в этих работах не рассматриваются глубокие зависимости программного обеспечения. Ближайшей работой является cDEP [9], которая рассматривает зависимости конфигурации в облачных системах (например, Hadoop, OpenStack). cDEP учитывает межкомпонентная зависимость различия, которые отличаются от наших межкомпонентных различий зависимости, поскольку компоненты Hadoop совместно используют XML-файлы файлы конфигурации и используют универсальные библиотеки конфигурации [1], что делает их эквивалентными одной программе с точки зрения конфигурации. Напротив, зависимости в нашем исследовании могут варьироваться между разными программами и границей между пользователем и ядром. Кроме того, cDEP полагается на фреймворк Java, который не может обрабатывать Файловые системы на основе C.
Надежность файловых систем. Были предприняты большие усилия для повышения надежности файловых систем [3, 22, 35, 39, 51] и их утилит [27, 28, 30, 56, 57]. Например, Прабхакаран и др. [51] анализируют политики сбоев четырех файловых систем и предлагают улучшенные проекты на основе таксономии IRON; Spiffy [56] создает язык аннотаций для разработки корректных утилит; SQCK [30] и RFSCK [27] улучшают средства проверки файловой системы, чтобы избежать неточных исправлений. Несмотря на эффективность, эти работы не рассматривают вопросы многокомпонентной конфигурации. Зависимости, полученные в этом документе, потенциально могут быть интегрированы с существующими инструментами для улучшения их охвата. Поэтому мы рассматриваем их как взаимодополняющие.
Работа, представленная в этом документе, предлагает множество возможностей связи для дальнейших улучшений и последующих исследований, например: Автоматизация, интеграция, оценка и открытый исходный код. Наши текущие статического анализа требует определенных ручного annota- ний, которые, как мы надеемся, чтобы уменьшить. Также, мы будем в полной мере реализовать межпроцедурный анализ и интеграция с дополнительными инструменты (например, фаззеры) для повышения эффективности. Мы планируем применить методологию для анализа других популярных программ с открытым исходным кодом файловые системы (например, XFS, BtrFS) и оценивать с учетом большего количества metric (например, ложноотрицательные результаты, накладные расходы). В конечном итоге мы надеемся на превратите прототип в практичный инструмент с открытым исходным кодом для решения проблем с конфигурацией хранилища в целом.
Авторы хотели бы поблагодарить анонимных рецензентов за их ценные отзывы. Мы также благодарим Рунчжоу Хана и Вэй Сюя за их помощь в воспроизведении и проверке нескольких примеров ошибок. Кроме того, Карсон Лав и Джахид Хасан помогли исследовать конфигурации в Windows и macOS. Эта работа была частично поддержана Национальной наукой Фонд (NSF) в рамках грантов CNS-1855565, CCF-1853714, CCF-1910747 и CNS-1943204. Любые мнения, выводы и выводы, содержащиеся в данном материале, являются авторы и не обязательно отражают точку зрения спонсора.
Эта работа лицензирована по международной лицензии Creative Commons Attribution International 4.0. HotStorage '22, 27-28 июня 2022 г., Виртуальное мероприятие, США © 2022 Авторские права принадлежат владельцу / авторам. ACM ISBN 978-1-4503-9399-7/22/06. https://doi.org/10.1145/3538643.3539756