Как называется наименьший блок, который можно выделить для размещения файла на диске

Обновлено: 21.11.2024

Принципиально ли необходимо хранить на диске информацию о незанятых секторах диска? Объясните почему.

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

Проблема 2:

<ПР>

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

Есть ли какая-либо польза от включения первых 436 байт файла в индексный дескриптор?

<ПР>

Примечание. Прежде всего необходимо определить размер индекса (2 или 4 байта). Учитывая, что у нас есть 3-уровневая схема индексации, вы можете быстро вычислить количество секторов, которые вы можете получить с помощью 2-байтового индекса и 4-байтового индекса. Вы увидите, что 2-байтовая индексация не работает. Это даст вам до 256 индексов на сектор с максимальным размером файла 436 + 13 * 512 + 1 * 256 * 512 + 1 * 256 * 256 * 512 + 1 * 256 * 256 * 256 * 512 = сколько угодно. Проблема с этим анализом заключается в том, что для работы этой схемы у вас гораздо больше секторов диска, чем можно закодировать в 2 байта. Вы можете использовать 3 байта, но это может стать некрасивым. Итак, мы используем 4-байтовые индексы, что дает нам 128 индексов на сектор, и правильный ответ: 436 + 13 * 512 + 1 * 128 * 512 + 1 * 128 * 128 * 512 + 1 * 128 * 128 * 128 * 512 = 1082203060, примерно 1 ГБ.

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

Проблема 3:

Решение:
Нет, мы не можем. Причина в том, что пространство имен в DOS сливается со структурами файловых данных, в отличие от UNIX, где пространство имен находится в структуре каталогов, отдельной от файловых структур данных (inode). Дополнительные сведения см. в примечаниях к лекциям.

Проблема 4:

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

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

Проблема 5:

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

Решение:
Лучшим местом будет средняя дорожка на диске. Причина в том, что в соответствии с политикой планирования лифта средняя дорожка будет посещена головкой диска дважды за один круговой путь, причем время между двумя посещениями будет максимальным для любой дорожки. Это наиболее желательное условие для трека, который будет активно использоваться.

Проблема 6:

Pooh Software Ltd. продает файловую систему, в которой используется UNIX-подобная файловая система с многоуровневой индексацией. Для большей надежности массив inode фактически реплицируется на диск в двух разных местах. Цель состоит в том, чтобы, если один или группа секторов, хранящих любую реплику массива, стали неисправными, система всегда может восстановиться из реплики. Обсудите влияние этой реплицированной структуры данных на производительность.

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

Проблема 7:

В файловой системе FAT используются 16-битные числа для представления номера кластера, с которого начинается связанный список кластеров, реализующих файл. Объясните последствия ограничения номеров кластеров до 16 бит. Измените файловую систему FAT, чтобы использовать 32-битные числа для представления кластеров, и покажите, как можно снять ограничения FAT.

Решение:
Использование 16-разрядных чисел для выражения кластеров позволяет использовать только до 32 КБ кластеров на диск (поскольку для обозначения конца файла и конца таблицы необходимы отрицательные числа). Для большого диска размер кластера, который является единицей размещения файлов, должен стать чрезмерно большим (например, размер кластера должен составлять 64 КБ в разделе диска размером 2 ГБ). Это приводит к огромной внутренней фрагментации файлов. Кроме того, он ограничивает размер раздела диска с использованием FAT только 2 ГБ.
Чтобы снять эти ограничения, мы используем 32-битные числа для выражения кластеров. Тем не менее, нужно быть осторожным, потому что такое расположение потенциально допускает до 2G записей в таблице FAT, каждая из которых состоит из 4 байтов! Следовательно, нам нужно хранить фактический размер таблицы FAT где-то на диске и использовать только минимальное количество записей, которое позволило бы таблице FAT использовать 32-битные числа для желаемого размера кластера. Например, диск объемом 4 ГБ можно разделить на 8 млн кластеров по 512 байт каждый. Требуемый размер таблицы должен составлять 32 МБ, или менее 1 % от размера диска.

Проблема 8:

Непрерывное размещение файлов приводит к фрагментации диска. Это внутренняя или внешняя фрагментация?

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

Проблема 9:

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

Проблема 10:

<ПР>

Что обычно хранится в индексном узле помимо индексов?

В чем недостаток хранения имени файла в индексном узле? Где должно храниться имя файла?

Если размер сектора диска составляет 512 байт, каков максимальный размер файла в этой схеме размещения?

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

В файловой системе, поддерживающей управление версиями, следует ли размещать информацию о номере версии в индексном узле или в дереве каталогов? Обоснуйте свой ответ.

<ПР>

Инод обычно хранит индексы и:

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

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

Сначала необходимо определить размер индекса. Для 2-байтового индекса у нас может быть 65536 дисковых блоков, т.е. 512 * 65536 = 32 МБ. Но структура тройного индекса может выражать больше дисковых блоков. Поэтому мы переходим на 4-байтовую схему индексации (3-байтная схема индексации не привлекательна и недостаточна). Таким образом, 4-байтная схема индексации дает максимальный размер файла 7 * 512 + 128 * 512 + 128 * 128 * 512 + 128 * 128 * 128 * 512 = 1 082 19952 или около 1 ГБ.

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

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

Проблема 11:

<ПР>

Что произойдет, если система резервного копирования перейдет по символическим ссылкам и сохранит файлы, на которые указывает ссылка?

Выявите проблемы с этой схемой резервного копирования.

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

<ПР>

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

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

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

Проблема 12:

Объясните, что происходит с диском в UNIX, когда пользователь в текстовом редакторе сохраняет новый файл с именем "foo" в текущем каталоге. Предположим, что длина foo составляет 15678 байт, размер дискового блока составляет 1024 байта, что файловая система поддерживает до 2^32 секторов и что индексный дескриптор содержит 10 прямых указателей на блоки, 1 косвенный указатель на блок, 1 дважды косвенный указатель на блок. и 1 тройной косвенный указатель блока. Система использует свободные карты на диске для отслеживания свободных блоков и свободных инодов. Вот набор действий, которые, как вы можете предположить, выполняет редактор:

fd = open(foo, O_CREAT|O_WRONLY);
p = &editBuffer;
numBlocks = editBufferSize / 1024;
for (i = 0; i Решение:

// fd = open(foo, O_CREAT|O_WRONLY) -- это создает файл
// предположим, что индекс N изначально свободен и выделен для этого файла
записать карту свободных индексов (отметить запись N как «используемый» для выделения индекса)
записать индекс N (все указатели равны «NULL» -- файл нулевой длины)
записать блок файла для каталога, содержащего «foo», добавив запись «foo - > N" (предположим, что это не увеличивает количество блоков в этом каталоге)
// 16 вызовов write() не приводят к обращению к диску
// закрываем
записываем обновления в карту свободных блоков для выделения 17 блоков -- 16 блоков данных + 1 косвенный блок
инод записи, содержащий указатель на 10 блоков данных и косвенный блок, и маркировка длины файла как 15678 байт
запись косвенного блока, содержащего указатель на 6 блоков данных
/>записать 16 блоков данных

Решение:
В этой ситуации индексный дескриптор указывает на непрямой блок, содержащий мусор. Это означает, что он может содержать указатели на блоки, выделенные другим файлам (и другим пользователям). Пользователь сможет прочитать до 6 блоков других пользователей (чтение последних 6 блоков файла будет следовать этим фиктивным указателям). Другие пользователи также могут читать данные этого пользователя (будущие записи этого пользователя в эти блоки будут следовать этим неверные указатели и помещает данные в файлы других пользователей; теперь эти данные могут быть прочитаны другими пользователями.)

Проблема 13:

Инженер разработал систему, подобную FAT, и использовал 24 бита для каждой записи. Для 32-гигабайтного диска, каков минимальный размер выделяемого файла в этой системе? Обосновать ответ.
Решение:
Диск объемом 32 ГБ имеет 2^35 байт памяти; если каждая запись в FAT имеет 24 бита, то может быть не более 2 ^ 24 фрагментов распределения (по одному на запись FAT), поэтому каждый фрагмент распределения должен иметь размер 2 ^ 11 байт = 2 КБ

Проблема 14:

Управление версиями: часто желательно, чтобы пользователи поддерживали разные версии одного и того же файла (например, во время разработки программы, для восстановления в случае неправильных обновлений, примененных к версии, и т. д.). Файловая система VMS реализует управление версиями, создавая новую копию файла каждый раз, когда он открывается для записи. Система также поддерживала управление версиями в структуре именования, добавляя номер версии к имени каждого файла. Например, при обновлении foo.c;1 система создает foo.c;2 и т. д. В системе реализованы команды для управления версиями, например, команда PURGE удалит все версии, кроме самой последней. Кроме того, пользователи могут отключить управление версиями для некоторых файлов. Обсудите плюсы и минусы этой схемы.

Решение:
Основным преимуществом этой схемы является ее простота. На самом деле нет принципиально необходимой поддержки со стороны операционной системы. Вместо этого прикладные программы и оболочка могут быть связаны с модифицированной библиотекой, которая создает новую версию всякий раз, когда файл открывается для обновления. Создание файла может быть выполнено с помощью доступных системных вызовов. Например, в UNIX-подобной системе это может быть реализовано за счет того, что библиотечная заглушка open() фактически вызывает creat() с новым именем, затем выполняет копирование, а затем открывает только что созданный файл.

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

Проблема 15:

Реализация программы FSCK просматривает дерево файловой системы и строит два списка дисковых блоков. Один список содержит секторы, которые показаны как используемые, а другой считывает информацию о свободных дисковых блоках на диске. Если бы два списка для 4 блоков были такими, как показано:

Используется	0	1< /TD>	0	1
Бесплатно	0	0	1	1

Определите проблемы, если таковые имеются, и что должна делать fsck для каждого блока.

Решение:
Комбинация (0, 0) является проблемой, поскольку она показывает, что блок диска не принадлежит ни одному файлу, и при этом он не находится в списке свободных. Fsck должен пометить блок как используемый и попытаться найти, где он должен принадлежать. В случае сбоя он должен создать восстановленный файл в каталоге Lost+Found и включить туда этот блок.

Комбинация (1,1) представляет собой проблему, поскольку она показывает блок диска, относящийся к файлу, который также находится в свободном списке. Fsck должен пометить блок как использованный и сохранить блок в файле, которому он принадлежит.

Все три метода имеют свои преимущества и недостатки, как описано ниже:

<р>1. Смежное размещение

Адрес начального блока
Длина выделенной части.

Файл mail’ на следующем рисунке начинается с блока 19 с длиной = 6 блоков. Следовательно, он занимает 19, 20, 21, 22, 23, 24 блоки.

При этом поддерживаются как последовательный, так и прямой доступ. Для прямого доступа адрес k-го блока файла, начинающегося с блока b, можно легко получить как (b+k).
Это очень быстро, так как количество операций поиска минимально из-за непрерывного размещения файловых блоков.

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

<р>2. Размещение связанного списка

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

Файл "джип" на следующем изображении показывает, как блоки распределяются случайным образом. Последний блок (25) содержит -1, указывающий на нулевой указатель, и не указывает ни на какой другой блок.

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

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

<р>3. Индексированное размещение

В этой схеме специальный блок, известный как блок индекса, содержит указатели на все блоки, занимаемые файлом. Каждый файл имеет свой индексный блок. i-я запись в индексном блоке содержит дисковый адрес i-го блока файла. Запись каталога содержит адрес индексного блока, как показано на рисунке:

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

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

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

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

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

Минимум свободного места

Количество файлов

Размер логического блока

Размер логического блока — это размер блоков, которые ядро UNIX использует для чтения или записи файлов. Размер логического блока обычно отличается от физического размера блока (обычно 512 байт), который является размером наименьшего блока, который контроллер диска может читать или записывать.

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

По умолчанию размер логического блока составляет 8192 байта (8 КБ) для файловых систем UFS. Файловая система UFS поддерживает блоки размером 4096 или 8192 байта (4 или 8 Кбайт). Рекомендуемый размер логического блока – 8 Кбайт.

Только SPARC -

На платформе sun4u можно указать только размер блока 8192 байта.

Как правило, для повышения эффективности используйте больший размер логического блока для файловых систем, в которых большинство файлов очень большие. Используйте меньший размер логического блока для файловых систем, в которых большинство файлов очень маленькие. Вы можете использовать команду quot -c file-system в файловой системе, чтобы отобразить полный отчет о распределении файлов по размеру блока.

Размер фрагмента

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

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

Вы определяете размер фрагмента при создании файловой системы UFS. Размер фрагмента по умолчанию составляет 1 Кбайт. Каждый блок может быть разделен на 1, 2, 4 или 8 фрагментов, в результате чего размер фрагмента может варьироваться от 8192 байт до 512 байт (только для файловых систем размером 4 Кбайт). Нижняя граница фактически привязана к размеру сектора диска, обычно 512 байт.

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

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

Минимум свободного места

Минимальное свободное пространство — это процент от общего дискового пространства, остающийся в резерве при создании файловой системы. Резерв по умолчанию равен ((64 Мбайт/размер раздела) * 100), округлен до ближайшего целого числа и ограничен от 1% до 10% включительно. Свободное пространство важно, потому что доступ к файлам становится все менее и менее эффективным по мере заполнения файловой системы. Пока имеется достаточно свободного места, файловые системы UFS работают эффективно. Когда файловая система заполняется, используя доступное пространство пользователя, только root может получить доступ к зарезервированному свободному пространству.

Команды, такие как df, сообщают процент пространства, доступного пользователям, за исключением процента, выделенного в качестве минимального свободного места. Когда команда сообщает, что используется более 100 процентов дискового пространства в файловой системе, часть резерва используется пользователем root.

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

Вращательная задержка (разрыв)

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

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

Чтобы позиционировать файловые блоки так, чтобы они были "правильными при ротации", процедуры выделения должны знать, насколько быстро ЦП может обслуживать передачи и сколько времени требуется диску, чтобы пропустить блок. Используя опции команды mkfs, вы можете указать, как быстро вращается диск и сколько дисковых блоков (секторов) приходится на дорожку. Подпрограммы распределения используют эту информацию, чтобы вычислить, сколько миллисекунд требуется, чтобы пропустить блок диска. Затем, используя ожидаемое время передачи (задержку вращения), процедуры распределения могут позиционировать или размещать блоки так, чтобы следующий блок как раз попадал под головку диска, когда система была готова его прочитать.

Для некоторых устройств нет необходимости указывать задержку вращения (опция -d для newfs).

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

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

Тип оптимизации

Тип оптимизации: пространство или время.

Пространство. Когда вы выбираете оптимизацию пространства, дисковые блоки выделяются для минимизации фрагментации и оптимизации использования диска.

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

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

Количество файлов

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

Количество байтов на индексный дескриптор по умолчанию составляет 2048 байт (2 КБ), если размер файловой системы меньше одного гигабайта. Если файловая система больше одного гигабайта, используется следующая формула:

Это список справочной информации в этой главе.

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

Тип хранимой информации

Информация, используемая при загрузке системы

Подробная информация о файловой системе

Вся информация о файле

Хранилище или блок данных

Данные для каждого файла

В следующих разделах представлена дополнительная информация об организации и функциях этих блоков.

Загрузочный блок

В загрузочном блоке хранятся объекты, используемые при загрузке системы. Если файловая система не используется для загрузки, загрузочный блок остается пустым. Загрузочный блок появляется только в первой группе цилиндров (группа цилиндров 0) и занимает первые 8 Кбайт в срезе.

Суперблок

В суперблоке хранится большая часть информации о файловой системе, включая следующее:

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

Ярлык, включающий имя файловой системы и имя тома

Размер логического блока файловой системы

Дата и время последнего обновления

Размер группы цилиндров

Количество блоков данных в группе цилиндров

Сводный блок данных

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

Путь к последней точке подключения

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

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

Иноды

Инод содержит всю информацию о файле, кроме его имени, которое хранится в каталоге. Индексный дескриптор составляет 128 байт. Информация об индексном узле хранится в блоке информации о цилиндре и содержит следующее:

Тип файла:

FIFO, также известный как именованный канал

Другие индексные дескрипторы — каталог атрибутов и тень (используется для ACL)

Режим файла (набор разрешений на чтение-запись-выполнение)

Количество жестких ссылок на файл

Идентификатор пользователя владельца файла

Идентификатор группы, к которой принадлежит файл

Количество байтов в файле

Массив из 15 адресов дисковых блоков

Дата и время последнего обращения к файлу

Дата и время последнего изменения файла

Дата и время изменения индексного дескриптора

Массив из 15 адресов дисковых блоков (от 0 до 14) указывает на блоки данных, в которых хранится содержимое файла. Первые 12 являются прямыми адресами. То есть они указывают непосредственно на первые 12 логических блоков хранения содержимого файла. Если файл больше 12 логических блоков, 13-й адрес указывает на косвенный блок, который содержит адреса прямых блоков вместо содержимого файла. 14-й адрес указывает на двойной косвенный блок, который содержит адреса косвенных блоков. 15-й адрес предназначен для тройных косвенных адресов. На следующем рисунке показана эта цепочка блоков адресов, начиная с индексного дескриптора.

Рис. 23–1 Цепочка адресов для файловой системы UFS

Блоки данных

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

Бесплатные блоки

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

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

Рис. 23–2. Типичная файловая система UFS

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

Описание параметров команды, которые настраивают эти параметры, см. в разделах newfs(1M) и mkfs_ufs(1M).

Размер логического блока

Размер логического блока — это размер блоков, которые ядро UNIX® использует для чтения или записи файлов. Размер логического блока обычно отличается от размера физического блока. Размер физического блока обычно составляет 512 байт, что является размером наименьшего блока, который контроллер диска может читать или записывать.

Размер логического блока по умолчанию равен размеру страницы системы. Размер логического блока по умолчанию составляет 8192 байта (8 Кбайт) для файловых систем UFS. Файловая система UFS поддерживает блоки размером 4096 или 8192 байта (4 или 8 Кбайт). Рекомендуемый размер логического блока – 8 Кбайт.

Только SPARC –

На платформе sun-4u TM можно указать только размер блока 8192 байта.

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

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

Размер фрагмента

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

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

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

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

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

Минимум свободного места

Минимальное свободное пространство – это процент от общего дискового пространства, который сохраняется в резерве при создании файловой системы. Резерв по умолчанию равен ((64 МБ/размер раздела) * 100), округлен до ближайшего целого числа и ограничен от 1 до 10 процентов включительно.

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

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

Задержка вращения

Этот параметр устарел. Значение всегда равно 0, независимо от указанного вами значения.

Тип оптимизации

Параметр типа оптимизации имеет значение пространство или время.

Пространство — при выборе оптимизации пространства блоки диска выделяются для минимизации фрагментации и оптимизации использования диска.

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

Для получения дополнительной информации см. Tunes(1M).

Количество инодов (файлов)

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

Количество байтов на индексный дескриптор по умолчанию составляет 2048 байт (2 КБ), если размер файловой системы меньше 1 Гбайт. Если файловая система больше 1 Гбайт, используется следующая формула:

Читайте также: