Псевдо файловые системы linux

Изучение псевдо-файловой системы “/proc” в ОС Linux

Страницы работы

Содержание работы

Министерство образования РФ

Хабаровский государственный технический университет

Лабораторная работа №2

по дисциплине «Операционные системы»

Выполнили: студенты гр. ПО-12

Проверил: Сорокин Н.Ю.

Знакомство и изучение псевдо-файловой системы “/proc” в ОС Linux. Получение информации о состоянии ОС и параметрах ядра ОС Linux.

Задание на лабораторную работу:

1. Изучите содержание директории /proc.

dr-xr-xr-x 3 root root 0 Мар 3 12:36 945/

dr-xr-xr-x 4 root root 0 Мар 2 15:16 bus/

-r—r—r— 1 root root 0 Мар 3 12:36 cmdline

-rw-r—r— 1 root root 0 Мар 3 12:36 cpufreq

-r—r—r— 1 root root 0 Мар 3 12:36 cpuinfo

-r—r—r— 1 root root 0 Мар 3 12:36 crypto

-r—r—r— 1 root root 0 Мар 3 12:36 devices

-r—r—r— 1 root root 0 Мар 3 12:36 dma

dr-xr-xr-x 2 root root 0 Мар 3 12:36 driver/

-r—r—r— 1 root root 0 Мар 3 12:36 e820info

-r—r—r— 1 root root 0 Мар 3 12:36 execdomains

-r—r—r— 1 root root 0 Мар 3 12:36 fb

-r—r—r— 1 root root 0 Мар 3 12:36 filesystems

dr-xr-xr-x 2 root root 0 Мар 3 12:36 fs/

dr-xr-xr-x 4 root root 0 Мар 3 12:36 ide/

-r—r—r— 1 root root 0 Мар 3 12:36 interrupts

-r—r—r— 1 root root 0 Мар 3 12:36 iomem

-r—r—r— 1 root root 0 Мар 3 12:36 ioports

dr-xr-xr-x 18 root root 0 Мар 3 12:36 irq/

-r——— 1 root root 267128832 Мар 3 12:36 kcore

-r——— 1 root root 0 Мар 2 15:16 kmsg

-r—r—r— 1 root root 0 Мар 3 12:36 ksyms

-r—r—r— 1 root root 0 Мар 3 12:36 loadavg

-r—r—r— 1 root root 0 Мар 3 12:36 locks

-r—r—r— 1 root root 0 Мар 3 12:36 mdstat

-r—r—r— 1 root root 0 Мар 3 12:36 meminfo

-r—r—r— 1 root root 0 Мар 3 12:36 misc

-r—r—r— 1 root root 0 Мар 3 12:36 modules

lrwxrwxrwx 1 root root 11 Мар 3 12:36 mounts -> self/mounts

-rw-r—r— 1 root root 203 Мар 3 12:36 mtrr

dr-xr-xr-x 5 root root 0 Мар 3 12:36 net/

-r—r—r— 1 root root 0 Мар 3 12:36 partitions

-r—r—r— 1 root root 0 Мар 3 12:36 pci

dr-xr-xr-x 4 root root 0 Мар 3 12:36 scsi/

lrwxrwxrwx 1 root root 64 Мар 3 12:20 self -> 15808/

-rw-r—r— 1 root root 0 Мар 3 12:36 slabinfo

-r—r—r— 1 root root 0 Мар 3 12:36 stat

-r—r—r— 1 root root 0 Мар 3 12:36 swaps

dr-xr-xr-x 2 root root 0 Мар 3 12:36 swsusp/

dr-xr-xr-x 12 root root 0 Мар 3 12:36 sys/

—w——- 1 root root 0 Мар 3 12:36 sysrq-trigger

dr-xr-xr-x 2 root root 0 Мар 3 12:36 sysvipc/

dr-xr-xr-x 4 root root 0 Мар 3 12:36 tty/

-r—r—r— 1 root root 0 Мар 3 12:36 uptime

-r—r—r— 1 root root 0 Мар 3 12:36 version

2. Используя помощь в системе Linux (команда man proc) дайте письменно ответ на вопрос: Какой формат имеет файл statm (см. Таблицу 1)?

Аргументы командной строки

Значения переменных окружения

Директория, содержащая все дескрипторы файлов

Память, используемая процессом

Статус процесса в более удобной для чтения форме

Связь (линк) на текущую рабочую директорию

Связь (линк) на исполняемый файл процесса

Связь (линк) на корневую директорию процесса

Информация о памяти процесса

3. Напишите программу на языке С (С++) которая использует данные из /proc и выводит на экран информацию (см. Таблицу 3) в соответствии с номером бригады.

char * prd, linebuf[100] ;

fp = fopen («/proc/interrupts», «r») ;

if (fp == NULL) fatalerror ();

printf(«information about the interrupts:\n»);

prd = fgets (linebuf, 100, fp) ; /* read data from «/proc/interrupts» file */

printf («%s», linebuf) ; /* stdout */

perror («FATAL ERROR!\n») ;

Результат работы прораммы:

information from [/proc/version]:

Linux version 2.4.22-10mdk (nplanel@no.mandrakesoft.com) (gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)) #1 Thu Sep 18 12:30:58 CEST 2003

.1-2mdk)) #1 Thu Sep 18 12:30:58 CEST 2003

Источник

Синтетическая файловая система — Synthetic file system

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

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

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

Содержание

Примеры

/ proc файловая система

В мире Unix обычно монтируется специальная файловая система в / proc . Эта файловая система реализована в ядре и публикует информацию о процессах . Для каждого процесса существует каталог (названный по идентификатору процесса ), содержащий подробную информацию о процессе: статус , открытые файлы, карты памяти , подключения и т. Д.

/ proc впервые появился в Unix 8th Edition, а его функциональность была значительно расширена в Plan 9 от Bell Labs .

Файловая система Linux / sys

Файловая система / sys в Linux дополняет / proc, предоставляя множество (не связанных с процессами) подробной информации о состоянии ядра в пользовательском пространстве. Более традиционные системы Unix находят эту информацию в вызовах sysctl.

ObexFS

ObexFS — это файловая система на основе FUSE, которая обеспечивает доступ к объектам OBEX через файловую систему. Приложения могут работать с удаленными объектами через протокол OBEX, как если бы они были просто (локальными) файлами.

План 9 файловых серверов

В семействе операционных систем Plan 9 от Bell Labs концепция синтетической файловой системы 9P используется как общий метод IPC . В отличие от большинства других операционных систем, дизайн Plan 9 широко распространен: в то время как в других мирах ОС существует множество (и часто больших) библиотек и фреймворков для общих вещей, Plan 9 инкапсулирует их в файловые серверы. Самым важным преимуществом является то, что приложения могут быть намного проще и что службы работают независимо от сети и платформы — они могут находиться практически на любом хосте и платформе в сети и практически в любой сети, если файловый сервер может быть смонтирован приложением. .

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

Другие реализации протокола файловой системы 9P также существуют для многих других систем и сред.

Встроенные системы

Широко известно, что отладка встроенных систем или даже устройств система на кристалле (SoC) является сложной задачей. Было реализовано несколько протоколов для обеспечения прямого доступа к внутрикристальным устройствам, но они, как правило, являются проприетарными, сложными и трудными в обращении.

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

Плюсы и минусы

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

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

Источник

Kodomo

Управление файловой системой

Sparse files

Начну с маленького примера вдогону к перыдущему рассказу.

Мы выяснили, что в файловой системе, как правило, есть некоторая верхушка файла (inode), и ссылки на блоки, в которых лежит тело файла. В зависимости от тонкостей того, как устроены эти ссылки (а они могут быть устроены очень по-разному в разных файловых системах), может быть возможным добиться, например, такой ситуации: у нас есть файл размером в 200G, у которого есть 4 блока данных – от 0 до 4К, от 50 до 54K и от 90G до 90G+4K. Такая ситуация называется sparse file (разреженный файл).

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

Со sparse files вы наверняка встречались, если когда-нибудь качали торренты: именно так представляют недокачанные файлы программы.

Узнать, сколько файл реально занимает на диске, можно командой du.

du файл – узнать сумму размеров блоков, занимаемых файлом (обычно это больше, чем размер файла; в случае sparse files – наоборот). Результат выдаётся как количество блоков (что не очень удобно читать). Для директорий du распечатывает аналогично размер каждого в директории самого по себе и складывает их размер с размером директории.

du -h файл – выдавать размер файла в человекочитаемом виде.

du -s файл – для директории выдавать только суммарный итоговый размер.

du -sh файл – так обычно вызываю du я, чтобы не задумываться. 2

Остальные варианты, что можно делать с du ищите в документации. (О которой я ещё расскажу довольно подробно).

Монтирование файловых систем

Традиционно UNIX развивался в среде, где есть две чётко раздельные роли – администратора и пользователя. (Windows, его предшественник DOS и его предшественник CP/M рассчитывались на компьютер, работающий без администратора – и это приводило к несколько другим решениям в некоторых местах). Для пользователя в UNIX файловая система всегда выглядит как одно единое и довольно неизменное дерево.

Для администратора, как мы выяснили в прошлый раз, есть, например, понятие раздела. Именно администратор в UNIX должен знать о том, как называется какое устройство относится к какому жёсткому диску.

Напоминаю и дополняю. В Linux имена устройств такие:

диски, подсоединённые через шлейф IDE – /dev/hda, /dev/hdb, .

диски, подсоединённые SCSI, SATA или USB – /dev/sda, /dev/sdb, .
для CD обычно автоматически создаётся ссылка в /dev/cdrom или /dev/dvd

первичные разделы диска /dev/диск: /dev/диск1, /dev/диск2, /dev/диск3, /dev/диск4

расширенные разделы: /dev/диск5, /dev/диск6, .

логические разделы (LVM): /dev/mapper/группа—имя

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

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

Положим, у нас в разделе /dev/sda1 есть файловая система, в которой есть дерево директорий:

И есть директория /dir:

То мы можем подмонтировать устройство /dev/sda1 поверх /dir.

Прежнее содержимое /dir мы не можем увидеть то дех пор, пока не размонтируем /dev/sda1:

При монтировании устройства мы можем указать кучу всяких параметров на тему того, как именно монтировать. Полный формат вызова команды mount выглядит примерно так: mount что куда -t тип_фс -o параметры, пара самых популярных примеров параметров:

Первой строкой mount мы монтируем /dev/sda1, как и в прошлом примере, поверх /dir, но монтируем с параметром ro – read-only. Вторым вызовом mount мы меняем настройки уже подмонтированной файловой системы – об этом говорит параметр remount; параметр rw обозначает перемонтировать на чтение и записть (read-write).

Во всех примерах выше говорят, что директория /dir называется точкой монтирования. (Точка монтирования – та директория, в которую что-нибудь вмонтировано).

fstab

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

UNIX сам по себе автоматически не запоминает, что вы где подмонтировали, поэтому если вы что-то подмонтировали и перезагрузили компьютер, монтировать нужно заново.

Дабы это не делать руками, сделали таблицу, в которой описывается, какие файловые системы куда нужно монтировать во время загрузки. Таблица эта лежит в файле /etc/fstab и выглядит примерно так:

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

Поля файла такие:

1. что
2. куда

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

параметры – ровно то же, что после флага -o

здесь всегда должен быть 0. Это поле – пережиток прошлого. Когда-то давно резервные копии файлов делались утилитой под названием dump – и в этом поле указывалась частота копирования выбранной файловой системы. Сейчас большинство людей всё-таки делает бэкапы другими средствами. (dump поддерживают и развивают довольно вяло, файловых систем он поддерживает только семейство ext*, да и сам подход довольно спорный).

в каком порядке во время загрузки проверять файловую систему на консистентность. Здесь всё просто: для / всегда должна быть 1 и никак иначе, для всех остальных должна быть 2, если их перепроверять нужно или 0 если не нужно

Когда вы ставите любой относительно современный Linux, программа-инсталлятор сама создаст для вас довольно разумный /etc/fstab и редактировать его своими руками вам вряд ли придётся.

Псевдо файловые системы

Помните ли вы, что такое устройство (как тип файла)? Напомню, это такой файл, у которого нету тела, а вместо этого в нём написано, в какой части ядра реализованы функции read, write, . – которые реализуют работу с этим файлом.

Довольно аналогичным образом, имя файловой системы указывает на то, где в ядре реализованы функции listdir, open, . 3

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

А раз всё сводится к тому, что с точки зрения ядра файловая система – это просто набор функций, то можно в качестве таких функций подсунуть что-нибудь, что отнюдь не будет реализовать способ организации данных на диске!

Примеров тому много. Приведу лишь несколько самых полезных / самых распространённых.

procfs – видимо, самая первая из псевдо файловых систем в UNIX. Она была реализована в 1984 году. Идея этой файловой системы состоит в том, чтобы показывать состояние ядра в виде набора директорий и файлов. /proc/число/ – это информация о процессе по его номеру (о процессах мы поговорим в следующий раз). /proc/meminfo – очень подробная таблица о том, какая область оперативной памяти сколько места занимает. /proc/filesystems – перечень файловых систем, о которых знает ядро. На самом деле, в этой файловой системе лежит очень много разной информации. И плюс к этому, в часть файлов на этой файловой системе можно писать данные – и таким образом настраивать ядро. Советую вам поглядеть, что есть в этой директории ближайший раз, как вы доберётесь до линукса. (Исключительно из интереса: сколько из того, что там есть, вы способны понять). Ещё одно полезное замечание: информация в этой файловой системе сделана так, чтобы с ней было удобно работать в первую очередь программам, а не людям; поэтому для людей тоже с древних времён существует довольно большая гора программ, которые вытаскивают информацию из этой файловой системы и выдают в более читаемом виде.

sysfs – примерно аналогичная файловая система, специфичная для линукса и очень молодая. В первую очередь она посвящена информации о всяких периферийных устройствах и возникла ради того, чтобы на лету уметь реагировать на втыкание-вытыкание разных частей компьютера. (Например, usb флэш-память). Рассказываю об этой файловой системе исключительно для полноты. Пример про неё: # echo disk > /sys/power/state отправляет компьютер в очень глубокое состояние сна (отправляет всё содержимое памяти на жёсткий диск и выключает компьютер совсем; иногда просыпание из этого сна даже возможно); никогда так не делайте.

nfs – network file system – название говорит за себя. Идея такая: на одном компьютере бегает несколько программ, которые раздают какие-нибудь директории по сети, на другом компьютере (если ему разрешено) можно подмонтировать какую-нибудь из этих директорий. Довольно подобно тому, как в Windows вы можете «расшарить» (share) директорию (на самом деле, NFS ровестник слову windows как названию программы – оба появились в 1985-м, – и потому сильно древнее возможности расшаривать директории в windows). В линуксе на компьютерах класса в fstab есть, например, такая строка:

• Обратите внимание, что в случае псевдо файловых систем мы уже не обязаны в

качестве устройства, на котором лежат данные, указывать устройство с точки зрения UNIX. В данном случае устройство kodomo:/home – это просто строка, которую драйвер nfs интерпретирует как адрес машины, с которой нужно соединяться и путь к директории, которую мы хотим подмонтировать. Об этой файловой системе я тоже рассказываю для полноты картины, а не для практики. С nfs всегда довольно много возни (в первую очередь, с раздающей стороны) и я не советую вам пытаться ей пользоваться.

tmpfs – файловая система для временных файлов. Идея такая: мы заводим кусочек оперативной памяти и складываем файлы туда. Зачем: чтобы с временными файлами работа была быстрее и для того, чтобы быть уверенными, что после перезагрузки они исчезнут. (Как ни странно, это свойство полезно даже в обиходе). Приятное свойство этой файловой системы в том, что она занимает в памяти столько места, сколько в ней реально используется. Я рекомендую вам, если вы вознамерились установить себе на компьютер линукс, добавить в /etc/fstab строчку примерно такого вида:

fuse – даже среди псевдо файловых систем это трудно назвать файловой системой. Авторы этой файловой системы размышляли вот о чём: во-первых, монтировать файловые системы может только администратор, а иногда и продвинутому пользователю 4 хотелось бы иногда что-нибудь подмонтировать удобства ради; а во-вторых, лучше было бы, чтобы драйвер файловой системы был обычной пользовательской программой с ограниченными правами (это желание у них возникло хотя бы потому, что отлаживать части ядра существенно сложнее, чем пользовательские программы, и потому, что раз пользователь может что-то подмонтировать, то именно правами пользователя должны ограничиваться и возможности драйвера). Идея fuse такова: она запускает пользовательскую программу и перенаправляет обращения к функциям драйвера в обращения к частям этой программы. (Приблизительно).

sshfs – это самый полезный, на мой вкус, пример файловой системы, сделанной через fuse. Идея такая: мы запускаем ssh и превращаем все обращения к нашей файловой системе в команды ssh 5 . Таким образом, мы сильно задёшево (без какой-либо настройки на сервере и даже без ведома сервера) получаем возможность подмонтировать у себя часть директорий с чужой UNIX-машины. Настоятельно рекомендую вам освоить это средство. Пример:

Вот вам два неприятных отличия fuse от остальных файловых систем: мы не можем монтировать и размонтировать его командой mount и umount. Более того, монтировать файловые системы fuse как правило нужно отдельной программой, которая поставляется с каждой из таких файловых систем, а размонтировать командой fusermount -u. В остальном команды монтирования fuse стараются вести себя примерно так же, как и mount.

В случае sshfs команда монтирования выглядит так:

copyfs – это ещё один пример файловой системы, сделанной через fuse. Преследует ту же цель, что и репозитории: хранить прежние версии файлов. Только в отличии от обычных репозиториев, новая версия файла сохраняется автоматически при любом изменении – от вас вообще не требуется никаких действий, чтобы прежние версии сохранялись. Должен признаться, что ни разу не пользовался этой файловой системой, возможно и зря.

encfs – ещё один пример файловой системы на fuse. Encryption filesystem – когда вы её монтируете, она спрашивает у вас пароль и шифрует все данные этим паролем. После того, как вы её отмонтировали, прочитать данные, которые вы записали, не имея пароля, невозможно. Как и с copyfs, этой файловой системой я не пользовался, и привожу её пример ради кургозора.

unionfs – это способ склеить две директории вместе. Мы имеем две директории с похожими данными (или одну полную директорию и одну пустую), и . получаем директорию, которая выглядит как Очень часто используется на «live CD» – дистрибутивах, которые работают прямо с компакт-диска. Поступают так: на CD запихивают полностью всю иерархию директорий, как это нужно для того, чтобы система работала, после чего создают небольшу

pmount

FIXME: /, /bin, /boot, /dev, /etc, /etc/X11, /home, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /srv, /tmp, /usr, /var

/usr: bin, include, lib, sbin, share, src, X11R6, local

/var: lib, lock, log, mail, run, spool, tmp

Пользователи в UNIX

login, password, . => /etc/passwd

• name:passwd:uid:gid:gecos:home:shell
• gecos = General Electric Comprehensive Operating Supervisor

/etc/passwd vs. /etc/shadow

• name:passwd:lastch:minage:maxage:warntime:grace:exp_date:RFU

gid, /etc/group

• name:passwd:gid:members

root

информация о пользователе: id, finger

Права на файловой системе

FIXME

• биты
• chmod, chgrp, chown

Байтов со значением 0x00, а не символов ‘0’, которые есть байты со значением 0x30. см. (1)

Я не знаю, откуда я взял флаг -c, но делает он именно то, что я и сказал на лекции: наряду со стандартной выдачей печатает ещё и суммарный итоговый размер. (2)

Названия функций я привёл из питонских примеров, в жизни всё разбито на сильно более мелкие шаги. (3)

Я надеюсь, такими станете вы по результатам моего курса. (4)

На самом деле, не в команды ssh, а в команды sftp. sftp — это подпротокол ssh, который реализует ту же функциональность, что и ftp. Если вы когда-нибудь пользовались WinSCP, то наверняка вы, сами того не зная, пользовались sftp. (5)

Источник