Управление файловой системой

Sparse files

Начну с маленького примера вдогону к перыдущему рассказу.

Мы выяснили, что в файловой системе, как правило, есть некоторая верхушка файла (inode), и ссылки на блоки, в которых лежит тело файла. В зависимости от тонкостей того, как устроены эти ссылки (а они могут быть устроены очень по-разному в разных файловых системах), может быть возможным добиться, например, такой ситуации: у нас есть файл размером в 200G, у которого есть 4 блока данных – от 0 до 4К, от 50 до 54K и от 90G до 90G+4K. Такая ситуация называется sparse file (разреженный файл).

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

Со sparse files вы наверняка встречались, если когда-нибудь качали торренты: именно так представляют недокачанные файлы программы.

Узнать, сколько файл реально занимает на диске, можно командой du.

du файл – узнать сумму размеров блоков, занимаемых файлом (обычно это больше, чем размер файла; в случае sparse files – наоборот). Результат выдаётся как количество блоков (что не очень удобно читать). Для директорий du распечатывает аналогично размер каждого в директории самого по себе и складывает их размер с размером директории.

du -h файл – выдавать размер файла в человекочитаемом виде.

du -s файл – для директории выдавать только суммарный итоговый размер.

du -sh файл – так обычно вызываю du я, чтобы не задумываться.²

Остальные варианты, что можно делать с du ищите в документации. (О которой я ещё расскажу довольно подробно).

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

Традиционно UNIX развивался в среде, где есть две чётко раздельные роли – администратора и пользователя. (Windows, его предшественник DOS и его предшественник CP/M рассчитывались на компьютер, работающий без администратора – и это приводило к несколько другим решениям в некоторых местах). Для пользователя в UNIX файловая система всегда выглядит как одно единое и довольно неизменное дерево.

Для администратора, как мы выяснили в прошлый раз, есть, например, понятие раздела. Именно администратор в UNIX должен знать о том, как называется какое устройство относится к какому жёсткому диску.

Напоминаю и дополняю. В Linux имена устройств такие:

• диски, подсоединённые через шлейф IDE – /dev/hda, /dev/hdb, ...

• диски, подсоединённые SCSI, SATA или USB – /dev/sda, /dev/sdb, ...

• для CD обычно автоматически создаётся ссылка в /dev/cdrom или /dev/dvd

• первичные разделы диска /dev/диск: /dev/диск1, /dev/диск2, /dev/диск3, /dev/диск4

• расширенные разделы: /dev/диск5, /dev/диск6, ...

• логические разделы (LVM): /dev/mapper/группа-имя

Итак, у нас есть разные наборы файлов разбросанные по нескольким разделам, а пользователь должен видеть всё как единое дерево директорий.

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

Положим, у нас в разделе /dev/sda1 есть файловая система, в которой есть дерево директорий:

 / +
   |- a +
   |    |- p
   |    |- q
   |- b
   |- c

И есть директория /dir:

/dir +
    |- x
    |- y

То мы можем подмонтировать устройство /dev/sda1 поверх /dir.

# ls /dir
x y
# mount /dev/sda1 /dir
# ls /dir
a b c
# ls /dir/a
p q

Прежнее содержимое /dir мы не можем увидеть то дех пор, пока не размонтируем /dev/sda1:

# umount /dev/sda1
# ls /dir
x y

При монтировании устройства мы можем указать кучу всяких параметров на тему того, как именно монтировать. Полный формат вызова команды mount выглядит примерно так: mount что куда -t тип_фс -o параметры, пара самых популярных примеров параметров:

# mount /dev/sda1 /dir -o ro
# ls /dir
a b c
# mkdir /dir/d
mkdir: cannot create directory `/dir/d': Read-only file system
# mount /dev/sda1 -o remount,rw
# mkdir /dir/d
# ls /dir
d

Первой строкой mount мы монтируем /dev/sda1, как и в прошлом примере, поверх /dir, но монтируем с параметром ro – read-only. Вторым вызовом mount мы меняем настройки уже подмонтированной файловой системы – об этом говорит параметр remount; параметр rw обозначает перемонтировать на чтение и записть (read-write).

Во всех примерах выше говорят, что директория /dir называется точкой монтирования. (Точка монтирования – та директория, в которую что-нибудь вмонтировано).

fstab

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

UNIX сам по себе автоматически не запоминает, что вы где подмонтировали, поэтому если вы что-то подмонтировали и перезагрузили компьютер, монтировать нужно заново.

Дабы это не делать руками, сделали таблицу, в которой описывается, какие файловые системы куда нужно монтировать во время загрузки. Таблица эта лежит в файле /etc/fstab и выглядит примерно так:

# This is fstab
/dev/sda1 /dir reiserfs defaults 0 2

Строгое определение формата этого файла такое: пустые строки и строки, начинающиеся с # игнорируются, в содержательных строках описываются настройки файловых систем – это несколько значений разделённых пробелами.

Поля файла такие:

1. что
2. куда

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

4. параметры – ровно то же, что после флага -o

5. здесь всегда должен быть 0. Это поле – пережиток прошлого. Когда-то давно резервные копии файлов делались утилитой под названием dump – и в этом поле указывалась частота копирования выбранной файловой системы. Сейчас большинство людей всё-таки делает бэкапы другими средствами. (dump поддерживают и развивают довольно вяло, файловых систем он поддерживает только семейство ext*, да и сам подход довольно спорный).

6. в каком порядке во время загрузки проверять файловую систему на консистентность. Здесь всё просто: для / всегда должна быть 1 и никак иначе, для всех остальных должна быть 2, если их перепроверять нужно или 0 если не нужно

Когда вы ставите любой относительно современный Linux, программа-инсталлятор сама создаст для вас довольно разумный /etc/fstab и редактировать его своими руками вам вряд ли придётся.

Псевдо файловые системы

Помните ли вы, что такое устройство (как тип файла)? Напомню, это такой файл, у которого нету тела, а вместо этого в нём написано, в какой части ядра реализованы функции read, write, ... – которые реализуют работу с этим файлом.

Довольно аналогичным образом, имя файловой системы указывает на то, где в ядре реализованы функции listdir, open, ...³

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

А раз всё сводится к тому, что с точки зрения ядра файловая система – это просто набор функций, то можно в качестве таких функций подсунуть что-нибудь, что отнюдь не будет реализовать способ организации данных на диске!

Примеров тому много. Приведу лишь несколько самых полезных / самых распространённых.

procfs – видимо, самая первая из псевдо файловых систем в UNIX. Она была реализована в 1984 году. Идея этой файловой системы состоит в том, чтобы показывать состояние ядра в виде набора директорий и файлов. /proc/число/ – это информация о процессе по его номеру (о процессах мы поговорим в следующий раз). /proc/meminfo – очень подробная таблица о том, какая область оперативной памяти сколько места занимает. /proc/filesystems – перечень файловых систем, о которых знает ядро. На самом деле, в этой файловой системе лежит очень много разной информации. И плюс к этому, в часть файлов на этой файловой системе можно писать данные – и таким образом настраивать ядро. Советую вам поглядеть, что есть в этой директории ближайший раз, как вы доберётесь до линукса. (Исключительно из интереса: сколько из того, что там есть, вы способны понять). Ещё одно полезное замечание: информация в этой файловой системе сделана так, чтобы с ней было удобно работать в первую очередь программам, а не людям; поэтому для людей тоже с древних времён существует довольно большая гора программ, которые вытаскивают информацию из этой файловой системы и выдают в более читаемом виде.

sysfs – примерно аналогичная файловая система, специфичная для линукса и очень молодая. В первую очередь она посвящена информации о всяких периферийных устройствах и возникла ради того, чтобы на лету уметь реагировать на втыкание-вытыкание разных частей компьютера. (Например, usb флэш-память). Рассказываю об этой файловой системе исключительно для полноты. Пример про неё: # echo disk > /sys/power/state отправляет компьютер в очень глубокое состояние сна (отправляет всё содержимое памяти на жёсткий диск и выключает компьютер совсем; иногда просыпание из этого сна даже возможно); никогда так не делайте.

nfs – network file system – название говорит за себя. Идея такая: на одном компьютере бегает несколько программ, которые раздают какие-нибудь директории по сети, на другом компьютере (если ему разрешено) можно подмонтировать какую-нибудь из этих директорий. Довольно подобно тому, как в Windows вы можете "расшарить" (share) директорию (на самом деле, NFS ровестник слову windows как названию программы – оба появились в 1985-м, – и потому сильно древнее возможности расшаривать директории в windows). В линуксе на компьютерах класса в fstab есть, например, такая строка:

kodomo:/home /home nfs defaults 0 0

• Обратите внимание, что в случае псевдо файловых систем мы уже не обязаны в

качестве устройства, на котором лежат данные, указывать устройство с точки зрения UNIX. В данном случае устройство kodomo:/home – это просто строка, которую драйвер nfs интерпретирует как адрес машины, с которой нужно соединяться и путь к директории, которую мы хотим подмонтировать. Об этой файловой системе я тоже рассказываю для полноты картины, а не для практики. С nfs всегда довольно много возни (в первую очередь, с раздающей стороны) и я не советую вам пытаться ей пользоваться.

tmpfs – файловая система для временных файлов. Идея такая: мы заводим кусочек оперативной памяти и складываем файлы туда. Зачем: чтобы с временными файлами работа была быстрее и для того, чтобы быть уверенными, что после перезагрузки они исчезнут. (Как ни странно, это свойство полезно даже в обиходе). Приятное свойство этой файловой системы в том, что она занимает в памяти столько места, сколько в ней реально используется. Я рекомендую вам, если вы вознамерились установить себе на компьютер линукс, добавить в /etc/fstab строчку примерно такого вида:

tmpfs /tmp tmpfs defaults 0 0

fuse – даже среди псевдо файловых систем это трудно назвать файловой системой. Авторы этой файловой системы размышляли вот о чём: во-первых, монтировать файловые системы может только администратор, а иногда и продвинутому пользователю⁴ хотелось бы иногда что-нибудь подмонтировать удобства ради; а во-вторых, лучше было бы, чтобы драйвер файловой системы был обычной пользовательской программой с ограниченными правами (это желание у них возникло хотя бы потому, что отлаживать части ядра существенно сложнее, чем пользовательские программы, и потому, что раз пользователь может что-то подмонтировать, то именно правами пользователя должны ограничиваться и возможности драйвера). Идея fuse такова: она запускает пользовательскую программу и перенаправляет обращения к функциям драйвера в обращения к частям этой программы. (Приблизительно).

sshfs – это самый полезный, на мой вкус, пример файловой системы, сделанной через fuse. Идея такая: мы запускаем ssh и превращаем все обращения к нашей файловой системе в команды ssh⁵. Таким образом, мы сильно задёшево (без какой-либо настройки на сервере и даже без ведома сервера) получаем возможность подмонтировать у себя часть директорий с чужой UNIX-машины. Настоятельно рекомендую вам освоить это средство. Пример:

$ mkdir tmp
$ sshfs kodomo.fbb.msu.ru:/home tmp
$ ls tmp
admin export old-pvm preps students
$ fusermount -u tmp
$ ls tmp
$

Вот вам два неприятных отличия fuse от остальных файловых систем: мы не можем монтировать и размонтировать его командой mount и umount. Более того, монтировать файловые системы fuse как правило нужно отдельной программой, которая поставляется с каждой из таких файловых систем, а размонтировать командой fusermount -u. В остальном команды монтирования fuse стараются вести себя примерно так же, как и mount.

В случае sshfs команда монтирования выглядит так:

sshfs логин@сервер:путь куда_монтировать

copyfs – это ещё один пример файловой системы, сделанной через fuse. Преследует ту же цель, что и репозитории: хранить прежние версии файлов. Только в отличии от обычных репозиториев, новая версия файла сохраняется автоматически при любом изменении – от вас вообще не требуется никаких действий, чтобы прежние версии сохранялись. Должен признаться, что ни разу не пользовался этой файловой системой, возможно и зря.

encfs – ещё один пример файловой системы на fuse. Encryption filesystem – когда вы её монтируете, она спрашивает у вас пароль и шифрует все данные этим паролем. После того, как вы её отмонтировали, прочитать данные, которые вы записали, не имея пароля, невозможно. Как и с copyfs, этой файловой системой я не пользовался, и привожу её пример ради кургозора.

unionfs – это способ склеить две директории вместе. Мы имеем две директории с похожими данными (или одну полную директорию и одну пустую), и ... получаем директорию, которая выглядит как Очень часто используется на "live CD" – дистрибутивах, которые работают прямо с компакт-диска. Поступают так: на CD запихивают полностью всю иерархию директорий, как это нужно для того, чтобы система работала, после чего создают небольшу

FIXME

pmount

FIXME

FHS

FIXME: /, /bin, /boot, /dev, /etc, /etc/X11, /home, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /srv, /tmp, /usr, /var

• /usr: bin, include, lib, sbin, share, src, X11R6, local

• /var: lib, lock, log, mail, run, spool, tmp

Пользователи в UNIX

FIXME

• login, password, ... => /etc/passwd

  • name:passwd:uid:gid:gecos:home:shell
  • gecos = General Electric Comprehensive Operating Supervisor
• /etc/passwd vs. /etc/shadow
  • name:passwd:lastch:minage:maxage:warntime:grace:exp_date:RFU
• gid, /etc/group
  • name:passwd:gid:members
• root
• информация о пользователе: id, finger

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

FIXME

• биты
• chmod, chgrp, chown