Файловая система. Индексные дескрипторы. Концепция «текст + файл»

aufs, another union file system . Идея совершенно замечательная, реализация оставляет желать, но даже в таком виде как сейчас оно пригодно к сиползованию. Предположим у вас несколько фс -- некоторые рид онли, некоторые рид райт. ваша задача -- сделать бутерброд, тчобы в каталоге были видны файлы из разных фс. Идея -- вы можете взять большое пространство доступное на ридо онли, накрыть его пространством, доступным на рид райт, и получить кучу файлов на рид райт. Типичное применение -- ливцд, когда на запись доступна только оперативная память, по хорошему. Сейчас есть лив флешки, но перезапись на флешку штука такая. А так у вас есть нетрогаемый образ, а если в какойто файл хочется записать он автоматическуи перемщается в пространство, в котором писать можно ( ег в оперативную память).

Сначала это был студенческий проект -- ufs. aufs делает какой-то японец. ЦУ него слегка японское мироощущение, но оно работает.

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

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

Именно поэтому на домашнее освоение были оставлены корутилз -- командочки для работы с файловой системой. info coreutils -- там всё написано. Сегодня мы поговорим немножко о том, что там написано.

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

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

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

Нумерация цилинд-дорожка-сектор ушла в прошлое. Теперь бесконечная лента секторов -- блоков с номерами от 1 до бесконечности.

Какие есть варианты хранения на таком устройстве?

Карта размещения это страшная штука. Можно попробовать ввести дополнительный уровень косвенности. отказаться от поняия файл "который указан в карте размещения" и вместо этого ввести иерархическую структуру. Если файл маленький, то он помещается в один кусок. Если этот файл недостаточно маленький, то информация остается, а куски файла хранят ссылки на такие же куски. Если и этого мало -- вводим ещё один уровень. Файл сам по себе выглядит не линейкой, а деревом ссылающихся друг на друга блоков. Возможный объем файла растет экспоненциально. Такая простая схема позволяет сделать что -- маленькие файлы будут доступны быстро, большие -- медленно. И не будет зараннее известно количество метаинформации. Как фишка ляжет. К чему может привести пирамидальная структура размещения файла в фс. Вы думаете, что увас полно свободного места, а при попытке что-то записа ть все начинает медленно работать, не пишется, не открывается, итд. Говорят нтфс долгое время так работал. Нтфс довольно прогрессиваня фс была, когда ее только придумали, но факт остается фактом -- когда много места занято у пирамидальной организации могут появляться артефакты. Решение простое -- ограничить количество этих индексов-инодов чтобы заранее ввыделить место под неё. Индексный дескриптор(инод) - информация о блоке. От макс количества инодов зависит сколько файлов можно напихать в вашу фс. Как правило трад. фс с трад. файлами трад. размеров предсказуемы. Иноды, сочетание инодов и имен, удаление файла -- уменьшение списка имен на единичку "я не хочу причинять тебе вреда, я просто хочу тебя съесть".

"Своп работал бы как полудохлый таракан".

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

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

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

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

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

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

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

Для этого есть ln -s символьная ссылка. Отдельный объект фс. Фактически прямая подстановка имени. Символьная ссылка на несущ файл -- не такая уж глупая вещь. Реализация в фрибзд след меанизма. Допустим нужно внезапно потребовать в рамках все ос потребовать чтобы вызов маллок из дибц обнулял память, хотя обычно он её не обнуляет. Можем в качестве флага на включение/отключение этой фичи использовать битую/небитую ссылку на какой-либо файл (о_О).

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

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

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

Тема состоит в следущем -- органзиация инф пространства на уровне системы в линуксе подчиняется двум максимам -- всё файл и всё текст. суммируя -- "всё текстовый файл".

Если есть информация, которую программа выдает пользователю,ничто не мешает пред выдачей пользователю отдать её какому-нибудь обработчику информации, пайплайн. ls|wc. Этот инструмент позволяет нам при наличии достаточного количества инфтсрументо вобработки делать с текстами всё что угодно.

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

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

Если вам нужно отвотировать строки или посчитать слова -- не нужно пистаь программу, достаточно использовать утилиты. Даже утилита генерирующая последовательность случайных числе ест. Понятно что любой может написать программу, которая печатает числа от 0 до 10. А в том, что когда основные подзадачи по обработке текста уже решены -- сама обработка будет представлять конвейер который будет очень легок читать.

LecturesCMC/GnuLinuxArchitecture2012/Conspects/02 (last edited 2012-05-01 12:54:05 by Allena)