Файловые системы /dev и /proc в Linux 2.4 0
Новичкам
Статья была опубликована 1 февраля 2010 года в 00:00, а последний раз правилась 4 февраля 2010 года в 00:05.
В Linux есть две файловые системы, которые абсолютно непоняты новым пользователям. У этих двух каталогов, /proc и /dev, нет аналогов в Windows. Тем не менее, они очень важны для понимания и использования Linux.
В Linux есть две файловые системы, которые абсолютно непоняты новым пользователям. У этих двух каталогов, /proc и /dev, нет аналогов в Windows. Тем не менее, они очень важны для понимания и использования Linux.
Данная статья представляет собой краткий обзор файловых систем для устройств (/dev) и для процессов (/proc). В ней рассказывается о том, что они из себя представляют, как работают и как используются.
/dev: файловая система для устройств
Устройства: В Linux’е устройство является специальным «оборудованием» (или кодом, эмулирующим его), которое представляет методы для ввода или вывода информации (IO — Input/Output). Например, клавиатура — устройство для ввода. Жесткий диск — устройства для ввода (запись) и вывода (чтение). Большинство устройств в Linux’е представлено как файлы в особой файловой системе (за исключением сетевых карт). Эти файлы хранятся в каталоге /dev, куда к ним обращается система для выполнения задач, связанных с вводом/выводом.
Грубо говоря, устройства можно разделить на две категории: символьные и блочные. Символьные устройства вводят/выводят по символам. Наиболее показательным примером служит клавиатура, у которой нажатие каждой клавиши формирует символ, передаваемый компьютеру. Мышь работает немного по-другому. Каждое движение или нажатие на кнопку отправляет символ на /dev/mouse.
Блочные устройства считывают данные большими объемами. Примерами служат устройства для хранения данных, такие как IDE жесткие диски (/dev/hd), SCSI жесткие диски (/dev/sd) и CD-ROM’ы (например, /dev/cdrom0 — символическая ссылка на первый CD-ROM). Операции ввода/вывода блочные устройства проводят с определенными блоками данных, что позволяет работать с большими объемами информации более эффективно.
Названия устройств: Устройства часто называются путем сокращения имен представляемого ими оборудования. Устройства с именами /dev/fb представляют буферы фреймов (frame buffers) для графики. Устройства /dev/hd представляют IDE жесткие диски (hard disks). В некоторых случаях для пояснения того, чем является устройство, используются символические ссылки: например, /dev/mouse, устройство, представляющее мышь, может быть прилинковано к последовательному, USB или PS2 устройству, в зависимости от железа. Символическая ссылка помогает и человеку, и машине разобраться, какое из устройств — мышь.
Иногда бывает несколько устройств одного типа. Например, у машины два ATAPI CD-ROM’а. Каждому CD-приводу нужен файл в /dev. В таком случае, возможен вариант, что /dev/cdrom0 будет первым CD-ROM’ом, а /dev/cdrom1 — вторым.
С именами жестких дисков немного сложнее. Название устройства жесткого диска зависит от типа диска, его позиции и раздела (partition’а). Первый жесткий диск может быть назван /dev/hda, где часть «hd» означает, что это IDE жесткий диск, а «a» показывает, что это первый жесткий диск. Тогда /dev/hdb будет ссылаться на второй жесткий диск. Каждый жесткий диск разбит на разделы. Первый раздел первого жесткого диска получит название /dev/hda1, где единица в конце обозначает номер раздела. Обратите внимание на то, что, если индексы некоторых устройств (например, /dev/cdrom0) могут начинаться с нуля, то индекс устройств с разделами обычно начинается с единицы. Вот примерный список файлов в /dev для двух IDE жестких дисков:
SCSI жесткие диски используют /dev/sd вместо /dev/hd, но все остальное выглядит также. /dev/sda1 ссылается на первый раздел первого SCSI жесткого диска.
Специальные устройства: Существует несколько специальных устройств, которые порой бывают очень полезны: /dev/null, /dev/zero, /dev/full и /dev/random.
Нулевое устройство, /dev/null представляет собой что-то типа «мусорной корзины». Часто некоторые программы выводят множество ненужной информации. Shell-скрипты обычно используют /dev/null для того, чтобы пользователь не видел ненужных ему сообщений от вызываемых утилит. Вот пример вызова модуля ядра с выводом всех сообщений в /dev/null.
/dev/zero близок к /dev/null. Как и /dev/null, устройство может быть использовано для блокирования вывода ненужной информации, но чтение /dev/zero возвращает \0 символы (чтение /dev/null возвращает символы end-of-file — конец файла). Поэтому /dev/zero обычно используется для создания пустых файлов.
Такая команда (см. выше) создаст файл размером в 100 кб, наполненный null-символами.
/dev/full служит для имитации «полного» устройства. Запись в /dev/full сопровождается ошибкой. «Полное» устройство полезно для того, чтобы посмотреть, как тестируемое приложение будет себя вести при попытки доступа к заполненному устройству (т.е. например, к жесткому диску, на котором не осталось места).
Устройства /dev/random и /dev/urandom создают «случайные» данные. Хотя вывод обоих может показаться абсолютно случайным, /dev/random более случаен чем /dev/urandom. /dev/random создает случайные символы, основываясь на «окружающем шуме». Так как количество этого случайного шума ограничено, /dev/random работает медленно и может временно останавливаться для дальнейшего сбора данных. /dev/urandom использует тот же шум, что и /dev/random, но если случайных данных больше нет, оно создает псевдо-случайные данные. Таким образом увеличивается его скорость, но уменьшается безопасность.
Старая файловая система /dev: Раньше файловая система /dev была частью обычной файловой системы. Она состояла из специальных файлов, созданных однажды (обычно при установке системы) и сохраненных на жестком диске.
В старых системах файловая система /dev должна содержать информацию обо всех устройствах, которые могут быть подключены к компьютеру. Из-за этого /dev была слишком большой — приходилось хранить сведения о множестве жестких дисков, дисководов и т.п. Ранее мы рассматривали список разделов жесткого диска hdb. В старой файловой системе /dev приходилось содержать файлы с /dev/hdb1 до /dev/hdb11. Чтобы выяснить, какие устройства действительно привязаны к разделам жесткого диска (если помните, у меня всего три раздела на hdb), нужно вызвать специальную утилиту. Команда «file -s hdb*» поможет в этом разобраться:
Если указанного файла устройства не было, приходилось его создавать с помощью mknod или другой программы (типа MAKEDEV). Хотя «старый способ» работал, он был сложен и неудобен.
DevFS: В ядрах 2.4.x была представлена альтернативная дисковая файловая система /dev. Эта альтернатива, DevFS, подключала код нового устройства в ядро. В DevFS файловая система /dev создается во время каждого запуска компьютера и сохраняется в оперативной памяти, а не на жестком диске. При использовании этой модели пропадает нужда в поддержке списка всех возможных устройств, а когда появляется новое устройство, ядро просто делает для него запись в /dev. Если же устройствам нужна особая настройка в DevFS, существует конфигурационный файл (обычно /etc/devfsd.conf).
/proc: Файловая система для процессов
Процессы: В любое время в Linux’е одновременно запущено множество процессов. Некоторые из них, такие как оконные менеджеры, email-клиенты и Web-браузеры, видны конечному пользователю. Другие, вроде серверов и вспомогательных процессов, в глаза не бросаются, но запущены в фоновом режиме, выполняя задания, не требующие каких-либо действий со стороны пользователя. Запуск «ps -ef» в shell’е выведет список всех запущенных на данный момент процессов. А выглядеть будет примерно так:
Многие из задач в выводе ps являются процессами, работающими в фоновом режиме. Те, что взяты в квадратные скобочки — процессы ядра. Только некоторые, вроде процессов kde и записей в конце списка, являются процессами, с которыми я взаимодействую напрямую.
Для управления системой ядро должно хранить информацию о каждом запущенном процессе, включая само себя. Также должна быть возможность просмотра сведений о запущенных приложениях пользовательского уровня (хорошим примером служит «ps», а также «top»). В файловой системе /proc ядро и хранит информацию о процессах.
Как и DevFS, /proc хранится в памяти, а не на диске. Если вы посмотрите в файл /proc/mounts (в котором приводится список всех примонтированных файловых систем), то увидите строку вроде этой:
/proc контролируется ядром, у этой файловой системы нет «под собой» какого-либо устройства. Так как в ней в основном содержится информация, управляемая ядром, наиболее логичным место для хранения такой информации является память, также контролируемая ядром.
Информация о запущенных процессах: Чтобы хранить информацию обо всех процессах, ядро присваивает каждому из них PID (Process ID — идентификатор процесса) в виде числа. Запуск команды «ps -ef» (см. выше) выведет список всех запущенных процессов в порядке их PID’ов (вторая колонка). Файловая система /proc хранит информацию о каждом PID.
В /proc названиями многих каталогов являются числа. Эти директории ссылаются на номера PID. В таких каталогах находятся файлы, которые предоставляют подробную информацию о положении, окружении и прочих деталях процесса. В выводе ps (см. выше) была следующая строка:
Этот процесс — запущенный bash shell, имеющий PID 1219. Каталог /proc/1219 содержит информацию об этом процессе.
В файле «cmdline» располагается команда, которая вызвала процесс. В файле «environ» находятся данные о значениях окружения для процесса. «status» содержит информацию о статусе процесса, среди которой пользовательский (UID) и групповой (GID) идентификаторы для пользователя, запустившего процесс, идентификатор родительского процесса (parent process ID — PPID) и текущий статус процесса (например, «Sleep» или «Running»).
У каждого каталога процесса есть несколько символических ссылок. «cwd» ссылается на текущий рабочий каталог для процесса. «exe» — ссылка на исполняемую программу процесса, а «root» ссылается на каталог, который процесс рассматривает как корневой (обычно «/»). В каталоге «fd» содержится список символических ссылок на дескрипторы файлов, используемых процессом.
Существуют и другие файлы в каталоге процесса, предоставляющие исчерпывающую информацию: от занятности процессора и памяти до количества времени, которое запущен процесс. Большая часть этих файлов описана в документации исходников ядра («Documentation/file systems/proc.txt»), а также доступна в man — «man proc».
Информация о ядре: Кроме хранения сведений о процессах, файловая система /proc содержит множество информации, самостоятельно созданной ядром для описания общего состояния системы.
Ядро и модули могут создавать файлы в /proc для того, чтобы предоставить информацию о своем текущем состоянии. Например, /proc/fb показывает, какие сейчас доступны устройства типа frame buffer (буферы фреймов обычно используются для отображения загрузочного логотипа).
Обратите внимание, что 0 ссылается на индекс frame buffer’а и устройство /dev/fb0. Если бы у меня был второй framebuffer, то появилась бы еще и строка с 1, соответствующая /dev/fb1. Часто данные proc ссылаются на устройства в /dev.
В /proc хранится немало информации о железе. В файле /proc/pci написано про все обнаруженные в системе PCI устройства. Запуск команды «lspci» выводит идентичную информацию, так как использует /proc/pci для получения сведений об устройствах. В /proc/bus находятся каталоги для bus-архитектур (PCI, PCCard, USB), в которых содержится информация об устройствах, присоединенных таким образом (PCI, PCCard, USB). Информация о сети располагается в /proc/net. Информацию о жестких дисках можно найти в /proc/ide и /proc/scsi (в зависимости от типа устройства). В /procs/devices присутствует список всех устройств системы (они разделены на две категории: «block» — блочные, «character» — символьные).
В действительности, в /proc находится намного больше файлов, чем было описано здесь. У каждого ядра они могут несколько различаться, в зависимости от того, что было включено в ядро, какое железо и программное обеспечение используется и в каком состоянии в настоящий момент находится компьютер. К некоторым из этих файлов постоянно обращается машина, а другие предоставляют «интуитивную» информацию.
Работа с процессами через /proc: Некоторые файлы /proc предназначены не только для чтения. Запись в них может влиять на состояние ядра. Просмотр содержимого файла в /proc обычно безопасно, но запись в них без точной уверенности в своих действиях может приводить к фатальным последствиям. Несмотря на это, иногда запись в /proc — единственный способ связи с ядром.
Например, в некоторых версиях ядра присутствует опция включения Web-сервера (khttp), работающего на уровне ядра. Из-за того, что запуск Web-сервера по умолчанию является риском с точки зрения безопасности, khttp требует записи в /proc для запуска.
Когда ядро видит, что содеримое /proc/sys/net/khttps/start меняется с 0 (по умолчанию) на 1, оно запускает сервер khttpd.
Существуют десятки других настраиваемых параметров в /proc — некоторые для конфигурации железа, другие для управления ядром. Однако, многие из них являются низкоуровневыми и могут привести к печальным последствиям, если указать неправильные значения. Поэтому, если вы твердо не уверены в своих действиях, менять параметры в /proc строго не рекомендуется.
/proc и /dev представляют интерфейсы к внутренностям Linux’а с помощью файлов. Они способствуют настройке и получению сведений об устройствах и процессах системы. Благодаря ним, можно с легкостью обновлять, изучать, запускать систему и устранять разнообразные неполадки. Понимание и применение знаний этих двух файловых систем являются ключом к созданию «более вашей» Linux-системы.
Источник
Understanding the /dev directory
There are many interesting features of the Linux directory structure. In this article I cover some fascinating aspects of the /dev directory. Before you proceed any further with this article, I suggest that, if you have not already done so, you read my earlier articles, Everything is a file, and An introduction to Linux filesystems, both of which introduce some interesting Linux filesystem concepts. Go ahead – I will wait.
Great! Welcome back. Now we can proceed with a more detailed exploration of the /dev directory.
Device Files
Device files are also known as device special files. Device files are employed to provide the operating system and users an interface to the devices that they represent. All Linux device files are located in the /dev directory which is an integral part of the root (/) filesystem because these device files must be available to the operating system during the boot process.
One of the most important things to remember about these device files is that they are most definitely not device drivers. They are more accurately described as portals to the device drivers. Data is passed from an application or the operating system to the device file which then passes it to the device driver which then sends it to the physical device. The reverse data path is also used, from the physical device through the device driver, the device file, and then to an application or another device.
Let’s look at the data flow of a typical command to visualize this.
In Figure 1, above, a simplified data flow is shown for a common command. Issuing the cat /etc/resolv.conf command from a GUI terminal emulator such as Konsole or xterm causes the resolv.conf file to be read from the disk with the disk device driver handling the device specific functions such as locating the file on the hard drive and reading it. The data is passed through the device file and then from the command to the device file and device driver for pseudo-terminal 6 where it is displayed in the terminal session.
Of course the output of the cat command could have been redirected to a file in the following manner, cat /etc/resolv.conf > /etc/resolv.bak in order to create a backup of the file. In that case the data flow on the left side of Figure 1 would remain the same while the data flow on the right would be through the /dev/sda2 device file, the hard drive device driver and then onto the hard drive itself.
These device files make it very easy to use Standard Streams (STD/IO) and redirection to access any and every device on a Linux or Unix computer. Simply directing a data stream to a device file sends the data to that device.
Classification
Device files can be classified in at least two ways. The first and most commonly used classification, is that of the data stream commonly associated with the device. For example tty and serial devices are considered to be character based because the data stream is transferred and handled one character or byte at a time. Block type devices such as hard drives transfer data in blocks, typically a multiple of 256 bytes.
If you have not already, go ahead and as a non-root user in a terminal session, change the present working directory (PWD) to /dev and display a long listing. This shows a list of device files with their file permissions and their major and minor identification numbers. For example the following device files are just a few of the ones in the /dev/directory on my Fedora 24 workstation. They represent disk and tty type devices. Notice the leftmost character of each line in the output. The ones that have a “b” are block type devices and the ones that begin with “c” are character devices.
The more detailed and explicit way to identify device files is using the device major and minor numbers. The disk devices have a major number of 8 which designates them as SCSI block devices. Note that all PATA and SATA hard drives have been managed by the SCSI subsystem because the old ATA subsystem was many years ago deemed as not maintainable due to the poor quality of its code. As a result hard drives that would previously been designated as “hd[a-z]” are now referred to as “sd[a-z]”.
You can probably infer the pattern of disk drive minor numbers in the small sample shown above. Minor numbers 0, 16, 32 and so on up through 240 are the whole disk numbers. So major/minor 8/16 represents the whole disk /dev/sdb and 8/17 is the device file for the first partition, /dev/sdb1. Numbers 8/34 would be /dev/sdc2.
The tty device files in the list above are numbered a bit more simply from tty0 through tty63.
The Linux Allocated Devices file at Kernel.org is the official registry of device types and major and minor number allocations. It can help you understand the major/ minor numbers for all currently defined devices.
Fun with device files
Let’s take a few minutes now and perform a couple fun experiments that will illustrate the power and flexibility of the Linux device files. Most Linux distributions have multiple virtual consoles, 1 through 7, that can be used to login to a local console session with a shell interface. These can be accessed using the key combinations Ctrl-Alt-F1 for console 1, Ctrl-Alt-F2 for console 2, and so on.
Press Ctrl-Alt-F2 to switch to console 2. On some distributions, the login information includes the tty (Teletype) device associated with this console, but many do not. It should be tty2 because you are in console 2.
Login as a non-root user. Then you can use the who am i command—yes, just like that, with spaces—to determine which tty device is connected to this console.
Before we actually perform this experiment, look at a listing of the tty2 and tty3 devices in /dev.
There will be a large number of tty devices defined but we do not care about most of them, just the tty2 and tty3 devices. As device files, there is nothing special about them; they are simply character type devices. We will use these devices for this experiment. The tty2 device is attached to virtual console 2 and the tty3 device is attached to virtual console 3.
Press Ctrl-Alt-F3 to switch to console 3. Login again as the same non-root user. Now enter the following command on console 3.
Press Ctrl-Alt-F2 to return to console 2. The string “Hello world” (without quotes) is displayed on console 2.
This experiment can also be performed with terminal emulators on the GUI desktop. Terminal sessions on the desktop use pseudo terminal devices in the /dev tree, such as /dev/pts/1. Open two terminal sessions using Konsole or Xterm. Determine which pseudo-terminals they are connected to and use one to send a message to the other.
Now continue the experiment by using the cat command to display the /etc/fstab file on a different terminal.
Another interesting experiment is to print a file directly to the printer using the cat command. Assuming that your printer device is /dev/usb/lp0, and that your printer can print PDF files directly, the following command will print the PDF file test.pdf on your printer.
The /dev directory contains some very interesting device files that are portals to hardware that one does not normally think of as a device like a hard drive or display. For one example, system memory – RAM – is not something that is normally considered as a “device,” yet /dev/mem is the portal through which direct access to memory can be achieved. The following example had some interesting results.
The dd command above provides a bit more control than simply using the cat command to dump all of memory. It provides the ability to specify how much data is read from /dev/mem and would also allow me to specify the point at which to start reading data from memory. Although some memory was read, the kernel responded with the following error that I found in /var/log/messages.
What this error means is that the kernel is doing its job by protecting memory that belongs to other processes which is exactly how it should work. So, although you can use /dev/mem to display data stored in RAM memory, access to most memory space is protected and will result in errors. Only that virtual memory which is assigned by the kernel memory manager to the BASH shell running the dd command should be accessible without causing an error. Sorry, but you cannot snoop in memory that does not belong to you unless you find a vulnerability to exploit.
There are some other very interesting device files in /dev. The device files null, zero, random and urandom are not associated with any physical devices.
For example, the null device /dev/null can be used as a target for the redirection of output from shell commands or programs so that they are not displayed on the terminal. I frequently use this in my BASH scripts to prevent users from being presented with output that might be confusing to them. The /dev/null device can be used to produce a string of null characters. Use the dd command as shown below to view some output from the /dev/null device file.
Note that there is really no visible output because null characters are nothing. Note the byte count.
The /dev/random and /dev/urandom devices are also very interesting. As their names imply, they both produce random output – not just numbers but any and all byte combinations. The /dev/urandom device produces deterministic random output and is very fast. That means the output is determined by an algorithm and uses a seed string as a starting point. As a result it is possible, although very difficult, for a hacker to reproduce the output if the original seed is known. Use the command cat /dev/urandom to view typical output. You can use Ctrl-c to break out.
The /dev/random device file produces non-deterministic random output but it produces output more slowly. This output is not determined by an algorithm that is dependent upon the previous number, but is generated in response to keystrokes and mouse movements. This method makes it far more difficult to duplicate a specific series of random numbers. Use the cat command to view some of the output from the /dev/random device file. Try moving the mouse to see how it affects the output.
As its name implies, the /dev/zero device file produces an unending string of zeroes as output. Note that these are Octal zeroes and not the ASCII character zero (0). Use the dd command as shown below to view some output from the /dev/zero device file.
Note that the byte count for this command is non zero.
Creating device files
In the past, the device files in /dev were all created at installation time, resulting in a directory full of almost very possible device file, even though most would never be used. In the unlikely event that a new device file was needed or one was accidentally deleted and needed to be re-created, the mknod program was available to manually create device files. All you had to know was the device major and minor numbers.
CentOS and RHEL 6 and 7, as well as all versions of Fedora going back to at least as far Fedora 15, use the newer method of creating the device files. All device files are created at boot time. This functionality is possible because the udev device manager detects addition and removal of devices as they occur. This allows for true dynamic plug-n-play functionality while the host is up and running. It also performs the same task at boot time by detecting all devices installed on the system very early in the boot process. Linux.com has a good description of udev.
Going back to your listing of the files in /dev, notice the date and time on the files. All of them were created during the last boot. You can verify this using the uptime or last commands. In my device listing above, all of those files were created at 7:06 AM on November 7, which is the last time I booted the system.
Of course the mknod command is still available, but the new MAKEDEV (yes, in all uppercase – which in my opinion is contrary to the Linux philosophy of using all lowercase command names) command provides an easier interface for creating device files, should the need arise. The MAKEDEV command is not installed by default in current versions of Fedora or CentOS 7; it is installed in CentOS 6. You can use YUM or DNF to install the MAKEDEV package.
Conclusion
Interestingly enough, it had been a long time since I needed to create a device file. However, just recently I had an interesting situation where one of the device files I typically use was not created and I did have to create it. I have not had any problem with that device since. So a situation caused by a missing device file can still happen and knowing how to deal with it can be important.
I have not covered many of the myriad different types of device files that you might encounter. That information is available in plenty of detail in the resources cited. I hope I have given you some basic understanding of how these files function and the tools to allow you to explore more on your own.
Источник
