Начертите дерево структуры каталогов на диске, если известно, что он содержит файлы со следующим

Обновлено: 02.07.2024

Файловая система — это логическая коллекция файлов на разделе или диске. Раздел — это контейнер для информации, который при желании может занимать весь жесткий диск.

Ваш жесткий диск может иметь различные разделы, которые обычно содержат только одну файловую систему, например, одна файловая система содержит файловую систему / или другая файловая система /home.

Одна файловая система на раздел обеспечивает логическое обслуживание и управление различными файловыми системами.

Все в Unix считается файлом, включая физические устройства, такие как DVD-ROM, USB-устройства и дисководы.

Структура каталогов

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

Файловая система Unix — это набор файлов и каталогов со следующими свойствами —

У него есть корневой каталог (/), содержащий другие файлы и каталоги.

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

Согласно соглашению, корневой каталог имеет номер инода 2, а потерянный+найденный каталог имеет номер инода 3. Номера инодов 0 и 1 не используются. Номера индексных дескрипторов файлов можно увидеть, указав параметр -i для команды ls.

Он автономен. Между одной файловой системой и другой нет никаких зависимостей.

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

Это корневой каталог, который должен содержать только те каталоги, которые необходимы на верхнем уровне файловой структуры

Здесь находятся исполняемые файлы. Эти файлы доступны всем пользователям

Это драйверы устройств

Команды каталога супервизора, файлы конфигурации, файлы конфигурации дисков, допустимые списки пользователей, группы, Ethernet, хосты, куда отправлять критические сообщения

Содержит файлы общей библиотеки и иногда другие файлы, связанные с ядром

Содержит файлы для загрузки системы

Содержит домашний каталог для пользователей и других учетных записей

Используется для монтирования других временных файловых систем, таких как cdrom и дискета для дисковода компакт-дисков и дисковода гибких дисков соответственно

Содержит все процессы, помеченные как файлы по номеру процесса или другой информации, которая является динамической для системы

Хранит временные файлы, используемые между загрузками системы

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

Обычно содержит файлы переменной длины, такие как файлы журнала и печати, а также файлы любого другого типа, которые могут содержать переменный объем данных

Содержит двоичные (исполняемые) файлы, обычно предназначенные для системного администрирования. Например, утилиты fdisk и ifconfig

Содержит файлы ядра

Навигация по файловой системе

Теперь, когда вы понимаете основы работы с файловой системой, вы можете перейти к нужным файлам. Следующие команды используются для навигации по системе —

имя файла с котом

Отображает имя файла

Перемещает вас в указанный каталог

копировать файл1 файл2

Копирует один файл/каталог в указанное место

имя файла

Определяет тип файла (двоичный, текстовый и т. д.)

найти каталог с именем файла

Находит файл/каталог

имя главного файла

Показывает начало файла

меньше имени файла

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

Показывает содержимое указанного каталога

mkdir имя_каталога

Создает указанный каталог

больше имени файла

Просматривает файл от начала до конца

мв файл1 файл2

Перемещает расположение или переименовывает файл/каталог

Показывает текущий каталог, в котором находится пользователь

rm имя файла

rmdir имя_каталога

Удаляет каталог

название хвостового файла

Показывает конец файла

нажмите имя файла

Создает пустой файл или изменяет существующий файл или его атрибуты

где имя файла

Показывает расположение файла

какое имя файла

Показывает расположение файла, если он находится в вашем PATH

Вы можете использовать справку Manpage, чтобы проверить полный синтаксис для каждой упомянутой здесь команды.

Команда df

Первый способ управлять пространством раздела – это команда df (диск свободен). Команда df -k (disk free) отображает использование дискового пространства в килобайтах, как показано ниже —

Для некоторых каталогов, таких как /devices, в столбцах "Кбайты", "Используется" и "Доступно" отображается 0, а также 0 % емкости.Это специальные (или виртуальные) файловые системы, и хотя они находятся на диске в каталоге /, сами по себе они не занимают место на диске.

Вывод df -k обычно одинаков во всех системах Unix. Вот что он обычно включает —

Имя физической файловой системы

Общее количество килобайт свободного места на носителе

Общий объем используемого пространства (файлами) в килобайтах

Общее количество килобайт, доступное для использования

Процент общего пространства, используемого файлами

На чем смонтирована файловая система

Вы можете использовать параметр -h (человекочитаемый), чтобы отобразить вывод в формате, который показывает размер в более понятной записи.

Командование дю

Команда du (использование диска) позволяет указать каталоги для отображения использования дискового пространства в конкретном каталоге.

Эта команда полезна, если вы хотите определить, сколько места занимает конкретный каталог. Следующая команда отображает количество блоков, потребляемых каждым каталогом. Один блок может занимать 512 байт или 1 килобайт в зависимости от вашей системы.

Опция -h упрощает понимание вывода —

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

Файловая система должна быть смонтирована, чтобы ее можно было использовать в системе. Чтобы увидеть, что в настоящее время смонтировано (доступно для использования) в вашей системе, используйте следующую команду —

Каталог /mnt, согласно соглашению Unix, — это место, где размещаются временные монтирования (например, дисководы компакт-дисков, удаленные сетевые диски и дисководы гибких дисков). Если вам нужно смонтировать файловую систему, вы можете использовать команду mount со следующим синтаксисом —

Например, если вы хотите смонтировать компакт-диск в каталог /mnt/cdrom, вы можете ввести -

Это предполагает, что ваше устройство CD-ROM называется /dev/cdrom и вы хотите смонтировать его в /mnt/cdrom. Обратитесь к справочной странице mount для получения более подробной информации или введите mount -h в командной строке для получения справочной информации.

После монтирования вы можете использовать команду cd для навигации по вновь доступной файловой системе через только что созданную точку монтирования.

Размонтирование файловой системы

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

Например, чтобы размонтировать компакт-диск, используйте следующую команду –

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

Квоты пользователей и групп

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

Квоты работают с двумя ограничениями, которые позволяют пользователю предпринять какие-либо действия, если объем пространства или количество дисковых блоков начинают превышать ограничения, установленные администратором —

Мягкий лимит — если пользователь превышает установленный лимит, существует льготный период, который позволяет пользователю освободить место.

Жесткое ограничение — при достижении жесткого ограничения, независимо от льготного периода, дальнейшие файлы или блоки не могут быть выделены.

Существует ряд команд для управления квотами —

Отображает использование диска и ограничения для пользователя группы

Это редактор квот. С помощью этой команды можно изменить квоту пользователей или групп

Сканирует файловую систему на предмет использования диска, создает, проверяет и восстанавливает файлы квот

Это редактор квот из командной строки

Это сообщает системе, что дисковые квоты должны быть включены для одной или нескольких файловых систем

Это сообщает системе, что дисковые квоты должны быть отключены для одной или нескольких файловых систем

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

Вы можете использовать справку Manpage, чтобы проверить полный синтаксис для каждой упомянутой здесь команды.

Задумывались ли вы, почему определенные программы расположены в /bin, или /sbin, или /usr/bin, или /usr/sbin?

Например, команда less находится в каталоге /usr/bin. Почему не /bin, или /sbin, или /usr/sbin? Чем отличаются все эти каталоги?


В этой статье давайте рассмотрим структуры файловой системы Linux и поймем значение отдельных каталогов высокого уровня.

1. / — корень

  • Каждый отдельный файл и каталог начинается с корневого каталога.
  • Только пользователь root имеет права на запись в этот каталог.
  • Обратите внимание, что /root — это домашний каталог пользователя root, который не совпадает с /.

2. /bin — пользовательские двоичные файлы

  • Содержит двоичные исполняемые файлы.
  • Обычные команды Linux, которые необходимо использовать в однопользовательских режимах, находятся в этом каталоге.
  • Здесь находятся команды, используемые всеми пользователями системы.
  • Например: ps, ls, ping, grep, cp.

3. /sbin — системные двоичные файлы

  • Как и /bin, /sbin также содержит двоичные исполняемые файлы.
  • Однако команды Linux, расположенные в этом каталоге, обычно используются системным администратором для обслуживания системы.
  • Например: iptables, перезагрузка, fdisk, ifconfig, swapon

4. /etc — файлы конфигурации

  • Содержит файлы конфигурации, необходимые для всех программ.
  • Также содержит сценарии запуска и завершения работы, используемые для запуска/остановки отдельных программ.
  • Например: /etc/resolv.conf, /etc/logrotate.conf

5. /dev – файлы устройств

  • Содержит файлы устройств.
  • К ним относятся терминальные устройства, USB или любое устройство, подключенное к системе.
  • Например: /dev/tty1, /dev/usbmon0

6. /proc — информация о процессе

  • Содержит информацию о системном процессе.
  • Это псевдофайловая система, содержащая информацию о запущенном процессе. Например: каталог /proc/ содержит информацию о процессе с этим конкретным pid.
  • Это виртуальная файловая система с текстовой информацией о системных ресурсах. Например: /proc/uptime

7. /var — файлы переменных

  • var означает переменные файлы.
  • Содержимое файлов, которые, как ожидается, будут увеличиваться, можно найти в этом каталоге.
  • К ним относятся — файлы системного журнала (/var/log); пакеты и файлы баз данных (/var/lib); электронная почта (/var/mail); очереди печати (/var/spool); заблокировать файлы (/var/lock); временные файлы, необходимые при перезагрузке (/var/tmp);

8. /tmp — временные файлы

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

9. /usr — Пользовательские программы

  • Содержит двоичные файлы, библиотеки, документацию и исходный код для программ второго уровня.
  • /usr/bin содержит двоичные файлы для пользовательских программ. Если вы не можете найти пользовательский двоичный файл в /bin, поищите в /usr/bin. Например: at, awk, cc, less, scp
  • /usr/sbin содержит двоичные файлы для системных администраторов. Если вы не можете найти системный двоичный файл в /sbin, поищите в /usr/sbin. Например: atd, cron, sshd, useradd, userdel
  • /usr/lib содержит библиотеки для /usr/bin и /usr/sbin
  • /usr/local содержит пользовательские программы, которые вы устанавливаете из исходного кода. Например, когда вы устанавливаете apache из исходного кода, он находится в папке /usr/local/apache2
  • .

10. /home – Домашние каталоги

  • Домашние каталоги для хранения личных файлов всех пользователей.
  • Например: /home/john, /home/nikita

11. /boot — файлы загрузчика

  • Содержит файлы, связанные с загрузчиком.
  • Файлы ядра initrd, vmlinux, grub находятся в папке /boot
  • Например: initrd.img-2.6.32-24-generic, vmlinuz-2.6.32-24-generic

12. /lib — системные библиотеки

  • Содержит файлы библиотеки, поддерживающие двоичные файлы, расположенные в каталогах /bin и /sbin
  • Имена файлов библиотеки: ld* или lib*.so.*
  • Например: ld-2.11.1.so, libncurses.so.5.7

13. /opt — дополнительные приложения

  • opt означает необязательный.
  • Содержит дополнительные приложения от отдельных поставщиков.
  • дополнительные приложения следует устанавливать в подкаталог /opt/ или /opt/.

14. /mnt — каталог монтирования

  • Временный каталог монтирования, в который системные администраторы могут монтировать файловые системы.

15. /media – съемные носители

  • Временный каталог монтирования для съемных устройств.
  • Например, /media/cdrom для компакт-диска; /media/floppy для дисководов; /media/cdrecorder для записи компакт-дисков

16. /srv — служебные данные

  • srv означает обслуживание.
  • Содержит данные, относящиеся к конкретным службам сервера.
  • Например, /srv/cvs содержит данные, относящиеся к CVS.

Если вам понравилась эта статья, вам также может понравиться...

Комментарии к этой записи закрыты.

идеально. пора было кому-то это сделать!

Это распространенное заблуждение, но /usr на самом деле не имеет ничего общего со словом «пользователь», а является аббревиатурой от «специальных процедур UNIX». Нет, не важно 😉

но следовало бы сделать его немного более подробным…!

Отлично.
Почти пользователь никогда не знал.

хммм… но почему ‘/usr/bin/’ или ‘/usr/local/bin/’ отсутствует.

Спасибо, что собрали это воедино. Иногда мне было интересно, что означают некоторые из каталогов, таких как /srv и /opt, поскольку я не слишком часто бываю в них.

В некоторых системах есть папка /src, в которой находится исходный код ядра

Отлично! Просто и понятно.

Спасибо, приятель, как раз вовремя, лол.. Еще раз спасибо

Я до сих пор не знаю, что содержит /usr/sbin. Системные двоичные файлы для пользовательских приложений?Имеет ли это смысл? Из приведенного выше описания кажется, что двоичный файл находится в каталоге /sbin или /usr/sbin.

Спасибо. Это здорово!
Почему мой каталог /srv пуст?

@Ronald
Понятно, спасибо, что разъяснили.

В некоторых системах /usr находится на отдельном разделе (возможно, в сети) от /. Таким образом, все, что абсолютно необходимо в однопользовательском режиме, должно находиться в /bin, /lib, /etc или /sbin. /usr/sbin предназначен для инструментов системного администрирования, которые не нужно использовать в данный момент. (Кроме того, программы в /bin и /sbin должны иметь общие библиотеки в /lib, чтобы они были доступны до монтирования /usr — а / может быть очень маленьким в такой настройке).

Мне нравится стандарт иерархии файловой системы. Люблю это.

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

Они неправы, и это потому, что они этого не понимают. Файл спецификации FHS содержит гораздо более подробное объяснение того, как должна выглядеть файловая система POSIX. Но он чрезвычайно исчерпывающий и может даже сбить с толку.

Хороший способ объяснить FHS POSIX — сказать: «все на своих местах, и для всего есть место».

FHS также позволяет мне легко выяснить, где что-то может быть, будь то файл конфигурации или актив для программы, которую я использую, с которой я хочу возиться. Прогноз действительно важен для иерархии файловой системы. И даже большая часть программного обеспечения Linux рассчитывает на соблюдение FHS, хотя, если вы собираете из исходного кода систему, не очень соответствующую требованиям, вы можете использовать аргументы скрипта configure, чтобы внести изменения в способ сборки программы, чтобы она выглядела в нужных местах.

У меня есть некоторые критические замечания, в FHS есть некоторые недостатки. Я нахожу /opt ужасной вещью, каталогом, который поощряет совершенно неорганизованный беспорядок для некоторых разработчиков, которые просто сбрасывают все, что они сделали, вместо того, чтобы пытаться заставить FHS работать. Навигация по /opt для ресурсов или конфигурации - это ужасный кошмар, и если бы я делал учебник по созданию программы, я бы сказал людям полностью избегать /opt и вместо этого разбрасывать свои файлы по лучшим местам, где они будут лучше. позаботился о: /usr, /etc, что угодно еще. /opt — это зло.

Я также считаю, что /mnt сегодня полностью не используется в пользу /media. Даже для локальных файловых систем, а не на съемных носителях: HAL и udev полностью игнорируют /mnt. Я думаю, что FHS должен отказаться от этого.

/usr/local я также считаю ненужным, особенно потому, что он не служит никакой реальной цели, которую не может выполнить сам /usr. Это пережиток тех далеких дней, когда в системе не было самого /usr, но был /usr/local. Мне не нужно вам говорить, даже в системах сервер-клиент ths больше не нужен. /usr/local также следует признать устаревшим, поскольку базовая структура /usr уже охватывает все базы.

Теперь я хочу отметить, что сам /dev также рассматривается как псевдофайловая система. Когда Linux не работает, на самом деле там всего около 3-4 статических файлов, и во время запуска udev заполняет /dev при загрузке системы, обычно в промежутке между моментом монтирования initramfs и моментом, когда постоянные сценарии инициализации попадают в Фаза модпроба. Это связано с тем, что аппаратное обеспечение, как и процессы, может изменяться в системе, и оно должно быть готово к изменениям вместе с аппаратным обеспечением. Это также потому, что в ДЕЙСТВИТЕЛЬНО старые дни UNIX не было реального метода автоматического обнаружения оборудования, как мы знаем его сегодня: ни udev, ни HAL. Вы добавили некоторое оборудование, вам нужно было убедиться в нескольких вещах:

<р>1. У вас есть водитель. Скорее всего, в те дни ядро, с которым вы работали, было на 100% монолитным, без всяких новомодных загружаемых модулей ядра. Таким образом, вы сделали ставку на два исхода с вашей реализацией UNIX: ваше ядро ​​имело встроенный драйвер для вашего программного обеспечения, мало чем отличается от того, если вы встроили драйвер прямо в ядро ​​​​Linux, а не в виде модуля. ИЛИ. Вы должны были предоставить драйвер пользовательского пространства, специально написанный для вашего ядра… каким-то образом. Это одна из причин, почему в первые дни ИТ-отделы компаний, использующие UNIX, имели собственных программистов и дизайнеров. В те дни это было затруднено, потому что большинство UNIX все еще были проприетарными.

<р>2. Вы понимаете, как все это работает: драйвер, железо и ядро. По крайней мере, достаточно знать, как настроить его так, чтобы драйвер мог взаимодействовать с ядром и, в свою очередь, взаимодействовать с оборудованием.

<р>3. Вы точно знаете, КАКОЙ файл устройства создать. Загляните как-нибудь в /dev. Обратите внимание на номенклатуру файлов. Вы должны были убедиться, что имя файла правильное, чтобы драйвер и программы, использующие аппаратное обеспечение, действительно могли взаимодействовать друг с другом с помощью необработанных данных.

Теперь, даже в те дни у многих хакеров были сценарии оболочки, чтобы помочь им, но они были в значительной степени предоставлены сами себе.У них не было thiong udev или HAL, проверяющих всю систему на наличие аппаратного обеспечения, и уж точно не было модулей ядра, чтобы убедиться, что их аппаратное обеспечение, и только его аппаратное обеспечение, возится с ядром.

@Yaro:
Основная причина разделения /usr и /usr/local в настоящее время заключается в том, что / и /usr обычно обслуживаются вашим менеджером пакетов, а /usr/local предназначен для локального системного администратора. Если вы начнете что-то менять в /usr, не заходя в менеджер пакетов, вы сами по себе (при обновлениях что-то может внезапно сломаться); если вы просто устанавливаете в /usr/local, то вы сохраняете независимость от PM без поломки, которая может быть вызвана перезаписью файлов, которые, по мнению менеджера пакетов, принадлежат ему.

@ABCD – я исправляюсь. Я полагаю, что это имеет смысл, хотя, по моему опыту, /usr/local не так надежен, как мог бы быть в PATH (мне даже пришлось явно указать некоторым скриптам configure использовать /usr вместо работы).

Мне нравится, как это делает Arch. Они настоятельно рекомендуют создать PKGBUILD, чтобы ваш менеджер пакетов мог следить за ним. Вероятно, это лучший способ сделать исходные сборки чего-либо. После этого вы можете отправить этот PKGBUILD в AUR и поделиться плодами своего труда: выяснить, как что-то собрать и установить.

Тем не менее, мое мнение о том, что /opt остается в силе, кажется ненужным и мучительным для навигации, если вы хотите что-то оттуда.

Спасибо за объяснение по поводу /usr/sbin, ABCD 🙂

/srv/ информация неверна.

Он должен содержать данные, *обслуживаемые* этим Linux-боксом. Однако пока нет стандарта, как должны быть структурированы данные.

usr означает системный ресурс Unix

Спасибо за эту замечательную статью. Это кратко и легко читается.
Кстати, в /medica/cdrom есть опечатка (лишняя буква c в медиа)

Мне очень нравится ваш блог. Продолжай в том же духе!

IIRC sbin на самом деле являются статическими двоичными файлами, т. е. они статически связывают зависимости своих библиотек и поэтому не зависят ни от каких файлов библиотек (т. е. /lib, /usr/lib, /usr/loca/lib и др.).

Изначально на диске был небольшой загрузочный раздел (чем меньше раздел, тем меньше вероятность возникновения ошибки диска). В этом загрузочном разделе были файлы /etc, /sbin и /boot. Этого достаточно, чтобы загрузить ОС и остальные разделы.

@SurrealWombat — Нет, вещи в sbin могут быть динамически связаны со своими библиотеками. «s» в sbin означает не «статический», а «системный».

sbin отличается от bin тем, что обычно это просто утилиты, которые должны использовать системные администраторы, и, как правило, для работы им требуются права root (например, fdisk, dd или fsck.), тогда как bin — это двоичные файлы общего назначения для повседневного использования ( ш или лс или ср).

То же самое относится к одним и тем же подкаталогам в /usr и /usr/local.

Кроме того, то, что находится в «корневом» sbin/bin, в первую очередь является тем, что вам абсолютно необходимо, если вы можете монтировать только / и никакие другие файловые системы. FHS довольно ясно об этом. материалы в /usr и /usr/lib нельзя планировать в однопользовательском режиме или в чрезвычайных ситуациях, поскольку они могут и часто находятся в разных файловых системах.

Это не значит, что системные двоичные файлы не связаны статически. Но обычно вы обнаружите, что статические двоичные файлы используются только в раннем пользовательском пространстве (например, когда вы запускаете initramfs до того, как постоянный / станет доступен для системы).

Чемп, это была удивительно ПОТРЯСАЮЩАЯ статья………..
Такая статья заставляет вас снова ВЛЮБИТЬСЯ в LINUX………

Отличная работа, очень информативный раздел комментариев… 9,5/10

Я до сих пор не понимаю, в чем разница между всеми этими каталогами bin для одного пользователя, такого как я, почему бы не использовать только один каталог, чтобы избежать хлопот?

@sxaxer — потому что разные каталоги bin и sbin в целом служат разным целям. Да, они содержат исполняемые двоичные файлы, но /bin и /usr/bin содержат исполняемые файлы с очень разным приоритетом. Дело не в том, сколько у вас пользователей, а в том, чтобы все было организовано. Собрав все в один огромный каталог двоичных файлов, поиск двоичных файлов станет намного сложнее.

/bin и /sbin предназначены для двоичных файлов, необходимых на тот случай, если вам нужно перейти в однопользовательский режим, который используется исключительно для целей восстановления/обслуживания и должен содержать только программное обеспечение, необходимое для обеспечения РАБОТЫ системы без дополнительных служб. запущены или смонтированы файловые системы. /bin — самая распространенная команда, которую, вероятно, использует каждый пользователь независимо от того, что (ls, cp, ps и т. д.), тогда как /sbin — это все, что касается системного администрирования, такого как fsck, init или fdisk.

/usr/bin и /usr/sbin — это в основном некритические программы в вашей системе. Системе технически не нужно, чтобы они загружались, по крайней мере, в режиме восстановления barebones, хотя вещи в обоих удаляемых, вероятно, будут препятствовать работе ПОЛНОЙ системы, поскольку такие вещи, как X или ваши обычные обычные приложения, должны закончиться в / usr/bin или /usr/sbin.

/opt особенный.В основном это делается для программ, которые вообще не пытаются следовать FHS, как правило, для проприетарных приложений. Хотя иногда туда могут быть помещены некоторые большие дополнения, такие как 32-битная среда chroot или мультибиблиотека. Но большинство ваших обычных приложений будут находиться в /usr/bin, а все, кроме основных системных команд для обслуживания, которые администратор может использовать в НОРМАЛЬНЫХ ситуациях выполнения системы (например, не пытаясь починить что-то сломанное), будет находиться в /usr/sbin. .

/etc часто содержит некоторые сценарии, но в основном для поддержки системы во время изменений уровня выполнения, таких как запуск демонов или при загрузке, перезагрузке или завершении работы. Они называются загрузочными скриптами, причина, по которой они находятся в /etc, а не в /sbin, заключается в том, что init считает, что они являются частью и рассматриваются как часть конфигурации системы (поскольку изменение этих скриптов меняет поведение вашей системы на низких уровнях, следовательно, скрипты все же конфигурационные, просто необычного вида.)

FHS очень хорошо организована. Если вы знаете, как это работает, вы сможете быстро и легко найти практически любой файл в Linux или UNIX, который вам может понадобиться.

@sxaxer- Кроме того, FHS спроектирован так, что может быть практически одна универсальная переменная среды PATH, которая работает ВСЕГДА. Это значит, что вам действительно НЕ НУЖНО искать исполняемые файлы, вы можете просто ИСПОЛЬЗОВАТЬ их. Подход FHS, безусловно, намного лучше, чем подход Windows.

@Yaro Kasear
Большое спасибо.
И последний вопрос: когда я хочу скомпилировать что-то, что я хочу перейти в /usr/bin и /usr/lib, что я должен ввести после ./configure?

Это будет ./configure –prefix=/usr

ПРИМЕЧАНИЕ. Не все пакеты соответствуют стандартам GNU autotools. Если исходный пакет использует cmake, вы, вероятно, обнаружите, что вам нужно сделать это по-другому.

Возможно, это имеет смысл для администраторов серверов, но для настольной системы FHS — полная неразбериха. У OS X и Gobolinux есть все аргументы по этому поводу, поэтому я не буду повторять их здесь.

Ни один обычный человек не может найти никакой логики в этой «организации». Только люди, потратившие годы на знакомство с этой штукой, могут сказать, что она «организована».

Теперь мы знаем, как просматривать файлы и каталоги, но как их создавать?

В этом выпуске мы узнаем о создании и перемещении файлов и каталогов на примере каталога для упражнений/записи.

Шаг первый: посмотрите, где мы находимся и что у нас уже есть

Мы по-прежнему должны находиться в каталоге shell-lesson-data на рабочем столе, что мы можем проверить, используя:

Далее мы перейдем в каталог для упражнений/записи и посмотрим, что в нем содержится:

Создать каталог

Давайте создадим новый каталог с именем thesis с помощью команды mkdir thesis (у которой нет вывода):

Как можно догадаться по названию, mkdir означает «создать каталог». Поскольку тезис является относительным путем (т. е. не имеет начального слэша, например /what/ever/thesis ), новый каталог создается в текущем рабочем каталоге:

Поскольку мы только что создали каталог тезисов, в нем еще ничего нет:

Обратите внимание, что mkdir не ограничивается созданием отдельных каталогов по одному. Параметр -p позволяет mkdir создать каталог с вложенными подкаталогами за одну операцию:

Опция -R команды ls отобразит список всех вложенных подкаталогов внутри каталога. Давайте используем ls -FR для рекурсивного отображения новой иерархии каталогов, которую мы только что создали в каталоге проекта:

Два способа сделать одно и то же

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

Хорошие имена для файлов и каталогов

  1. Не используйте пробелы.

    Пробелы могут сделать имя более осмысленным, но, поскольку пробелы используются для разделения аргументов в командной строке, лучше избегать их в именах файлов и каталоги. Вместо этого вы можете использовать - или _ (например, north-pacific-gyre/ , а не north pacific gyre/ ). Чтобы проверить это, попробуйте ввести mkdir north pacific gyre и посмотрите, какой каталог (или каталоги!) создается при проверке с помощью ls -F .

  2. Не начинайте имя с - (тире).

    Команды рассматривают имена, начинающиеся с -, как параметры.

  3. Наклеивайте буквы, цифры, . (точка или точка), - (тире) и _ (подчеркивание).

    Многие другие символы имеют особое значение в командной строке. О некоторых из них мы узнаем на этом уроке. Существуют специальные символы, которые могут привести к неправильной работе вашей команды и даже к потере данных.

Создать текстовый файл

Давайте изменим наш рабочий каталог на thesis с помощью cd , затем запустим текстовый редактор Nano, чтобы создать файл с именем draft.txt :

Какой редактор?

Когда мы говорим, что nano — это текстовый редактор, мы на самом деле имеем в виду текст: он может работать только с простыми символьными данными, а не с таблицами, изображениями или любым другим удобным для человека носителем. Мы используем его в примерах, потому что это один из наименее сложных текстовых редакторов. Однако из-за этой особенности он может быть недостаточно мощным или достаточно гибким для работы, которую вам нужно будет выполнить после этого семинара. В системах Unix (таких как Linux и macOS) многие программисты используют Emacs или Vim (на изучение обоих требуется больше времени) или графический редактор, такой как Gedit. В Windows вы можете использовать Notepad++. В Windows также есть встроенный редактор под названием «Блокнот», который можно запустить из командной строки так же, как и nano для целей этого урока.

Независимо от того, какой редактор вы используете, вам необходимо знать где он ищет и сохраняет файлы. Если вы запустите его из оболочки, он (вероятно) будет использовать ваш текущий рабочий каталог в качестве местоположения по умолчанию. Если вы используете меню «Пуск» вашего компьютера, вместо этого он может захотеть сохранить файлы на рабочем столе или в каталоге документов. Вы можете изменить это, перейдя в другой каталог при первом нажатии кнопки «Сохранить как…»

Давайте напечатаем несколько строк текста. Как только мы довольны нашим текстом, мы можем нажать Ctrl + O (нажмите клавишу Ctrl или Control и, удерживая ее, нажмите клавишу O), чтобы записать наши данные на диск (нас спросят, какой файл мы хотим чтобы сохранить это в: нажмите клавишу «Ввод», чтобы принять предложенный по умолчанию вариант draft.txt ).

скриншот текстового редактора nano в действии

После того, как наш файл будет сохранен, мы можем использовать Ctrl + X, чтобы выйти из редактора и вернуться в оболочку.

Control, Ctrl или клавиша ^

  • Control-X
  • Control+X
  • Ctrl + X
  • Ctrl+X
  • ^X
  • C-x

nano не оставляет никаких выводов на экране после выхода, но теперь ls показывает, что мы создали файл с именем draft.txt :

Создание файлов другим способом

Мы увидели, как создавать текстовые файлы с помощью редактора nano. Теперь попробуйте следующую команду:

  1. Что сделала сенсорная команда? Когда вы просматриваете свой текущий каталог с помощью проводника файлов с графическим интерфейсом, отображается ли файл?

  2. Используйте ls -l для проверки файлов. Насколько велик my_file.txt?

  3. В каких случаях вам может понадобиться создать файл таким образом?

Решение

  1. Команда touch создает новый файл с именем my_file.txt в вашем текущем каталоге. Вы можете просмотреть этот вновь сгенерированный файл, набрав ls в командной строке. my_file.txt также можно просмотреть в проводнике файлов с графическим интерфейсом.

  2. При проверке файла с помощью ls -l обратите внимание, что размер файла my_file.txt равен 0 байт. Другими словами, он не содержит данных. Если вы откроете файл my_file.txt в текстовом редакторе, он будет пустым.

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

Что в имени?

Возможно, вы заметили, что все файлы Нелле называются "что-то точка-что-то", и в этой части урока мы всегда использовали расширение .txt . Это всего лишь соглашение: мы можем назвать файл mythesis или почти что угодно. Тем не менее, большинство людей большую часть времени используют имена, состоящие из двух частей, чтобы помочь им (и их программам) различать разные типы файлов. Вторая часть такого имени называется расширением имени файла и указывает, какой тип данных содержит файл: .txt указывает на обычный текстовый файл, .pdf указывает на PDF-документ, .cfg — это файл конфигурации, полный параметров для какой-либо программы или другое, .jpg — изображение в формате PNG и т. д.

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

Именование PNG-изображения кита поскольку whit.mp3 каким-то волшебным образом не превращает его в запись песни кита, хотя может заставить операционную систему попытаться открыть его с помощью музыкального проигрывателя, когда кто-то дважды щелкнет по нему.

Перемещение файлов и каталогов

Возвращаясь к каталогу shell-lesson-data/writing,

В нашем каталоге тезисов у нас есть файл draft.txt с не слишком информативным именем, поэтому давайте изменим имя файла с помощью mv , что является сокращением от «move»:

Первый аргумент сообщает mv, что мы «перемещаем», а второй — куда это должно двигаться. В данном случае мы перемещаем тезис/черновик.txt в thesis/quotes.txt, что имеет тот же эффект, что и переименование файла. Действительно, ls показывает нам, что тезис теперь содержит один файл с именем quotes.txt:

Нужно быть осторожным при указании имени целевого файла, так как mv молча перезапишет любой существующий файл с таким же именем, что может привести к потере данных. Дополнительный параметр mv -i (или mv --interactive ) можно использовать, чтобы заставить mv запрашивать подтверждение перед перезаписью.

Обратите внимание, что mv также работает с каталогами.

Давайте переместим файл quotes.txt в текущий рабочий каталог. Мы снова используем mv, но на этот раз мы будем использовать только имя каталога в качестве второго аргумента, чтобы сообщить mv, что мы хотим сохранить имя файла, но поместим файл в новое место. (Вот почему команда называется «переместить».) В этом случае имя каталога, которое мы используем, является специальным именем каталога. о которых мы упоминали ранее.

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

Кроме того, мы можем подтвердить, что файл quotes.txt больше не присутствует в каталоге тезисов, явно попытавшись указать его в списке:

ls с именем файла или каталога в качестве аргумента выводит только запрошенный файл или каталог. Если файл, указанный в качестве аргумента, не существует, оболочка возвращает ошибку, как мы видели выше. Мы можем использовать это, чтобы увидеть, что файл quotes.txt теперь присутствует в нашем текущем каталоге:

Перемещение файлов в новую папку

После выполнения следующих команд Джейми понимает, что поместила файлы sucrose.dat и maltose.dat не в ту папку. Файлы должны были быть помещены в папку raw.

Заполните пробелы, чтобы переместить эти файлы в папку raw/ (то есть в ту, куда она забыла их положить)

Решение

Напоминаем, что .. относится к родительскому каталогу (т. е. каталогу выше текущего), а . относится к текущему каталогу.

Копирование файлов и каталогов

Команда cp очень похожа на mv, за исключением того, что она копирует файл, а не перемещает его. Мы можем проверить, правильно ли он поступил, используя ls с двумя путями в качестве аргументов — как и большинство команд Unix, ls можно указать сразу несколько путей:

Мы также можем скопировать каталог и все его содержимое, используя рекурсивную опцию -r , например для резервного копирования каталога:

Мы можем проверить результат, перечислив содержимое папки thesis и thesis_backup:

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

  1. cp statstics.txt Statistics.txt
  2. mv statstics.txt stats.txt
  3. mv statstics.txt .
  4. cp statstics.txt.

Решение

  1. Нет. Хотя при этом будет создан файл с правильным именем, файл с неправильным именем все еще существует в каталоге, и его необходимо удалить.
  2. Да, переименовать файл можно.
  3. Нет, точка (.) указывает, куда переместить файл, но не дает нового имени файла; одинаковые имена файлов не могут быть созданы.
  4. Нет, точка (.) указывает, куда копировать файл, но не дает нового имени файла; одинаковые имена файлов не могут быть созданы.

Перемещение и копирование

Что выводит закрывающая команда ls в показанной ниже последовательности?

  1. белки-сохраненные.dat рекомбинированы
  2. воссоединено
  3. белки.dat рекомбинированы
  4. proteins-saved.dat

Решение

  1. Нет, см. объяснение выше. .profiles-saved.dat находится в папке /Users/jamie
  2. Да
  3. Нет, см. объяснение выше. .projects.dat находится в папке /Users/jamie/data/recombined
  4. Нет, см. объяснение выше. .profiles-saved.dat находится в папке /Users/jamie

Удаление файлов и каталогов

Возвращаясь к каталогу shell-lesson-data/writing, давайте наведем порядок в этом каталоге, удалив созданный нами файл quotes.txt. Для этого мы будем использовать команду Unix — rm (сокращение от «удалить»):

Мы можем подтвердить, что файл исчез, используя ls :

Удаление навсегда

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

Безопасное использование rm

Что происходит, когда мы выполняем команду rm -i thesis_backup/quotations.txt? Зачем нам нужна эта защита при использовании rm ?

Решение

Опция -i будет запрашивать перед (каждым) удалением (используйте Y, чтобы подтвердить удаление, или N, чтобы сохранить файл). Оболочка Unix не имеет корзины для мусора, поэтому все удаленные файлы исчезнут навсегда. С помощью параметра -i у нас есть возможность убедиться, что мы удаляем только те файлы, которые хотим удалить.

Если мы попытаемся удалить каталог тезисов с помощью rm thesis , мы получим сообщение об ошибке:

Это происходит потому, что rm по умолчанию работает только с файлами, а не с каталогами.

rm может удалить каталог и все его содержимое, если мы используем рекурсивную опцию -r , и он сделает это без каких-либо запросов на подтверждение:

Учитывая, что нет возможности восстановить файлы, удаленные с помощью оболочки, rm -r следует использовать с большой осторожностью (можно рассмотреть возможность добавления интерактивной опции rm -r -i ).

Операции с несколькими файлами и каталогами

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

Копировать с несколькими именами файлов

В этом упражнении вы можете протестировать команды в каталоге shell-lesson-data/exercise-data.

В приведенном ниже примере что делает cp, если задано несколько имен файлов и имя каталога?

В приведенном ниже примере что делает cp, если задано три или более имен файлов?

Решение

Если задано более одного имени файла, за которым следует имя каталога (т. е. каталог назначения должен быть последним аргументом), cp копирует файлы в указанный каталог.

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

Использование подстановочных знаков для одновременного доступа к нескольким файлам

Подстановочные знаки

* — это подстановочный знак, который соответствует нулю или более символов. Давайте рассмотрим каталог shell-lesson-data/exercise-data/proteins: *.pdb соответствует ethan.pdb, propane.pdb и каждому файлу, оканчивающемуся на «.pdb». С другой стороны, p*.pdb соответствует только pentane.pdb и propane.pdb , потому что «p» в начале соответствует только именам файлов, начинающимся с буквы «p».

? также является подстановочным знаком, но соответствует только одному символу. Таким образом, ?ethan.pdb будет соответствовать метану.pdb, тогда как *ethan.pdb соответствует и ethan.pdb , и метану.pdb .

Подстановочные знаки можно использовать в сочетании друг с другом, например. . ane.pdb соответствует трем символам, за которыми следует ane.pdb , что дает cubane.pdb ethan.pdb octane.pdb .

Когда оболочка видит подстановочный знак, он расширяет подстановочный знак, чтобы создать список совпадающих имен файлов перед выполнением запрошенной команды. В качестве исключения, если выражение с подстановочным знаком не соответствует ни одному файлу, Bash передаст выражение в качестве аргумента команде как есть. Например, ввод ls *.pdf в каталоге белков (который содержит только файлы с именами, заканчивающимися на .pdb ) приводит к сообщению об ошибке, что файл с именем *.pdf отсутствует. Однако обычно такие команды, как wc и ls, видят списки имен файлов, соответствующих этим выражениям, но не сами подстановочные знаки. Именно оболочка, а не другие программы, занимается раскрытием подстановочных знаков.

Список имен файлов, соответствующих шаблону

  1. ls *t*ane.pdb
  2. ls *t?ne.*
  3. ls *t??ne.pdb
  4. этан.*

Решение

Решение 3.

1. показывает все файлы, имена которых содержат ноль или более символов (*), за которыми следует буква t, затем ноль или более символов (*), за которыми следует ane.pdb. Это дает этан.pdb метан.pdb октан.pdb пентан.pdb .

2. показывает все файлы, имена которых начинаются с нуля или более символов ( * ), за которыми следует буква t , затем один символ ( ? ), затем ne. за которым следует ноль или более символов ( * ). Это даст нам octane.pdb и pentane.pdb, но не соответствует ничему, что заканчивается на thane.pdb.

3. устраняет проблемы варианта 2, сопоставляя два символа ( ?? ) между t и ne . Это решение.

4. показывает только файлы, начинающиеся с этана. .

Подробнее о подстановочных знаках

У Сэма есть каталог, содержащий данные калибровки, наборы данных и описания наборов данных:

Прежде чем отправиться на очередную экскурсию, она хочет создать резервную копию своих данных и отправить несколько наборов данных своему коллеге Бобу. Для выполнения работы Сэм использует следующие команды:

Помогите Сэму, заполнив пустые поля.

Полученная структура каталогов должна выглядеть так

Принципиально ли необходимо хранить на диске информацию о незанятых секторах диска? Объясните почему.

Решение:
Нет. Эта информация может быть вычислена при запуске путем обхода дерева файловой системы. Однако это вопрос безопасности. Работа такой утилиты, как fsck, упрощается и становится более безопасной благодаря наличию такого списка.

Проблема 2:

<ПР>
  • Предположим, что размер сектора диска составляет 512 байт, и предположим, что любая вспомогательная индексная таблица занимает весь сектор. Каков максимальный размер файла в этой системе.
  • Есть ли какая-либо польза от включения первых 436 байт файла в индексный дескриптор?
  • <ПР>
  • Примечание. Прежде всего необходимо определить размер индекса (2 или 4 байта).Учитывая, что у нас есть 3-уровневая схема индексации, вы можете быстро вычислить количество секторов, которые вы можете получить с помощью 2-байтового индекса и 4-байтового индекса. Вы увидите, что 2-байтовая индексация не работает. Это даст вам до 256 индексов на сектор с максимальным размером файла 436 + 13 * 512 + 1 * 256 * 512 + 1 * 256 * 256 * 512 + 1 * 256 * 256 * 256 * 512 = сколько угодно. Проблема с этим анализом заключается в том, что для работы этой схемы у вас гораздо больше секторов диска, чем можно закодировать в 2 байта. Вы можете использовать 3 байта, но это может стать некрасивым. Итак, мы используем 4-байтовые индексы, что дает нам 128 индексов на сектор, и правильный ответ: 436 + 13 * 512 + 1 * 128 * 512 + 1 * 128 * 128 * 512 + 1 * 128 * 128 * 128 * 512 = 1082203060, примерно 1 ГБ.
  • Да. Большинство файлов маленькие. Если размер файла составляет 436 байт или меньше, то весь файл можно прочитать и записать за одну дисковую операцию без необходимости отдельного доступа к индексному узлу.
  • Проблема 3:

    Решение:
    Нет, мы не можем. Причина в том, что пространство имен в DOS сливается со структурами файловых данных, в отличие от UNIX, где пространство имен находится в структуре каталогов, которая отделена от структур файловых данных (inode). Дополнительные сведения см. в примечаниях к лекциям.

    Проблема 4:

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

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

    Проблема 5:

    Вы разрабатываете файловую систему с нуля. Драйвер диска позволяет полностью контролировать размещение данных на диске. Предполагая, что вы остановились на архитектуре таблицы размещения файлов (FAT), где будет лучше всего хранить таблицу на диске?

    Решение:
    Лучшим местом будет средняя дорожка на диске. Причина в том, что в соответствии с политикой планирования лифта средняя дорожка будет посещена головкой диска дважды за один круговой путь, причем время между двумя посещениями будет максимальным для любой дорожки. Это наиболее желательное условие для трека, который будет активно использоваться.

    Проблема 6:

    Pooh Software Ltd. продает файловую систему, в которой используется UNIX-подобная файловая система с многоуровневой индексацией. Для большей надежности массив inode фактически реплицируется на диск в двух разных местах. Цель состоит в том, что если один или группа секторов, в которых хранится какая-либо реплика массива, станут неисправными, система всегда сможет восстановиться из реплики. Обсудите влияние этой реплицированной структуры данных на производительность.

    Решение:
    Обновления индексных дескрипторов необходимо выполнить для обеих копий. Это снизит производительность операций, пытающихся изменить индексные дескрипторы, таких как выделение нового файла, удаление файла, увеличение размера файла или открытие файла для обновлений (среди, возможно, многих других). Однако чтение информации из индексного дескриптора можно ускорить с помощью продуманного планирования дисков. Чтобы прочитать определенный inode, мы планируем чтение из любой дорожки, ближайшей к текущей позиции заголовка.

    Проблема 7:

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

    Решение:
    Использование 16-разрядных чисел для выражения кластеров позволяет использовать только до 32 КБ кластеров на диск (поскольку для обозначения конца файла и конца таблицы необходимы отрицательные числа). Для большого диска размер кластера, который является единицей размещения файлов, должен стать чрезмерно большим (например, размер кластера должен составлять 64 КБ в разделе диска размером 2 ГБ). Это приводит к огромной внутренней фрагментации файлов. Кроме того, он ограничивает размер раздела диска с использованием FAT только 2 ГБ.
    Чтобы снять эти ограничения, мы используем 32-битные числа для выражения кластеров. Тем не менее, нужно быть осторожным, потому что такое расположение потенциально допускает до 2G записей в таблице FAT, каждая из которых состоит из 4 байтов! Поэтому нам нужно где-то на диске хранить фактический размер таблицы FAT и использовать только минимальное количество записей, которое позволило бы таблице FAT использовать 32-битные числа для желаемого размера кластера. Например, диск объемом 4 ГБ можно разделить на 8 млн кластеров по 512 байт каждый.Требуемый размер таблицы должен составлять 32 МБ, или менее 1 % от размера диска.

    Проблема 8:

    Непрерывное размещение файлов приводит к фрагментации диска. Это внутренняя или внешняя фрагментация?

    Решение:
    И то, и другое! Файл по-прежнему размещается в единицах дискового блока, что означает, что последний блок в файле будет наполовину пустым (внутренняя фрагментация). Кроме того, непрерывное размещение приводит к внешней фрагментации, поскольку между файлами может быть много небольших нераспределенных фрагментов, которые нельзя использовать для размещения файла, размер которого больше размера любого фрагмента, но меньше общего размера файла. свободное место.

    Проблема 9:

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

    Проблема 10:

    <ПР>
  • Что обычно хранится в индексном узле помимо индексов?
  • В чем недостаток хранения имени файла в индексном узле? Где должно храниться имя файла?
  • Если размер сектора диска составляет 512 байт, каков максимальный размер файла в этой схеме размещения?
  • Предположим, мы хотим улучшить файловую систему, поддерживая управление версиями. То есть при обновлении файла система создает новую версию, оставляя предыдущую нетронутой. Как бы вы изменили схему распределения инодов для поддержки управления версиями? В ответе следует учитывать, как создается и удаляется новая версия.
  • В файловой системе, поддерживающей управление версиями, следует ли размещать информацию о номере версии в индексном узле или в дереве каталогов? Обоснуйте свой ответ.
  • <ПР>
  • Инод обычно хранит индексы и:
    • размер файла в байтах,
    • специальные флаги, указывающие, относится ли файл к особому типу (каталог, символические ссылки)
    • отметки времени (дата создания, дата изменения, дата последнего чтения),
    • количество ссылок на этот файл из пространства имен,
    • идентификация владельца (например, в UNIX, идентификатор пользователя и идентификатор группы) и
    • учетные данные безопасности (кто должен иметь возможность читать файл)
  • Сохранение имени файла в индексном узле ограничивает гибкость файловой системы и исключает использование жестких ссылок. Кроме того, поскольку желательно иметь относительно длинные имена файлов, было бы обременительно хранить массивы символов переменного размера в структуре inode (или расточительно, если определен определенный максимум).
  • Сначала необходимо определить размер индекса. Для 2-байтового индекса у нас может быть 65536 дисковых блоков, т.е. 512 * 65536 = 32 МБ. Но структура тройного индекса может выражать больше дисковых блоков. Поэтому мы переходим на 4-байтовую схему индексации (3-байтная схема индексации не привлекательна и недостаточна). Таким образом, 4-байтная схема индексации дает максимальный размер файла 7 * 512 + 128 * 512 + 128 * 128 * 512 + 128 * 128 * 128 * 512 = 1 082 19952 или около 1 ГБ.
  • Мы расширяем структуру inode таким образом, чтобы разные версии файла использовали общие блоки. Когда создается новая версия, мы копируем информацию из старой версии в новую. Кроме того, нам нужно будет добавить счетчик ссылок к каждому блоку диска и установить для этого счетчика ссылок значение 1, когда блок выделяется для одного файла. Счетчик ссылок увеличивается каждый раз, когда блок совместно используется разными версиями. Затем, когда версия изменяется, мы применяем политику, подобную копированию при записи, и уменьшаем счетчик ссылок дисковых блоков и фактически копируем измененные дисковые блоки и делаем их доступными только для новой версии.
  • Лучше поместить его в пространство каталогов, чтобы пользователю было проще связать разные версии одного и того же файла.
  • Проблема 11:

    <ПР>
  • Что произойдет, если система резервного копирования перейдет по символическим ссылкам и сохранит файлы, на которые указывает ссылка?
  • Выявите проблемы с этой схемой резервного копирования.
  • Вместо описанного выше система резервного копирования KeyStone требует, чтобы файловая система поддерживала битовую карту для каждого сектора на диске. Если сектор диска обновляется, файловая система устанавливает соответствующий бит в единицу. Когда система KeyStone выполняет инкрементное резервное копирование, она сохраняет только те сектора диска, биты которых установлены, а затем сбрасывает всю битовую карту. Сравните две схемы резервного копирования. Каковы общие проблемы между ними? Каковы ключевые преимущества каждого из них? Какой из них вы бы использовали?
  • <ПР>
  • Это было бы досадно, потому что если файл будет восстановлен из резервной копии, он больше не будет символической ссылкой. Вместо этого это будет файл, на который во время резервного копирования указывает ссылка, что семантически неверно.Для корректной работы система резервного копирования должна восстановить символическую ссылку.
  • Для больших файлов достаточно изменить один байт, чтобы система резервного копирования сохранила весь файл. То есть, система резервного копирования не слишком умна, пытаясь уменьшить объем памяти, который необходимо сохранить (она сохраняет весь файл, если он был изменен, а не просто сохраняет разницу между старым и новым файлом). Однако это не является серьезной проблемой.
  • Основное различие между двумя системами резервного копирования заключается в том, что KeyStone работает на уровне плоской файловой системы, а система LoneStar работает на уровне пространства имен. KeyStone может выглядеть умнее, поскольку он не будет сохранять немодифицированные блоки диска, но у него есть несколько серьезных проблем. Во-первых, требуется, чтобы файловая система манипулировала растровым изображением, что серьезно увеличивает повседневную работу. Во-вторых, поскольку он работает на уровне плоской файловой системы, возникает проблема, когда отдельные файлы должны быть восстановлены в другой файловой системе. В-третьих, он по-прежнему может сохранять блоки диска, которые были изменены, но в настоящее время находятся в свободном списке (если они были изменены, а затем освобождены).
  • Проблема 12:

    Объясните, что происходит с диском в UNIX, когда пользователь в текстовом редакторе сохраняет новый файл с именем "foo" в текущем каталоге. Предположим, что длина foo составляет 15678 байт, размер дискового блока составляет 1024 байта, что файловая система поддерживает до 2^32 секторов и что индексный дескриптор содержит 10 прямых указателей на блоки, 1 косвенный указатель на блок, 1 дважды косвенный указатель на блок. и 1 тройной косвенный указатель блока. Система использует свободные карты на диске для отслеживания свободных блоков и свободных инодов. Вот набор действий, которые, как вы можете предположить, выполняет редактор:

    fd = open(foo, O_CREAT|O_WRONLY);
    p = &editBuffer;
    numBlocks = editBufferSize / 1024;
    for (i = 0; i Решение:

    // fd = open(foo, O_CREAT|O_WRONLY) -- это создает файл
    // предположим, что индекс N изначально свободен и выделен для этого файла
    записать карту свободных индексов (отметить запись N как «используемый» для выделения индекса)
    записать индекс N (все указатели равны «NULL» -- файл нулевой длины)
    записать блок файла для каталога, содержащего «foo», добавив запись «foo - > N" (предположим, что это не увеличивает количество блоков в этом каталоге)

    // 16 вызовов write() не приводят к обращению к диску

    // закрываем
    записываем обновления в карту свободных блоков для выделения 17 блоков -- 16 блоков данных + 1 косвенный блок
    инод записи, содержащий указатель на 10 блоков данных и косвенный блок, и маркировка длины файла как 15678 байт
    запись косвенного блока, содержащего указатель на 6 блоков данных
    />записать 16 блоков данных

    Решение:
    В этой ситуации индексный дескриптор указывает на непрямой блок, содержащий мусор. Это означает, что он может содержать указатели на блоки, выделенные другим файлам (и другим пользователям). Пользователь сможет прочитать до 6 блоков других пользователей (чтение последних 6 блоков файла будет следовать этим фиктивным указателям). Другие пользователи также могут читать данные этого пользователя (будущие записи этого пользователя в эти блоки будут следовать этим неверные указатели и помещает данные в файлы других пользователей; теперь эти данные могут быть прочитаны другими пользователями.)

    Проблема 13:

    1. Инженер разработал систему, подобную FAT, и использовал 24 бита для каждой записи. Для 32-гигабайтного диска, каков минимальный размер выделяемого файла в этой системе? Обосновать ответ.
      Решение:
      Диск объемом 32 ГБ имеет 2^35 байт памяти; если каждая запись в FAT имеет 24 бита, то может быть не более 2 ^ 24 фрагментов распределения (по одному на запись FAT), поэтому каждый фрагмент распределения должен иметь размер 2 ^ 11 байт = 2 КБ

      Каков максимальный размер файла при таком расположении, если блок диска составляет 1024 байта? Объясните, как вы вычисляете этот максимальный размер.
      Решение:
      Непрямой блок имеет 1024 байта * 1 индекс/4 байта = 256 указателей. ^2) * 1024 байта.

    Проблема 14:

    Управление версиями: часто желательно, чтобы пользователи поддерживали разные версии одного и того же файла (например, во время разработки программы, для восстановления в случае неправильных обновлений, примененных к версии, и т. д.). Файловая система VMS реализует управление версиями, создавая новую копию файла каждый раз, когда он открывается для записи. Система также поддерживала управление версиями в структуре именования, добавляя номер версии к имени каждого файла. Например, при обновлении foo.c;1 система создает foo.c;2 и т. д. В системе реализованы команды для управления версиями, например, команда PURGE удалит все версии, кроме самой последней. Кроме того, пользователи могут отключить управление версиями для некоторых файлов. Обсудите плюсы и минусы этой схемы.

    Решение:
    Основным преимуществом этой схемы является ее простота. На самом деле нет принципиально необходимой поддержки со стороны операционной системы. Вместо этого прикладные программы и оболочка могут быть связаны с модифицированной библиотекой, которая создает новую версию всякий раз, когда файл открывается для обновления. Создание файла может быть выполнено с помощью доступных системных вызовов. Например, в UNIX-подобной системе это может быть реализовано за счет того, что библиотечная заглушка open() фактически вызывает creat() с новым именем, затем выполняет копирование, а затем открывает только что созданный файл.

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

    Проблема 15:

    Реализация программы FSCK просматривает дерево файловой системы и строит два списка дисковых блоков. Один список содержит секторы, которые показаны как используемые, а другой считывает информацию о свободных дисковых блоках на диске. Если бы два списка для 4 блоков были такими, как показано:

    Используется 0 1< /TD> 0 1
    Бесплатно 0 0 1 1

    Определите проблемы, если таковые имеются, и что должна делать fsck для каждого блока.

    Решение:
    Комбинация (0, 0) является проблемой, поскольку она показывает, что блок диска не принадлежит ни одному файлу, и при этом он не находится в списке свободных. Fsck должен пометить блок как используемый и попытаться найти, где он должен принадлежать. В случае сбоя он должен создать восстановленный файл в каталоге Lost+Found и включить туда этот блок.

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

    Читайте также: