Чому файлова система Linux створена як єдине дерево каталогів?

Хтось може пояснити, чому Linux створений як єдине дерево каталогів?

Тоді як в Windows ми можемо мати декілька накопичувачів, як C:\, і D:\, в Unix є один корінь. Якась конкретна причина там?

Оскільки файлова система Unix передує Windows протягом багатьох років, можна переформулювати питання на тему "чому Windows використовує окремий позначення для кожного пристрою?".

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

Припустимо, у вас є система, де ОС статична і є програма, яка має високі вимоги до вводу / виводу. Ви можете встановити / usr лише для читання і поставити / opt (якщо програма там живе) на SSD-накопичувачі. Ієрархія файлової системи не змінюється. У Windows це набагато складніше, особливо з програмами, які наполягають на життя під C: \ Program Files \

Це почасти з історичних причин, а почасти тому, що це має більше сенсу.

Мультимедіа

Multics була першою операційною системою, яка запровадила ієрархічну файлову систему, як ми її знаємо сьогодні, з каталогами, які можуть містити каталоги. Посилаючись на " Файлову систему загального призначення для вторинного зберігання" RC Daley і PG Neumann:

У розділі 2 статті представлена ​​ієрархічна структура файлів, яка дозволяє гнучко використовувати систему. Ця структура містить достатньо можливостей для забезпечення універсальності. (…)

Для зручності розуміння структуру файлів можна розглядати як дерево файлів, деякі з яких - каталоги. Тобто, за одним винятком, кожен файл (наприклад, кожен каталог) виявляється безпосередньо вказаним точно однією гілкою точно в одному каталозі. Виняток становить кореневий каталог або корінь у корені дерева. Хоча це явно не вказується з жодного каталогу, корінь неявно вказується на вигадану гілку, яку відома файлова система. (…)

У будь-який час користувач вважається оперуючим в якомусь одному каталозі, який називається його робочим каталогом. Він може отримати доступ до файлу, на який фактично вказує запис у його робочому каталозі, просто вказавши ім'я запису. Більше одного користувача можуть мати один і той же робочий каталог одночасно.

Як і в багатьох інших аспектах, Multics прагнула гнучкості. Користувачі можуть працювати в піддереві файлової системи та ігнорувати решту, і все ж користуватися каталогіми для організації своїх файлів. Каталоги також використовувались для контролю доступу - атрибут READ дозволяв користувачам перелічувати файли в каталозі, а атрибут EXECUTE дозволяв користувачам отримувати доступ до файлів у цьому каталозі (це, як і багато інших функцій, жилося в unix).

Мультимедіа також слідувало принципу створення єдиного пулу зберігання даних. У роботі не зупиняється на цьому аспекті. Один пул пам’яті добре співпадав з обладнанням того часу: не було ніяких знімних пристроїв зберігання даних, принаймні жодного, про який користувачі не піклувалися б. У Multics був окремий пул резервного зберігання даних, але це було зрозуміло для користувачів.

Unix

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

Єдина ієрархічна файлова система добре підходила для Unix. Як і у Multics, пули пам’яті зазвичай не стосуються користувачів. Однак були знімні пристрої, і Unix відкрив їх користувачам за допомогою команд mountі umount(зарезервовано для "суперкористувача", тобто адміністратора). У «Системі розподілу часу UNIX» Деніс Річі та Кен Томпсон пояснюють:

Хоча корінь файлової системи завжди зберігається на одному пристрої, необов’язково, щоб вся ієрархія файлової системи знаходилась на цьому пристрої. Існує системний запит монтування з двома аргументами: ім'я існуючого звичайного файлу та ім'я спеціального файлу, асоційований об'єм зберігання якого (наприклад, пакунок диска) повинен мати структуру незалежної файлової системи, що містить власну ієрархію каталогів . Ефект mount полягає в тому, щоб змусити посилання на попередній звичайний файл посилатися замість цього на кореневий каталог файлової системи на знімному томі. Фактично, mount замінює лист дерева ієрархії (звичайний файл) цілком новим піддеревом (ієрархія, що зберігається на знімному томі). Після монтажу практично не існує різниці між файлами на знімному томі та файлами у постійній файловій системі. Наприклад, у нашій інсталяції кореневий каталог знаходиться на невеликому розділі одного з наших дисководів, а інший диск, який містить файли користувача, змонтований послідовністю ініціалізації системи. Система файлів, що встановлюється, створюється записом у відповідний спеціальний файл. Для створення порожньої файлової системи доступна утиліта, або можна просто скопіювати наявну файлову систему.

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

Windows

Windows простежує своє походження на двох лініях: VMS , операційну систему, спочатку розроблену для міні-комп'ютера VAX , і CP / M , операційну систему, розроблену для ранніх мікрокомп'ютерів Intel.

VMS мав розподілену ієрархічну файлову систему Files-11 . У Файлах-11 повний шлях до файлу містить ім'я вузла, позначення облікового запису на цьому вузлі, ім’я пристрою, шлях до дерева каталогів, ім'я файлу, тип файлу та номер версії. VMS мав потужну функцію логічного імені, що дозволяло визначати ярлики до конкретних каталогів, тому користувачам рідко доведеться дбати про «реальне» розташування каталогу.

CP / M був розроблений для комп'ютерів з 64 кБ оперативної пам’яті та дискети, тому він пішов для простоти. Не було каталогів, але посилання на файл може містити індикацію ( A:або B:) диска .

Коли MS-DOS 2.0 представив каталоги, це було зроблено з синтаксисом, сумісним з MS-DOS 1, який сам слідував за CP / M. Тож шляхи вкорінювалися на приводі з однобуквеною назвою. (Також символ косої риси /використовувався в VMS та CP / M для запуску параметрів командного рядка, тому для розділення каталогів довелося використовувати інший символ. Ось чому DOS та пізніші Windows використовують зворотну косу рису, хоча деякі внутрішні компоненти також підтримують косу рису ).

Windows зберегла сумісність з DOS та підходом до VMS, тому зберегла поняття букв диска навіть тоді, коли вони стали менш актуальними. Сьогодні під капотом Windows використовує шляхи UNC ( спочатку розроблені Microsoft та IBM для OS / 2 , спорідненого роду). Хоча це зарезервовано для споживачів живлення (можливо, це пов'язано з вагою історії), Windows дійсно дозволяє встановлювати через точки перезавантаження .

Не існує жодних проблем із безпекою щодо того, щоб мати одне дерево директорій.

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

Це лише одна частина генія, що стоїть за дизайном Unix .

Зауважте, що назви букв диска з MS-DOS, які зберігаються в сучасних Windows, є червоною оселедцем тут. Імена букв диска - не найкраще представлення структури файлової системи, яка має декілька коренів. Вони є солом'яним впровадженням такої системи.

Правильно реалізована файлова система, яка підтримує декілька коренів, дозволила б довільну назву для томів, наприклад dvdrom:/path/to/file.avi. Такі як система позбудеться від смішних проблем з користувальницьким інтерфейсом, які страждають на Windows. Наприклад, якщо ви підключите такий пристрій, як камера, інтерфейс Windows Explorer змушує вас повірити, що існує пристрій під назвою Camera (або будь-який інший), і у вас є такий шлях Computer\Camera\DCIM\.... Однак, якщо вирізати та вставити текстову версію цього шляху з Провідника, він насправді не працює, оскільки деякі компоненти імені шляху є вигадкою інтерфейсу користувача, невідомою для основної ОС. У правильно запровадженій системі з декількома коренями було б добре: було бcamera:\DCIM\...шлях, який розпізнається рівномірно на кожному рівні в системі. Більше того, якби ви перенесли старий жорсткий диск зі СТАРОГО ПК, ви б не застрягли з якоюсь буквою назви диска на кшталт F:, а навпаки, ви зможете назвати його всім, що хочете old-disk:.

Отже, якби Unix мав декілька коренів у структурі файлової системи, це було б зроблено як слід, а не як у MS-DOS та Windows з однобуквенними іменами накопичувачів. Іншими словами, порівняємо лише схему Unix з хорошою багатокореневою конструкцією.

Отже, чому Unix не має розумної реалізації декількох коренів на користь здорової однокореневої реалізації? Це, мабуть, просто для простоти. Точки кріплення забезпечують всю функціональність можливості доступу до томів через імена. Не потрібно розширювати простір імен додатковим синтаксисом префікса.

Математично кажучи, будь-який графік нерозчленованого дерева ("ліс") може бути з'єднаний, додавши кореневий вузол і зробивши дійові частини, що не перетинаються, його дітьми.

Більше того, більш гнучким є те, що обсяги не повинні бути на рівні коренів. Оскільки немає спеціального синтаксису, який позначає гучність (це лише компонент контуру), точки монтажу можуть бути де завгодно. Якщо ви піднесите до свого комп'ютера три старі диски, ви можете їх мати як /old-disk/one, /old-disk/twoі т. Д. Ви можете впорядковувати диски як завгодно, як упорядковуєте файли та каталоги.

Можна записати програми, які залежать від шляхів, а обгрунтованість шляхів може бути збережена під час переналаштування пристроїв зберігання даних. Наприклад, програми можуть використовувати відомі шляхи, такі як /var/logі /var/lib. Ви залежаєте від того, чи є ви на одному /var/logі /var/libтому ж обсязі диска або на окремих. Ви можете перемістити систему до нової топології зберігання, зберігаючи шляхи.

Точки кріплення - хороша ідея, і саме тому Windows використовує їх з Windows 2000 року.

Точки кріплення гучності є надійними щодо системних змін, які виникають при додаванні або видаленні пристроїв з комп'ютера. Microsoft Technet

І * nix, і Windows монтують свої накопичувачі. У Windows вони автоматично встановлюються в точках кріплення, які за замовчуванням розташовуються в алфавітному порядку. Ці параметри за замовчуванням:

• A:і B:=> дискети
• C: => перший розділ першого жорсткого диска
• D: => наступний розділ або наступний жорсткий диск або пристрій CD / DVD, якщо інших розділів немає.

Кожна з цих точок монтажу - це каталог.

У * nix, точки монтажу визначає користувач. Наприклад, у мене один розділ змонтований як /, а інший як /home. Отже, /homeце окремий привід, це було б еквівалентом скажімо E:в Windows.

В обох випадках Windows та * nix, точки монтажу - це окремі каталоги. Єдина відмінність полягає в тому, що в * nix ці окремі каталоги є підкаталогами /, C:тоді як у Windows кожна точка монтування монтується безпосередньо під /, під My Computerприпущенням.

З точки зору користувача, головна перевага полягає в тому, що кріплення повністю прозорі. Мені не потрібно знати, що каталог /homeнасправді знаходиться на окремому розділі. Я можу просто використовувати його як звичайний каталог. Натомість, у DOS, я повинен був би чітко називати це ім'ям точки монтажу, скажімоE:\home

Зовнішні накопичувачі монтуються майже однаково в обох системах. Скажіть D:для Windows та /mnt/cdromдля Linux. Кожне з них - це каталог, я не бачу різниці. Коли ви помістите компакт-диск на свій привід під Windows, диск змонтується так D:само, як і в Linux.

Я згоден з відповідями вище, особливо з відповіддю Дуга О'Ніла, але я думаю, що всі вони дещо пропускають, як і явні точки кріплення пристрою, такі як MS-DOS "C:" або "A:".

Роб Пайк написав «Прикрите ім’я» про синтаксис імен, але Расс Кокс кинув це :

Простіри імен ... найпотужніші, коли можна додавати нову семантику без додавання нового синтаксису.

Простір одного імені, де пристрої можуть бути довільно встановлені, дозволяє реально гнучкі операції. Я регулярно використовую /mnt/sdb1та /mnt/cdromтимчасово розміщую використаний на даний момент диск чи компакт-диск у загальній файловій системі. Зовсім не рідкість мати домашні каталоги на сервері NFS, так що незалежно від того, на якій машині ви входите, ви отримуєте однакові $HOMEскрізь.

Це зводиться до цього: наявність спеціального синтаксису для спеціальних речей ставить певні межі того, що ви можете зробити. Якщо ви можете змонтувати лише невикористаний диск або компакт-диск або DVD, або мережеву файлову систему / "поділитися" на "E:" або "W:" або будь-якому іншому, у вас набагато менше гнучкості.

Це нерозумно. У Windows також є одна точка ієрархії. Але це приховано і нестандартно. Як і більшість речей Windows.

У цьому випадку це концепція "Мій комп'ютер". Це еквівалент кореня (/) в Unix. Пам'ятайте, що root - це поняття, яке існує в ядрі. тобі подобається чи ні. Так само, як Windows трактує "Мій комп'ютер". Звичайно, ви можете змонтувати розділ на root в unix, і саме це робить більшість людей. І багато речей будуть шукати певний шлях для речей (наприклад, / тощо /), але ви не обмежені цим. Одним чином, монтуйте свої накопичувачі в / C: /. вам не заборонено робити це в unix.

C: \ не є коренем у Windows, це точка монтування одного розділу. ЯКІ ОБОВ'ЯЗКОВО бути на вищому рівні "Мій комп'ютер". Перебуваючи в unix, ви можете змонтувати перегородку під будь-яким іншим деревом. Отже, у Linux ви можете мати C: змонтований, /поки у вас встановлений D: змонтований /mnt/d/... або навіть навіть встановлений, /але це складно і залежить від того, як поводяться дві файлові системи під час монтажу поверх уже встановленого контуру.

Таким чином, ви можете отримати точно так само, як у вас з Windows, "змусивши" дотримуватися тих самих обмежень, які Windows випадково накладає на вас.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Тоді вам доведеться передати параметри кріплення параметрів завантаження. оскільки у вас не буде / etc / ..., але це також імітує обмеження, які встановлює вікно, як те, що він робить.

Причина того, що у Windows є літери накопичувача, ймовірно, йде далеко далі, ніж Microsoft та DOS. Присвоєння літер знімним накопичувачам було поширеним для систем IBM, тому Microsoft, можливо, щойно діяла за вказівками IBM, копіюючи CP / M. І спочатку DOS так і не мав каталогів.

Коли MS-DOS працював на комп’ютерах з одним або двома знімними дисками та без фіксованого носія, вам не дуже потрібна файлова система з каталогами. З одним або, можливо, двома, 180-кілобайтними дисками, у вас ніколи не було достатньо файлів, щоб не було проблем з їх організацією.

https://en.wikipedia.org/wiki/Drive_letter_assignment

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

З іншого боку, букви DOS для накопичувачів є гарною конструкцією для ПК з 1 або 2 дискетами та однодисковим накопичувачем. Велика дискета 5,25 '- це завжди A :, маленька 3,5' завжди B :, а дисковий диск завжди C :. Ви завжди знаєте, чи копіюєте ви файл на дискету чи десь на диск. Вам не потрібна гнучкість, якщо ви фізично не можете підключити більше ніж 2 дискети та 2 (або 4) жорсткі диски.

Дизайн DOS був більш сприятливим для кінцевих користувачів, а дизайн Unix - адміністратором. Тепер літери диска - це тягар для Windows, користувачі більше покладаються на автоматичне відкривання вікна провідника із вмістом знімного диска, ніж знаючи його букву ... Ubuntu робить те ж саме.

Це насправді не так. Windows використовує іншу схему шляхів (ну, не та сама)

"Листи одиниці" - це лише те, що легко запам'ятовуються шляхами, дисками та розділами.

Шляхи ARC визначають шлях до файлу у Windows (але вони видимі користувачеві лише під час завантаження):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

У Windows NT немає зв’язку між дисками, розділами та одиничними літерами: Ви можете "помістити" весь том у папку (наприклад: c: \ myseconddisk міг бути весь фізичний диск!)

Я хотів би зазначити дві речі -

1. Жорсткі диски в Linux насправді таким чином присвоюють літери / імена, як / dev / sdb1. Але вони можуть бути встановлені в будь-якому місці, до якого можна дістатися з єдиної / кореневої структури
2. Найпоширенішою причиною того, що люди (включаючи мене в минулому) мали окремі накопичувачі в Windows, полягало в тому, щоб десь зберігати документи, музику, програми тощо, щоб, коли Windows неминуче потрібно було перевстановити або замінити, будь то оновлення чи віруси чи відмова файлової системи, до цих файлів все ще був доступ. У мене немає такої проблеми в Linux - файлова система набагато надійніша, ОС не ламається, якщо якимось прямим дією або помилкою з мого боку (оо! Кровоточить репо репортаж, спробуємо це!) Та оновленнями є ЗПД простішими. І, в рідкісному випадку, мені довелося перевстановити, оскільки все програмне забезпечення було доступне через репости або ppa-файли, які я додав (і я міг легко скопіювати свій домашній директор з живого диска),

Якщо ви оглянетесь назад в історію, ви також можете побачити, що Unix запустився під час 8 трекових стрічкових систем для аудіо та 9 трекових систем даних IBM (8 треків / 8 біт для даних, один для паритету). Технічно дуже те саме.

У той час інформація про розташування файлів зберігалася в частинах інформації на стрічці та визначалася вперед та назад, коли ви читали дані зі стрічки (наприклад, файл із початковим розташуванням та кінцевим підписом); це також пояснює вам, чому у вас не було однієї жиру на початку диска - у вас було кілька разів, щоб прискорити пошук. А якщо у вас було кілька дисків, вони пов’язані всередині / dev та за адресою файлу, який ви пересували між пристроями.

Я вважаю, що ви можете мати думку, що це було запущено просто раніше, і що рішення, що стоїть за областю MS Dos (CP / M) і пізніше Windows NT, просто пов'язане з літерами накопичувача VM мейнфрейму замість однієї точки введення, оскільки на той час це виглядало Більш сучасних, даних на сьогоднішній день не існувало, і вони не думали, що у вас в кінцевому підсумку не вистачить букв диска або що це буде надмірно захаращено.

9-трек-привід та присвоєння листа