Файловая система. Индексные дескрипторы. Концепция «текст + файл»
aufs, another union file system . Идея совершенно замечательная, реализация оставляет желать, но даже в таком виде как сейчас оно пригодно к сиползованию. Предположим у вас несколько фс -- некоторые рид онли, некоторые рид райт. ваша задача -- сделать бутерброд, тчобы в каталоге были видны файлы из разных фс. Идея -- вы можете взять большое пространство доступное на ридо онли, накрыть его пространством, доступным на рид райт, и получить кучу файлов на рид райт. Типичное применение -- ливцд, когда на запись доступна только оперативная память, по хорошему. Сейчас есть лив флешки, но перезапись на флешку штука такая. А так у вас есть нетрогаемый образ, а если в какойто файл хочется записать он автоматическуи перемщается в пространство, в котором писать можно ( ег в оперативную память).
Сначала это был студенческий проект -- ufs. aufs делает какой-то японец. ЦУ него слегка японское мироощущение, но оно работает.
Пока возвращемся к важному факту, затронотому в прошлый раз -- в линуксе по возможности любая информация представляется в виде файлов. Даже информация о содержимом системы, в том числе и управление, на сегодняшний день оформляются в линуксе в виде спец вирт фс -- проц сис, и т д. Собственно говоря ничего кроме процессов и объектов фс мы особ не можем себе ничего вообразить. Есть ещё всякие сокеты, но и хобычно не рассматривают как часть ос.
Всё -- файл. Во первых любая информация стремится быть представленной в виде файла, во -вторых не так уж много других объектов для манипулирования.
Именно поэтому на домашнее освоение были оставлены корутилз -- командочки для работы с файловой системой. info coreutils -- там всё написано. Сегодня мы поговорим немножко о том, что там написано.
Что следует из этой максимы "все кроме пчел это файл, а пчелы это процессы"? Важность инструментария для модификации файлов. Прежде чем переходить к этой части разговора хочу сделать два отступления для того чтобы картинка оставлась ценльной. В начале разговра, когда только упомянули фс, было сказано что есть два определения "структура хранения данных на диске, как диск ощущает себя когда на нем хранят информациюю" и второе -- "структура хранения с точки зрения пользователя". Мы говорили провторое -- фхс, то сё. Сегодня поговрим немножко про первое.
Что собой представляет типичная фс с точки зрения диска. Не будем говорить о разбиение диска на семестры -- это было достаточно плотно обговорено в прошлом семестре. могу заметить, что скорее всего, каждый раздел будет являться фс в первом определении. Что при этом важно знать про типичную линуксовую фс (что то типа ехт2, ехт3). Файловые системы бзди логически организованны примерно так же, хоть и написаны по другмоу и другими людьми. Проблема с фс сосотоит в следующем -- сбалансировать количество информации о файле и собственно пейлоада. На ленточку записали подряд три файла. Чтобы они не слились в один между ними должна быть дырка.Метаинформация в этом случае -- бумажка приколотая к ленте с надписями где какой файл. На устройствах с последовательным доступом вообще неудобно хранить метаинформацию.
Теперь попробуем записать файл на диск. Диск состоит из уилиндров, дорожек и секторов. Доступ к данным на одном цилиндре -- быстро. На разных -- долго потмоу что перепозиционируется дорожка.
Нумерация цилинд-дорожка-сектор ушла в прошлое. Теперь бесконечная лента секторов -- блоков с номерами от 1 до бесконечности.
Какие есть варианты хранения на таком устройстве?
- подряд, ак на ленточке. Тогда мы можем запланировать очень небольшое место метаинформации. Это будет имя файла, начало, длина. Если все файлы лежат последовательно, то размер метаинформации будет напрмяую зависеть от количества файлов. Такая фс сразу зафрагментируется и будет печально.
- признаем файлы фрагментированными, будем хранить имя, начало, длину, карту размещения. объем метаинформации немедленно разбух. стал зависеть от количества файлов, общего объема винчестера. Типичный пример -- фат. Там все просто, естественно и неудобно. ПРоблема фата -- баланс метаинформации и пейлоада и фрагментация. предположим один сектор 512 байт. Берём 200 гб винчестер 400 миллионов секторов. в карте размещения должно быть 400 миллионов 32 байтных слов. Это много и долго ковырять, если что. Если сделать адресуемый блок не один сектор, а побольше, то получим что в больших секторах лежат маленькие файлики. В 54 кб занятиы, например, 3. Отсюда проблемы с фс типа фат32. Они достаточно медленные, их легко забить маленькими файлами и на них опять встаёт проблема фрагментации. Файлы создаются удалются -- файл может очень плохо разбросаться по диску. Сборка мусора может длиться сутками и даже неделями.
- как можно избавиться от этой болезни. Легко избавиться если заранее разделим винчестер на части, внутри которых не будем заморачиваться скоростью доступа. введём понятие цилиндрогруппы. Внутри него перемещение блока головок считается не очень медленным. Если места на диске достаточно будем стараться размещать файлы внутри неё. Предполжим у нас есть очень большой файл, мы его читаем. В рамках оной цилиндрогруппы читаем файл миллион секторов. Что делают фс? Они в память читают скопом всю цилиндрогруппу не заботясь о порядке. Это наиболее старый алгоритм кэширования. Легко избавиться от фрагментации -- вырезали-вставили -- они сами сгруппировались по цилиндрогруппам.
Карта размещения это страшная штука. Можно попробовать ввести дополнительный уровень косвенности. отказаться от поняия файл "который указан в карте размещения" и вместо этого ввести иерархическую структуру. Если файл маленький, то он помещается в один кусок. Если этот файл недостаточно маленький, то информация остается, а куски файла хранят ссылки на такие же куски. Если и этого мало -- вводим ещё один уровень. Файл сам по себе выглядит не линейкой, а деревом ссылающихся друг на друга блоков. Возможный объем файла растет экспоненциально. Такая простая схема позволяет сделать что -- маленькие файлы будут доступны быстро, большие -- медленно. И не будет зараннее известно количество метаинформации. Как фишка ляжет. К чему может привести пирамидальная структура размещения файла в фс. Вы думаете, что увас полно свободного места, а при попытке что-то записа ть все начинает медленно работать, не пишется, не открывается, итд. Говорят нтфс долгое время так работал. Нтфс довольно прогрессиваня фс была, когда ее только придумали, но факт остается фактом -- когда много места занято у пирамидальной организации могут появляться артефакты. Решение простое -- ограничить количество этих индексов-инодов чтобы заранее ввыделить место под неё. Индексный дескриптор(инод) - информация о блоке. От макс количества инодов зависит сколько файлов можно напихать в вашу фс. Как правило трад. фс с трад. файлами трад. размеров предсказуемы. Иноды, сочетание инодов и имен, удаление файла -- уменьшение списка имен на единичку "я не хочу причинять тебе вреда, я просто хочу тебя съесть".
"Своп работал бы как полудохлый таракан".
Осталось скуазать, что в начале фс находится мастерблок, а прочая информация о файле находится в начале мастергруппы, чтобы от метаинформации до пейлоада было недалеко. Кстати сказать, эта схема позволяет избежать второй напасти -- хранения в одном блоке.
Недостатки фс в современном мире. Есть некоторые устройства на которых такие фс работают плохо. Очень медленно читающие, такие как лазерные диски и во вторую очередь флешки, ссдшки и прочие фс в которых медленно происходит запись, да ещё и органиченный цикл. во втором случае делается ремап. Запись новых данных идет всегда в свободное место, чтобы занятое место на флешке ползало. Сейчас такая поддержка аппаратная. В случае ссд оправдывает себя уменьшение объема поиска при работе с фс -- например хранение бинарных деревьев вместо линейного списка для метаинформации. В тот же бтрфс это втсроено.
Наконец современные фс энтерпрайз класса типа зфс это уже не совсем фс, потому что они оперируют с многими уровнями косвенности начиная с томов. И в них постоянно развивается доабвление кода, привязывающееся к конкретному устройству. ,Например есть специальные диски, которые сертифицировал оракл. У этих дисков есть профиль производитьельности -- откуда быстрее читается. Современныек фс пытаются учитыывать даже это.
Рассказ об одном бтре занял бы больше одной лекции, а о зфс и говрить нечего, там одних только фич на страницу.
Райзер фс был хорош когда его развивали. Он обладал другой концепцией, поулярной в нулевых годах. Фс сама по себе, спутеМ, инодом, это легаси. Файлы это такие данные, которые пользователь хранит чтобы их искать и использовать. давайте спроектируем фс как базу данных, а полный путь будет одним из ключей. Идея хороша и активно эксплуатируется в мак оси, когда есть смартфолдеры и тэги. Это пользовательская идея, востребованная в первую очередь конечным пользователем. А в случае линукса и вообще юникс подобных систем идет крупное развитие в энтерпрайзную сторону а там важнее быстродействие, надежность во ввсех смыслах, динамическое распределение и перераспределение объема.
Основная проблем с ссд -- это отсутствие явного удаления сектора. Нет такой комманды контроллера в стандарте ата. Поэтому реализовать хороший сборщик мусора сложно.
Жесткие ссылки (дополнительные имена на файл) работают не для кататлогов, чтобы не было вечных циклов. Второе -- недостаток проистекающий их деления на иноды. Если есть потеряный файл, вы не знаете как он называется. Третий недостаток -- не работает кросс фсно.
Для этого есть ln -s символьная ссылка. Отдельный объект фс. Фактически прямая подстановка имени. Символьная ссылка на несущ файл -- не такая уж глупая вещь. Реализация в фрибзд след меанизма. Допустим нужно внезапно потребовать в рамках все ос потребовать чтобы вызов маллок из дибц обнулял память, хотя обычно он её не обнуляет. Можем в качестве флага на включение/отключение этой фичи использовать битую/небитую ссылку на какой-либо файл (о_О).
Первоапрельская шутка про хранение в фс файлов не занимающих место -- всё сожержимое в названии. даже апи какое-то реализовано было.
Сетуид используется очень разнородно. Например нужен рут чтобы открыть сокет. Почему бы не предусмотреть возможность процессу открыть сокет, но ничего больше. И так дале, и так далее. Таких капабилитиз в линусе напложили очень много. Современные способы написания программ склоняются к отхождению от сетуида и сетгида, а склоняются к использованию кааблитиз -- сеткап. Современные фс умеют хранить капабилитиз так же, как они хранят сетуид и сетгид. Это открывает забавные перспективы в манипуляции файлами и профессами.
Переходим к тому, чему должна была быть посвещена наща лекция. Лектор испытывает отврщение к рассказам о списках комманд.
Тема состоит в следущем -- органзиация инф пространства на уровне системы в линуксе подчиняется двум максимам -- всё файл и всё текст. суммируя -- "всё текстовый файл".
Если есть информация, которую программа выдает пользователю,ничто не мешает пред выдачей пользователю отдать её какому-нибудь обработчику информации, пайплайн. ls|wc. Этот инструмент позволяет нам при наличии достаточного количества инфтсрументо вобработки делать с текстами всё что угодно.
Даже управление ос по сути является манипуляцией текстовыми полями, представленными в виде файлов. Есть каталог етц, в котором лежат почти все системные конфигурационные файлы. Они, вообще говоря, текстовые. По сути управление все йос сводится к тому чтобы модифицировать конфигурационный файл и как то сообщить об этом службе котороая сейчас его использует.
Другой пример. В шелле есть переменные окружения. Это такие переменные, которые ведут себя как обычные переменные, а с другой сторны они в окнтексте процесса. Модифицируя переменную окружения можно модифицировать работу программы, которой эта перменная передастся. Манипуляция текстовыми полями приводит к управлению программой.
Если вам нужно отвотировать строки или посчитать слова -- не нужно пистаь программу, достаточно использовать утилиты. Даже утилита генерирующая последовательность случайных числе ест. Понятно что любой может написать программу, которая печатает числа от 0 до 10. А в том, что когда основные подзадачи по обработке текста уже решены -- сама обработка будет представлять конвейер который будет очень легок читать.