Чому нам потрібно монтуватися на Linux?

Я розумію, що таке монтаж в Linux, і я розумію файли пристроїв. Однак я не розумію, ЧОМУ нам потрібно встановити.

Наприклад, як пояснено у прийнятій відповіді на це питання , використовуючи цю команду:

mount /dev/cdrom /media/cdrom

ми монтуємо пристрій CDROM /media/cdromі, зрештою, можемо отримати доступ до файлів CDROM за допомогою наступної команди

ls /media/cdrom

в якому буде перераховано вміст CDROM.

Чому б не пропустити монтаж повністю, а зробити наступне?

ls /dev/cdrom

І мають вміст CDROM у списку. Очікую, що одна з відповідей буде: " Ось так створено Linux ". Але якщо так, то чому він був розроблений саме так? Чому б не отримати доступ до /dev/cdromкаталогу безпосередньо? Яка реальна мета монтажу?

Однією з причин є те, що доступ до рівня блоку є трохи нижчим, ніж lsможна було б працювати. /dev/cdromабо, dev/sda1можливо, це ваш привід CD ROM та розділ 1 вашого жорсткого диска відповідно, але вони не реалізують ISO 9660 / ext4 - вони просто вказівники RAW на ті пристрої, відомі як файли пристроїв .

Однією з речей, які визначає mount, є ЯК використовувати цей необроблений доступ - яка логіка файлової системи / драйвер / ядро ​​модулів буде керувати ls /mnt/cdromчитанням / записом або перекладати, в які блоки потрібно читати, і як інтерпретувати вміст цих блокує такі речі file.txt.

В іншому випадку цей доступ низького рівня може бути досить хорошим; Я щойно читав і записував у послідовні порти, usb-пристрої, термінали tty та інші порівняно прості пристрої. Я б ніколи не намагався вручну читати / писати з / dev / sda1 в, скажімо, редагувати текстовий файл, тому що я, в основному, повинен був би повторно реалізувати логіку ext4, яка може включати, серед іншого, пошук файлів у введеннях, знайти блоки зберігання, прочитати повний блок, внести мої зміни (зміни), записати цілі блоки, потім оновити inode (можливо), або замість цього записати все це в журнал - дуже важко.

Один із способів переконатися в цьому - просто спробувати:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devце каталог, і ви можете cdі lsвсе, що вам подобається. /dev/sda1не є каталогом; це особливий тип файлу, який ядро ​​пропонує як "ручку" для цього пристрою.

Дивіться запис у Вікіпедії на файлах пристроїв для більш глибокої обробки.

В основному, і простіше кажучи, операційна система повинна знати, як отримати доступ до файлів на цьому пристрої.

mount це не лише "надання доступу до файлів", це і вказує на операційну систему, яку має файлова система, якщо вона лише для читання або доступ для читання / запису тощо.

/dev/cdromце пристрій низького рівня, функції операційної системи не знають, як отримати доступ до них ... уявіть, ви помістили в нього дивно відформатований компакт-диск (навіть аудіо-компакт-диск), як би lsсказати, які файли (якщо такі є) CD-ROM, не "монтуючи" його спочатку?

Зауважте, що це відбувається автоматично в багатьох ОС (навіть Linux на деяких дистрибутивах та графічних інтерфейсах), але це не означає, що інші ОС не «монтують» накопичувачі.

Для консистенції

Уявіть, що на першому жорсткому диску у вашій системі є деякі розділи. Наприклад, /dev/sda2. Пізніше ви вирішите, що накопичувач недостатньо великий, тому ви купуєте другий і додаєте його до системи. Раптом це стає /dev/sdaі стає вашим поточним приводом /dev/sdb. Зараз ваш розділ /dev/sdb2.

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

Однак монтаж дозволяє все ж використовувати ту саму точку монтажу для цього перейменованого накопичувача. Вам доведеться редагувати, /etc/fstabщоб сказати вашій системі, що (наприклад) /media/backupзараз /dev/sdb2замість цього, але це лише одна редакція.

Зауважте, що сучасні системи ще простіші. Замість посилання на пристрій, /dev/sda2або /dev/sdb2, у них є UUIDS, які схожі на c5845b43-fe98-499a-bf31-4eccae14261bабо може бути дано нешкідливі етикетки , такі як , backupякі можуть бути використані для посилання на пристрої під час монтажу. Таким чином, ім’я пристрою не змінюється, додаючи новий пристрій, що робить адміністрування ще простішим:

# mount LABEL="backup" /media/backup

Для безпеки

Вимагаючи встановлення пристрою, адміністратор може контролювати доступ до пристрою. Пристрій можна вилучати, коли його відключити, але не під час використання (якщо ви не хочете зазнати втрати даних). Якщо ви (користувач) Windows, пам’ятаєте маленьку зелену піктограму в області повідомлень, яка говорить про те, що безпечно вийняти USB-накопичувач? Це встановлення Windows та демонтаж палички для вас. Таким чином, принцип не є лише Unix / Linux.

Я б назвав це історичними причинами. Не те, щоб інші відповіді були невірними, але в сюжеті є трохи більше.

Порівняйте Windows: Windows запускалася як однокомп'ютерна, однокористувацька ОС. На цьому єдиному комп’ютері, мабуть, був один дискети та один жорсткий диск, ні мережне підключення, ні USB, ніщо. (У Windows 3.11 були можливості для власних мереж; Windows 3.1 не зробив .)

Вид налаштування Windows був настільки простим, що не потрібно було фантазувати: Просто монтуйте все (усі два пристрої) автоматично кожен раз, не було (не було) багато речей, які могли б піти не так.

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

Одне з дизайнерських рішень Unix полягало в тому, що файлова система повинна представлятись єдиним єдиним об'єктом для кінцевих користувачів, незалежно від того, скільки комп’ютерів були розкинуті фізичні диски, незалежно від типу диска і незалежно від того, який із десятків комп'ютерів користувач отримав би доступ до нього. Логічний шлях до файлів користувача залишатиметься однаковим, навіть якщо фізичне розташування цих файлів змінилося протягом ночі, наприклад, через обслуговування сервера.

Вони абстрагували логічну файлову систему, шляхи до файлів від фізичних пристроїв, які зберігали ці файли. Скажімо, сервер A - це звичайно хостинг / дім, але сервер A потребує технічного обслуговування: просто відключіть сервер A і замість цього встановіть резервний сервер B на / home, і ніхто, крім адміністраторів, навіть не помітить.
(На відміну від конвенції Windows про надання різних імен різним фізичним пристроям - C:, D:, тощо - що працює проти прозорості, до якої прагнув Unix.)

У такій обстановці ви не можете просто змонтувати все на очах вольово-невольно,

У великій мережі окремі диски та комп’ютери постійно виходять з ладу. Адміністраторам потрібна можливість сказати, що встановлено де і коли, наприклад, зробити контрольоване відключення одного комп’ютера, тоді як інший комп'ютер прозоро бере на себе розміщення тих же файлів.

Тож тому з історичної точки зору: Windows та Unix виходили з різного походження. Ви можете назвати це культурною різницею, якщо вам подобається:

• Unix народився в середовищі, де адміністратору потрібно було контролювати монтаж; з десятків пристроїв зберігання даних в мережі адміністратор повинен вирішити, що встановлено, де і коли.
• Windows народився в умовах, коли не було адміністратора та лише двох пристроїв зберігання даних, і користувач, ймовірно, знав, чи є їх файл на дискеті чи на жорсткому диску.
• (Linux, звичайно, народився як однокомп'ютерна ОС, але це також було чітко розроблено з самого початку, щоб імітувати Unix якомога ближче на домашньому комп'ютері.)

Зовсім недавно ОС наближалися один до одного:

• Linux додав більше однокомп'ютерних однокористувацьких речей (наприклад, автоматичного керування); як це стало часто використовуватися в налаштуваннях для одного комп'ютера.
• Windows додала більше безпеки, мереж, підтримки декількох користувачів тощо; як мережі стали більш повсюдними, і Microsoft почала також робити ОС для серверів.

Але все одно легко сказати, що ці два є результатом різних традицій.

У нинішньої композиції є кілька переваг. Вони можуть бути згруповані в переваги блоку спеціальних файлів та переваги точок кріплення.

Спеціальні файли - це файли, що представляють пристрої. Одна з ідей, на якій був побудований unix, - це все, що є файлом. Це робить багато речей простими, наприклад, взаємодія з користувачем - це лише те, що файл читає і записує на tty пристрої, який є спеціальним файлом символів. Аналогічно перевірка наявності поганих блоків, розділення або форматування диска - це лише файлові операції. Це не має значення, якщо диск - mfm, ide, scsi, fiberchanel чи щось інше, це лише файл.

Але з іншого боку, ви, можливо, не хочете мати справу з усім диском або розділом лише з файлами, а в багатьох випадках більше файлів, ніж вміститься на диску. Отже, у нас є точки кріплення. Точка кріплення дозволяє помістити цілий диск (або розділ) в каталог. Ще в часи мого Slackware, коли жорсткий диск розміром з декількома сотнями Мб, звичайно було використовувати компакт-диск як / usr, а жорсткий диск для /, / usr / local та swap. Або ви можете поставити / на одному приводі та / додому на іншому.

Тепер я помітив, що ви згадали про встановлення компакт-диска на / media / cdrom, який зручно для комп'ютерів, які мають лише один привід CDDrom, але що робити, якщо у вас є більше одного? де ти повинен монтувати другий? чи третій? чи п’ятнадцятий? ви, звичайно, можете використовувати / media / cdrom2 тощо. Або ви можете встановити його на / src / samba / ресурси / windows-install, або / var / www, або де б це не мало сенсу робити.

Назва запитання задає: Чому нам потрібно монтуватися на Linux?

Один із способів інтерпретації цього питання: Чому нам потрібно видавати явні mountкоманди, щоб зробити файлові системи доступними в Linux?

Відповідь: у нас немає.

Вам не потрібно чітко монтувати файлові системи, ви можете домогтися, щоб це було зроблено автоматично, і дистрибутиви Linux вже роблять це для більшості пристроїв, як і Windows та Macs.

Так що, мабуть, це не те, що ви хотіли запитати.

Друга інтерпретація: Чому нам іноді потрібно видавати явні mountкоманди, щоб зробити файлові системи доступними в Linux? Чому б не змусити операційну систему завжди робити це за нас, а приховувати це від користувача?

Це питання, яке я читаю в тексті запитання, коли ви запитуєте:

Чому б зовсім не пропустити монтаж, зробіть наступне

ls /dev/cdrom

і чи є перелік вмісту компакт-диска?

Імовірно, ви маєте на увазі: чому б просто не зробити цю команду робити що

ls /media/cdrom

робить зараз?

Ну, у такому випадку /dev/cdromбуде дерево каталогів, а не файл пристрою. Отож, як видається, ваше справжнє запитання: чому в першу чергу мати файл пристрою?

Я хотів би додати відповідь до тих, що вже були надані.

Чому користувачі можуть бачити файли пристроїв?

Кожного разу, коли ви використовуєте компакт-диск чи будь-який інший пристрій, який зберігає файли, використовується програмне забезпечення, яке інтерпретує все, що є на вашому компакт-диску, як дерево файлів файлів. Він викликається щоразу, коли ви використовуєте lsчи будь-який інший тип команди чи програми, що здійснює доступ до файлів на вашому компакт-диску. Це програмне забезпечення є драйвером файлової системи для конкретної файлової системи, яка використовується для запису файлів на компакт-диск. Щоразу, коли ви перераховуєте, читаєте чи записуєте файли у файловій системі, завдання цього програмного забезпечення - переконатися, що відповідні операції читання та запису низького рівня виконуються на відповідному пристрої. Щоразу, коли ви mountвикористовуєте файлову систему, ви повідомляєте системі, який драйвер файлової системи використовувати для пристрою. Чи ви робите це явно за допомогоюmountкоманду або залиште це в ОС, щоб це було зроблено автоматично, це потрібно буде зробити, і, звичайно, програмне забезпечення драйвера файлової системи потрібно буде там бути в першу чергу.

Як драйвер файлової системи виконує свою роботу? Відповідь: це робиться, читаючи з файлу пристрою та записуючи його у файл. Чому? Відповідь, як ви вже заявляли: Unix був розроблений таким чином. У Unix файли пристроїв є звичайною низькою рівнем абстракції для пристроїв. Справжнє програмне забезпечення (драйвер пристрою) для певного пристрою повинно реалізовувати відкриття, закриття, читання та запис на пристрої як операції над файлом пристрою. Таким чином, програмному забезпеченню вищого рівня (наприклад, драйверу файлової системи) не потрібно знати стільки про внутрішню роботу окремих пристроїв. Драйвери пристроїв низького рівня та драйвери файлової системи можуть писатися окремо різними людьми, якщо вони домовляються про загальний спосіб взаємодії між собою, і саме для цього потрібні файли пристроїв.

Тому драйвери файлової системи потребують файлів пристрою.

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

Те саме стосується Linux: ви можете написати власний драйвер файлової системи (або драйвер пристрою), встановити його і потім використовувати. Це робить Linux (або будь-який інший варіант Unix) легко розширюваним (і це насправді є причиною запуску Linux): коли на ринок виходить якийсь новий апарат, або розроблений новий, розумніший спосіб реалізації файлової системи , хтось може написати код, щоб підтримати його, змусити його працювати та внести його в Linux.

Файли пристроїв полегшують це.

Багато двигунів бази даних можуть працювати безпосередньо з неочищеними дисками або розділами. Наприклад, MySQL:

http://dev.mysql.com/doc/refman/5.7/uk/innodb-raw-devices.html

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

Тому що /dev/cdromце пристрій, тоді /media/cdromяк файлова система . Для доступу до файлів на компакт-диску потрібно встановити перше на останньому.

Під час завантаження комп'ютера ваша операційна система вже автоматично монтує кореневу та користувацьку файлові системи з вашого фізичного жорсткого диска. Це просто додавання більшої кількості файлових систем для використання.

Усі операційні системи роблять це, проте деякі (наприклад, Windows, коли він встановлює компакт-диск на D:), роблять це прозоро. Linux залишає це вам, щоб ви мали більший контроль над процесом.

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

Таким чином, у фундаментальному сенсі, інтерфейс інтерфейсу для медіа повинен обробляти два види потенційних подій монтажу аналогічно, і немає хорошого способу для комп'ютерів керувати мережевими кріпленнями так само інтуїтивно, як це можливо для мережевих кріплень з іншими інтерфейсами для комп'ютерів, наприклад, смартфони, планшети та носячі комп’ютери, яким бракує можливості вставляти фізичні носії в пристрої. (Зверніть увагу, наскільки жахливий інтерфейс iPhone для перемикання SIM-карт, в них вставлені єдині пристрої фізичних медіа iOS.

Зауважте також, що інші популярні підходи до інтерфейсів інтерфейсів для цього типу фізичної коробки (наприклад, Windows 98, Windows 8, Mac OS X v10.2 (Jaguar) та Mac OS X v10.9 (Mavericks)) стикаються з тими ж проблемами та використовуйте додаткові діалогові інтерфейси графічного інтерфейсу, щоб розібрати потенційну плутанину (наприклад, Windows 8, як правило, налаштований на запит на кожен новий вставлений компакт-диск, чи слід його встановлювати як файлову систему, музичний носій або, якщо потрібно, колекцію відео MP4 ). Немає жодної причини, чому жоден із цих діалогів користувача не може бути використаний з Linux або іншими UNIX.