Чому у спеціальних файлах пристроїв є вставки?


11

Файли пристроїв самі по собі не є файлами. Вони є інтерфейсом вводу / виводу для використання пристроїв в Unix-подібних операційних системах. Вони не використовують місця на диску, однак вони все ще використовують inode, як повідомляється statкомандою:

$ stat /dev/sda
      File: /dev/sda
      Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 6h/6d   Inode: 14628       Links: 1     Device type: 8,0

Чи використовують файли пристроїв фізичні вставки у файловій системі і навіщо вони взагалі потрібні?


2
Вклад і дані - це файл. Без inode у вас немає файлу. (У файлах пристрою немає даних)
користувач253751

Відповіді:


16

Коротка відповідь полягає в тому, що це робиться лише в тому випадку, якщо у вас є резервна копія фізичної файлової системи /dev(і якщо ви використовуєте сучасний дистрибутив Linux, ви, мабуть, не робите).

Звідси випливає довга відповідь:

Все це повертається до оригінальної філософії UNIX, що все є файлом. Ця філософія є частиною того, що зробило UNIX таким універсальним, оскільки ви могли безпосередньо взаємодіяти з пристроями з простору користувачів, не потребуючи спеціального коду у вашій програмі, щоб безпосередньо спілкуватися з фізичним обладнанням.

Спочатку це /devбув лише інший каталог із відомим іменем, куди ви поміщали файли пристрою. Деякі системи UNIX все ще застосовують такий підхід (я вважаю, що OpenBSD все ще є), і ви зазвичай можете сказати, чи є така система, оскільки вона буде мати багато файлів пристроїв для пристроїв, яких система насправді не має (наприклад, файли для кожного можливий розділ на кожному можливому диску). Це економить місце в пам’яті та час під час завантаження ціною використання трохи більше дискового простору, що було гарною торгівлею для ранніх систем, оскільки вони, як правило, дуже обмежені в пам'яті та не дуже швидкі. Це, як правило, називається статичним /dev.

У сучасних системах Linux (і я вважаю, також FreeBSD і, можливо, останні версії Solaris) /dev- це тимчасова файлова система пам'яті, заселена ядром (або udev, якщо ви використовуєте Systemd, оскільки вони не довіряють ядру робити майже нічого) . Це економить трохи дискового простору ціною деякої пам’яті (як правило, менше кількох МБ) та дуже невеликими накладними витратами на обробку. Він також має ряд інших переваг, причому одним з найбільших є те, що легше виявити апаратне забезпечення з гарячим підключенням. Зазвичай це називається динамічним /dev.

В обох випадках, до вузлів пристрою можна отримати доступ через звичайний VFS-шар, що за визначенням означає, що вони повинні мати inode (навіть якщо це віртуальний, який просто існує, щоб такі речі, як stat()працює, належить. З практичної точки зору, це має нульовий вплив на системи, які використовують динамічну, /devтому що вони просто зберігають вкладиші в пам'яті або генерують їх у міру необхідності, а також біля нульового впливу, коли /devє статичним, тому що індекси займають майже нульовий простір на диску, а більшість файлових систем або не мають верхньої межі на їх чи способу надання більше, ніж кому-небудь, можливо, буде потрібно.


3
Обережно піднімає руку. Я був у проекті, у якого на сервері не вистачало індексів. Нарешті, кризис нашому колективу потрібно було переконати керівництво інвестувати в заміну тієї бек-енд-системи, яка була розроблена (погано, як ви могли собі уявити!) До того, як хтось із нас потрапив туди.
KRyan

@KRyan Це може статися, але в наші дні це рідко, якщо адміністратор явно не зменшив кількість при створенні файлової системи. Багато сучасних файлових систем (принаймні NTFS, BTRFS і ZFS, я думаю, що також може бути XFS) насправді динамічно розподіляють узори, тому для багатьох новіших систем насправді неможливо закінчити.
Остін Хеммельгарн

@KRyan У мене теж була ця проблема. Насправді це була добре розроблена система, якщо її трохи датували та переносили на exreams (для кожної транзакції потрібен незалежний журнал, який зберігався на диску, зрештою він просто заповнився крихітними маленькими
вводами

1
Od and docker є начебто відомим тим, що викликає саме цю проблему з inode.
coteyr

@AustinHemmelgarn Родина ext досить відома тим, що має статичну кількість вкладень (а згодом і закінчується). Це, до речі, найбільш використовувана файлова система Linux, ймовірно, величезний запас (сценарії, які зберігають величезну кількість даних на XFS вбік, ZFS та BTRFS є відносно новими), а також за замовчуванням для більшості дистрибутивів. Звичайно, в сучасній системі максимум введення за замовчуванням на багато порядків перевищує кількість файлів пристроїв, які ви коли-небудь матимете.
Боб

15

Файли пристроїв також мають дозволи, і вони зберігаються у inode.


Відмінний момент, який я забув згадати.
Остін Хеммельгарн

5
Не лише дозволи, але й тип файлу та інші метадані. Класично, сам каталог містить лише ім'я та номер inode - нічого не свідчить про те, що файл є пристроєм, поки ви не прочитаєте inode.
Жил "ТАК - перестань бути злим"

12

Довідники - це просто зіставлення імен файлів до inode, тому все про те, на що посилається ім'я (файл, символьна посилання, пристрій, FIFO, сокет), повинно бути в inode, більше нікуди його не ставити.

Інформація про пристрій зберігається в inode. Тут знаходяться основні та незначні номери пристроїв, а також дозволи, часові позначки тощо. Поле типу, яке говорить про те, що це блок або символьний пристрій, а не звичайний файл, зберігається там.

Inode для пристроїв просто не використовує поля, які містять блок-блок файлу.


0

Без введення у вас буде тільки ім'я файлу, щоб зберігати всю інформацію про відповідний пристрій. Це означає, що "приємні" назви пристроїв, як, наприклад, /dev/sdaне виникає сумніву: вам знадобиться ім'я, яке може бути пов'язане з певним драйвером, наприклад /dev/ohci/sda.

Ще важливіше, що всі інструменти, які покладаються на inode (наприклад stat, lsтощо), повинні були бути модифіковані, щоб обробляти шляхи по- /devособливому. Це було б надмірно великим обсягом роботи без видимої користі порівняно з поточним станом речей.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.