Хотелось бы хоть немного разобраться с файловой системой Linux.
В каких папках чего лежит, для чего эти папки нужны, какие форматы файлов бывают и тд.
мОжет кто кинет ссылочку на файлик на русском? или объяснит чтосам знает?
Файловая система Linux
Файловая система Linux
zaurus SL 760
Для начала два замечания: "файловой системой" принято называть несколько иную вещь - структура директорий и мифические расширения файлов к ней отношения не имеют.
Во вторых, слово "папка" действует на старых опытных юниксоидов как красная тряпка на быка. Правильный термин "директория" или "каталог".
Традиционно структура дерева директорий Юникс достаточно нелогична и запутана. Каких-то раз и навсегда определенных мест для размещения файлов не существует - не только разные дистрибутивы Линукса хранят одинаковые файлы в разных местах, но даже разные версии одного и того же приложения могут пытаться распихать свои файлы по разным директориям.
Поэтому имеет смысл говорить только об общем принципе, который ("закон - что дышло") может быть применен по разному.
Итак:
/bin - здесь хранятся только исполняемые файлы. При этом теоретически здесь должны располагаться только программы более или менее одинаковые для всех систем с данным дистрибутивом. То есть, предполагается, что пользователь самостоятельно не будет добавлять сюда программы. В то же время утилиты, предназначенные для администрирования системы не должны располагаться в этом каталоге.
/boot - как легко понять из названия, здесь обычно располагается само ядро, файл System.map - карта символов ядра и все остальное, что имеет отношение к процедуре загрузки, кроме модулей (initrd, файлы конфигурации grub, если импользуется этот загрузчик и т.д.). В этой директории во время загрузки могут создаваться некоторые вспомогательные файлы, такие как kernel.h. Раньше образ ядра зачастую хранился в корневой директории, но все основные современные дистрибутивы давно уже перешли на использование /boot.
/dev - директория предназначенная для хранения файлов устройств. Основная метафора Юникс - "все, что угодно, есть файл". На самом деле эта метафора (как всегда) не выдерживается до конца последовательно - существует три типа устройств: символьные, блочные и сетевые. Однако только символьные и блочные устройства имеют соответствующие им файлы. Никакого файла, соответствующего, скажем, eth0 не существует в принципе. Правда могут существовать файлы соответствующие символьным или блочным устройствам обеспечивающим доступ к сетевым ресурсам (то есть после установления, скажем, ppp соединения может появиться новое символьное устройство, которое не было доступно до того).
С точки зрения ядра Юникс имена, которые мы даем устройствам никакого смысла не имеют. Ядро различает устройства не по именам, а по номерам. Каждое устройство имеет два номера: старший и младший. "ls -l /dev" позволяет посмотреть эти номера. mknod позмоляет создать новый файл устройства. Неважно какое у него будет имя - если оно будет иметь тот же тип, что и уже существующее и те же оба номера, ядро окажется не в состоянии отличить обращение к новому файлу устройства от обращения к старому. При этом все просто договорились использовать для размещения этих файлов директорию /dev. С равным успехом их можно создавать в любой другой директории. Правда, существуют псевдо файловые системы, которые обеспечивают автоматическое создание и уничтожение файлов устройств. В Линукс это devfs (устаревшая) и udev. Они традиционно монтируются на /dev.
Смысл старших и младших номеров исходно был предельно ясен и прост: существовала талица драйверов устройств и старший номер выбирал драйвер из этой таблицы. То есть, запросы на все устройства с одинаковым старшим номером направлялись одному и тому же драйверу. Каждый драйвер, в свою очередь поддерживал таблицу устройств и по младшему номеру выбирал конкретноен устройство из этой таблицы. Со временем, по мере усложнения операционной системы эта простота, к сожалению, исчезла...
(Надоело мне это писать, если sil'у будет интересно - потом продолжу, если вопрос был о чем-то другом - нужно уточнить).
Во вторых, слово "папка" действует на старых опытных юниксоидов как красная тряпка на быка. Правильный термин "директория" или "каталог".
Традиционно структура дерева директорий Юникс достаточно нелогична и запутана. Каких-то раз и навсегда определенных мест для размещения файлов не существует - не только разные дистрибутивы Линукса хранят одинаковые файлы в разных местах, но даже разные версии одного и того же приложения могут пытаться распихать свои файлы по разным директориям.
Поэтому имеет смысл говорить только об общем принципе, который ("закон - что дышло") может быть применен по разному.
Итак:
/bin - здесь хранятся только исполняемые файлы. При этом теоретически здесь должны располагаться только программы более или менее одинаковые для всех систем с данным дистрибутивом. То есть, предполагается, что пользователь самостоятельно не будет добавлять сюда программы. В то же время утилиты, предназначенные для администрирования системы не должны располагаться в этом каталоге.
/boot - как легко понять из названия, здесь обычно располагается само ядро, файл System.map - карта символов ядра и все остальное, что имеет отношение к процедуре загрузки, кроме модулей (initrd, файлы конфигурации grub, если импользуется этот загрузчик и т.д.). В этой директории во время загрузки могут создаваться некоторые вспомогательные файлы, такие как kernel.h. Раньше образ ядра зачастую хранился в корневой директории, но все основные современные дистрибутивы давно уже перешли на использование /boot.
/dev - директория предназначенная для хранения файлов устройств. Основная метафора Юникс - "все, что угодно, есть файл". На самом деле эта метафора (как всегда) не выдерживается до конца последовательно - существует три типа устройств: символьные, блочные и сетевые. Однако только символьные и блочные устройства имеют соответствующие им файлы. Никакого файла, соответствующего, скажем, eth0 не существует в принципе. Правда могут существовать файлы соответствующие символьным или блочным устройствам обеспечивающим доступ к сетевым ресурсам (то есть после установления, скажем, ppp соединения может появиться новое символьное устройство, которое не было доступно до того).
С точки зрения ядра Юникс имена, которые мы даем устройствам никакого смысла не имеют. Ядро различает устройства не по именам, а по номерам. Каждое устройство имеет два номера: старший и младший. "ls -l /dev" позволяет посмотреть эти номера. mknod позмоляет создать новый файл устройства. Неважно какое у него будет имя - если оно будет иметь тот же тип, что и уже существующее и те же оба номера, ядро окажется не в состоянии отличить обращение к новому файлу устройства от обращения к старому. При этом все просто договорились использовать для размещения этих файлов директорию /dev. С равным успехом их можно создавать в любой другой директории. Правда, существуют псевдо файловые системы, которые обеспечивают автоматическое создание и уничтожение файлов устройств. В Линукс это devfs (устаревшая) и udev. Они традиционно монтируются на /dev.
Смысл старших и младших номеров исходно был предельно ясен и прост: существовала талица драйверов устройств и старший номер выбирал драйвер из этой таблицы. То есть, запросы на все устройства с одинаковым старшим номером направлялись одному и тому же драйверу. Каждый драйвер, в свою очередь поддерживал таблицу устройств и по младшему номеру выбирал конкретноен устройство из этой таблицы. Со временем, по мере усложнения операционной системы эта простота, к сожалению, исчезла...
(Надоело мне это писать, если sil'у будет интересно - потом продолжу, если вопрос был о чем-то другом - нужно уточнить).
!!!!!!
ВадимП, спасибо. Тронут до слез, прада 
Информация полезная и не мне одному я думаю нужная , так что смело её в FAQ!.
Это именно то что я просил. Если будут еще силы - дополните.
Вопрос по теме но конкретный.
Я как то случайно нарбрел, убей бог не помню какой это был каталог, но там были конфигураионные фалы системы (Ваша любимая X11
)
я поменял на больший, шрифт в окне настройки яркости, Qpakadger, еще каких то встроенных приложениях (они были в той же папке ) . А теперь не могу найти где. Все обыскал. Снится скоро он мне будет этот каталог...!
Где искать не подскажете?
Информация полезная и не мне одному я думаю нужная , так что смело её в FAQ!.
Это именно то что я просил. Если будут еще силы - дополните.
Вопрос по теме но конкретный.
Я как то случайно нарбрел, убей бог не помню какой это был каталог, но там были конфигураионные фалы системы (Ваша любимая X11
) я поменял на больший, шрифт в окне настройки яркости, Qpakadger, еще каких то встроенных приложениях (они были в той же папке ) . А теперь не могу найти где. Все обыскал. Снится скоро он мне будет этот каталог...!
Где искать не подскажете?
zaurus SL 760
некоторые, наиболее общие файлы настройки обычно находятся в /etc/X11.
Найти другие может быть намного более сложно (это может быть какой-нибудь /usr/X11R6/lib/X11/etc...)
В целом надо смотреть (правда я не совсем понял, что именно) где-то или в /usr/{.|local|share}/X11R6/etc/X11
или в
/usr/{.|local|share}/X11R6/lib
(поскольку сама /usr закрыта на запись, то вместо /usr/X11R6 могла быть использована или /usr/local/X11R6 или /usr/share/X11R6 - не знаю, что сделал sash.
Найти другие может быть намного более сложно (это может быть какой-нибудь /usr/X11R6/lib/X11/etc...)
В целом надо смотреть (правда я не совсем понял, что именно) где-то или в /usr/{.|local|share}/X11R6/etc/X11
или в
/usr/{.|local|share}/X11R6/lib
(поскольку сама /usr закрыта на запись, то вместо /usr/X11R6 могла быть использована или /usr/local/X11R6 или /usr/share/X11R6 - не знаю, что сделал sash.
/etc - директория "et cetera", которая давным-давно уже потеряла свое исходное предназначение - служить местом для хранения всего, что не вошло ни в одну другую директорию. Сейчас она используется в основном для двух вещей: хранения файлов конфигурации наиболее важных приложений и стартовых сценариев (терминологический вопрос: не пишу "самой системы", потому что непонятно что есть "сама система"? Ближе всего к понятию "файл конфигурации самой системы" файл /etc/inittab, который вполне корректно рассматривать как файл важного системного приложения /sbin/init).
Файлы в самой директории в подавляющем большинстве не исполняемые. Даже сценарии оболочки вроде bashrc или profile. Нет смысла делать их исполняемыми, поскольку они всегда вызываются из текущего интерпретатора (". bashrc") - в противном случае они окажутся не в состоянии выполнить свое предназначение (установить переменные окружения).
Лирическое отступление:
В Unix не существует способа передать переменные окружения от потомка родителю. Поэтому, если потомок (например, mc) меняет директорию, после выхода из него восстанавливается первоначальная директория. Чтобы текущая директория сохранялась после выхода из программы используется примитивный трюк:в каком-то из сценариев выполняемом при запуске начальной оболочки (я предпочитаю, как это сделано в Red Hat, для этой цели создать директорию /etc/profile.d) определяется функция с именем mc. Когда Вы вызываете midnight commander фактически вызывается эта фунция, которая вызывает mc с ключом "-P". При этом mc, завершая работу записывает текущий каталог в файл, указаный после этого ключа. Функция читает этот файл и выполняет cd `cat file`. То есть выполняет переход в ту директорию из которой вышел mc. Поскольку функия выполняется в той же оболочке, после выхода из фунции новая директория сохраняется и для пользователя все выглядит так, как будто он изменил директорию в mc, вышел и остался в новой директории.
Правда, существуют и исключения. Некоторые файлы создаются как исполняемые (например, /etc/bash_completion), но это право доступа для них никогда не является принципиально важным.
Стартовые файлы (которые традиционно находятся во всех дистрибутивах в /etc/rc.d/), напротив, не только являются исполняемыми, но и существенно зависят от этого атрибута. В некоторых случаях, для ускорения начальной загрузки (ненамного) они запускаются не последовательно, а одновременно, что, как легко понять, требует порождения для каждого файла отдельного процесса.
Кроме того, в /etc могут создаваться субдиректории, которые, в большинстве, используюся каким-то единственным приложением или подсистемой. В таких директориях обычно бывают перемешаны сценарии и файлы конфигурации. В очень редких случаях там могут находиться символьные ссылки на исполняемые файлы (/etc/X11/X). Сами исполняемые файлы (программы, не сценарии) я не встречал никогда.
Файлы в самой директории в подавляющем большинстве не исполняемые. Даже сценарии оболочки вроде bashrc или profile. Нет смысла делать их исполняемыми, поскольку они всегда вызываются из текущего интерпретатора (". bashrc") - в противном случае они окажутся не в состоянии выполнить свое предназначение (установить переменные окружения).
Лирическое отступление:
В Unix не существует способа передать переменные окружения от потомка родителю. Поэтому, если потомок (например, mc) меняет директорию, после выхода из него восстанавливается первоначальная директория. Чтобы текущая директория сохранялась после выхода из программы используется примитивный трюк:в каком-то из сценариев выполняемом при запуске начальной оболочки (я предпочитаю, как это сделано в Red Hat, для этой цели создать директорию /etc/profile.d) определяется функция с именем mc. Когда Вы вызываете midnight commander фактически вызывается эта фунция, которая вызывает mc с ключом "-P". При этом mc, завершая работу записывает текущий каталог в файл, указаный после этого ключа. Функция читает этот файл и выполняет cd `cat file`. То есть выполняет переход в ту директорию из которой вышел mc. Поскольку функия выполняется в той же оболочке, после выхода из фунции новая директория сохраняется и для пользователя все выглядит так, как будто он изменил директорию в mc, вышел и остался в новой директории.
Правда, существуют и исключения. Некоторые файлы создаются как исполняемые (например, /etc/bash_completion), но это право доступа для них никогда не является принципиально важным.
Стартовые файлы (которые традиционно находятся во всех дистрибутивах в /etc/rc.d/), напротив, не только являются исполняемыми, но и существенно зависят от этого атрибута. В некоторых случаях, для ускорения начальной загрузки (ненамного) они запускаются не последовательно, а одновременно, что, как легко понять, требует порождения для каждого файла отдельного процесса.
Кроме того, в /etc могут создаваться субдиректории, которые, в большинстве, используюся каким-то единственным приложением или подсистемой. В таких директориях обычно бывают перемешаны сценарии и файлы конфигурации. В очень редких случаях там могут находиться символьные ссылки на исполняемые файлы (/etc/X11/X). Сами исполняемые файлы (программы, не сценарии) я не встречал никогда.
я опять себячуствую безнодежно тупым. 
ЗАчем все так усложнять? Зачем одни и те же файлы совать по разным директориям и почему просто ссылки на них не создавать?
Почему не сделать один каталог куда положить все файлы настроек,
1 каталог для драйверов, короче как то разграничить .... такая ведь каша....
Но енаверное я просто расуждаю как ламер
Все уменые а я баран.....
Понамудрено везде!!!!!
Особенно ответ sash в одном из топиков порадовал: цитирую
"...Дефолтовая ориентация фреймбуффера..." или "Это не заметно при использовании кутопии в vga режиме, но вылазит боком при использовании режима qvga и использовании yuv/rgb оверлея"
Ладно будем разбираться.
ЗАчем все так усложнять? Зачем одни и те же файлы совать по разным директориям и почему просто ссылки на них не создавать?
Почему не сделать один каталог куда положить все файлы настроек,
1 каталог для драйверов, короче как то разграничить .... такая ведь каша....
Но енаверное я просто расуждаю как ламер
Все уменые а я баран.....
Понамудрено везде!!!!!
Особенно ответ sash в одном из топиков порадовал: цитирую
"...Дефолтовая ориентация фреймбуффера..." или "Это не заметно при использовании кутопии в vga режиме, но вылазит боком при использовании режима qvga и использовании yuv/rgb оверлея"
Ладно будем разбираться.
zaurus SL 760
sil, высказывания sash я комментировать не возьмусь. Я вообще не силен в комментировании англицизмов 
.
По поводу местонахождения файлов - возьмите архив www.killefiz.de. Там всего-то с тысячу пакетов, но четкой структуры уже нет и по категории найти нужный пакет невозможно - только поиском. Попробуйте увеличить количество пакетов в 50 раз, сделайте сотню независимых друг от друга серверов на каждом из которых дерево директорий будут создавать разные люди, учтите при этом, что редко какой пакет идеально вписывается в одну-единственную категорию и скажите мне: уверены ли Вы, что через 30 лет бездумного накопления этих пакетов достаточно легко будет понять, каким образом сложилась существующая иерархия категорий?
.По поводу местонахождения файлов - возьмите архив www.killefiz.de. Там всего-то с тысячу пакетов, но четкой структуры уже нет и по категории найти нужный пакет невозможно - только поиском. Попробуйте увеличить количество пакетов в 50 раз, сделайте сотню независимых друг от друга серверов на каждом из которых дерево директорий будут создавать разные люди, учтите при этом, что редко какой пакет идеально вписывается в одну-единственную категорию и скажите мне: уверены ли Вы, что через 30 лет бездумного накопления этих пакетов достаточно легко будет понять, каким образом сложилась существующая иерархия категорий?
/home - в всех остальных Линукс-системах за исключением наших Zaurus'ов в этой директории создаются домашние директории пользователей в которых те вольны хранить все, что им угодно. Чтобы воспрепятствовать бесконтрольному разрастанию таких директорий (место на диске все-таки не резиновое) может быть использована система квот, аналогичная квотированию дискового пространства для размещения вложений или почтовых ящиков на интернет-серверах. В нашем случае эта директория во-первых, сразу после hard reset уже содержит абсолютно все файлы, которые Вы вправе изменять и, во-вторых, плюс к этому будет содержать абсолютно все файлы, которые Вы впоследствии добавите (например, устанавливая новые приложения). Для этого в /home существуют директории /home/QtPalmtop и /home/system которым не соответствует ни один пользователь.
Еще одним отличием нашего /home от обычного является тот факт, что домашняя директория суперпользователя, которая во всех остальных случаях называется /root и лежит в корневой директории, в нашем случае (/home/root) также находится в /home.
Лирическое отступление:
Причины побудившие Sharp соорудить такую странную конструкцию достаточно понятны - чтобы защитить флеш-память от модификации неопытным пользователем применена достаточно простая схема: флеш разделен на три части: boot (7MB), initrd (25-50MB) и пользовательская область (все остальное). boot в свою очередь тоже разделен на части: в частности там находится диагностическое меню, две копии ядра и еще одна файловая система с небольшим набором утилит - именно она монтируется как корневая при загрузке по "D"+"B".
boot при нормальной загрузке не монтируется вовсе, чтобы его нельзя было никак повредить (на самом деле сделать с помощью dd это можно с два счета), initrd (доступный как /dev/mtdblock2 он же /dev/root) монтируется как read-only корневая файловая система, а /dev/mtdblock3 монтируется на /home и поэтому все, что можно записать, попадает именно туда.
Однако получившаяся в результате файловая структура не выглядит не только идеальной, но даже хоть сколько-то близкой к такому состоянию. Зачем, скажите на милость, они запихнули в /root все, что они туда запихнули? Насколько легко неопытному пользователю понять, что бессмысленно править /etc/rc.d/rc.sysinit - он существует, но это не тот файл, который фактически используется при загрузке системы?
И т.д. и т.п...
/lib - здесь все просто. В этой директории хранятся общесистемные библиотеки. То есть, полная аналогия с директорией /bin: в /bin находятся "общие" программы, в /usr/bin - порльзовательские. Аналогично с /lib и /usr/lib.
Во всех остальных Линукс-системах возникает естественный вопрос: какие файлы можно отнести к общесистемным, а какие к пользовательским? Но не в нашем случае. Поскольку и /lib и /bin находятся в файловой системе доступной только для чтения, любые модификации можно выполнять только с их компаньонами в /usr.
Только самым важным приложениям, таким как iptables дозволено создавать в /lib субдиректории и хранить там свои библиотеки.
Но /lib имеет еще одну неожиданную функцию - при загрузке модулей ядра они по умолчанию ищутся в директории /lib/modules/`uname -r`.
Еще одним отличием нашего /home от обычного является тот факт, что домашняя директория суперпользователя, которая во всех остальных случаях называется /root и лежит в корневой директории, в нашем случае (/home/root) также находится в /home.
Лирическое отступление:
Причины побудившие Sharp соорудить такую странную конструкцию достаточно понятны - чтобы защитить флеш-память от модификации неопытным пользователем применена достаточно простая схема: флеш разделен на три части: boot (7MB), initrd (25-50MB) и пользовательская область (все остальное). boot в свою очередь тоже разделен на части: в частности там находится диагностическое меню, две копии ядра и еще одна файловая система с небольшим набором утилит - именно она монтируется как корневая при загрузке по "D"+"B".
boot при нормальной загрузке не монтируется вовсе, чтобы его нельзя было никак повредить (на самом деле сделать с помощью dd это можно с два счета), initrd (доступный как /dev/mtdblock2 он же /dev/root) монтируется как read-only корневая файловая система, а /dev/mtdblock3 монтируется на /home и поэтому все, что можно записать, попадает именно туда.
Однако получившаяся в результате файловая структура не выглядит не только идеальной, но даже хоть сколько-то близкой к такому состоянию. Зачем, скажите на милость, они запихнули в /root все, что они туда запихнули? Насколько легко неопытному пользователю понять, что бессмысленно править /etc/rc.d/rc.sysinit - он существует, но это не тот файл, который фактически используется при загрузке системы?
И т.д. и т.п...
/lib - здесь все просто. В этой директории хранятся общесистемные библиотеки. То есть, полная аналогия с директорией /bin: в /bin находятся "общие" программы, в /usr/bin - порльзовательские. Аналогично с /lib и /usr/lib.
Во всех остальных Линукс-системах возникает естественный вопрос: какие файлы можно отнести к общесистемным, а какие к пользовательским? Но не в нашем случае. Поскольку и /lib и /bin находятся в файловой системе доступной только для чтения, любые модификации можно выполнять только с их компаньонами в /usr.
Только самым важным приложениям, таким как iptables дозволено создавать в /lib субдиректории и хранить там свои библиотеки.
Но /lib имеет еще одну неожиданную функцию - при загрузке модулей ядра они по умолчанию ищутся в директории /lib/modules/`uname -r`.
/mnt - существует далеко не всех вариантах Unix. Используется исключительно для создания в ней субдиректорий на которые монтируются дополнительные файловые системы.
/opt - "optional" (иногда добавляют "for layered products"). Прямая противоположность с /mnt: эта директория очень типична для Unix, но редко встречается в Linux. Один из очень немногих (наряду с некоторыми базами данных, всякими там Globus Toolkit'ами и пр.) продуктов использующих в Линукс эту директорию - графическая среда Qtopia.
/proc - "псевдо файловая система". То есть файловая система, которой не соответствует никакой реальный носитель. На самом деле по все той же метафоре ("все, что угодно - это файл") получить всю необходимую информацию о состоянии Вашей операционной системы можно, просто просматривая якобы существующие файлы в этой файловой системе. Формат /proc очень плохо стандартизован и постоянно меняется не только при переходе между разными вариантами Unix, но даже от версии к версии Linux. Первоначально эта файловая система была предназначена только для получения справочной информации о системе, но никак не для управления ей. То есть любая попытка записи в эти псевдофайлы попросту игнорировалась. К сожалению, через некоторое время исходная парадигма забылась, /proc перегрузили несвойственными ей функциями и теперь не только запись, но даже простая попытка чтения из некоторых файлов может в некоторых случаях изменить состояние системы. В Linux для управления системой долго использовалась директория /proc/sys. Файлы в этой директории можно не только читать но и изменять, изменяя тем самым системные параметры связанные с этими файлами. В версии 2.6 ядра значительная часть функциональности /proc/sys была вынесена в новую файловую систему sysfs, монтируемую на директорию /sys (понятно, что монтировать что угодно можно куда угодно. Никто не в состоянии запретить Вам смонтировать procfs на /mnt/floppy. Просто это не принято).
Первое, что Вы увидите по "ls /proc" - это большое количество субдиректорий со странными именами состоящими из одних цифр. Их количество должно быть равно количеству процессов в таблице задач. В каждой такой директории хранится информация о состоянии и ресурсах процесса с этим номером. Именно отсюда берет свою информацию известная Вам программа ps. (Вообще все стандартные информационные программы, начиная от mount без параметров и кончая free берут свои данные именно из /proc).
Поясним назначение некоторых файлов из /proc/<номерпроцесса>:
cwd - символьная ссылка на текущую директорию процесса
fd - директория, которая теоретически должна содержать ссылки на все открытые этим процессом файлы. Ссылка при этом имеет имя == номеру дескриптора с которым этот файл открыт в данном процессе.
root - ссылка на корневую директорию файловой системы. После chroot может отличаться от "/".
cmdline - аргументы командной строки с которыми был вызван процесс.
environ - переменные окружения
exe - ссылка на исполняемый файл
maps - карта выделенного процессу адресного пространства
...
/root - во всех нормальных вариантах Линукса в этой директории расположена домашняя директория суперпользователя root. В нашем случае, директория используется как свалка... ладно, скажем "как склад" для хранения архивов файлов из которых будет восстановлено содержимое пользовательского раздела при жесткой перезагрузке.
/opt - "optional" (иногда добавляют "for layered products"). Прямая противоположность с /mnt: эта директория очень типична для Unix, но редко встречается в Linux. Один из очень немногих (наряду с некоторыми базами данных, всякими там Globus Toolkit'ами и пр.) продуктов использующих в Линукс эту директорию - графическая среда Qtopia.
/proc - "псевдо файловая система". То есть файловая система, которой не соответствует никакой реальный носитель. На самом деле по все той же метафоре ("все, что угодно - это файл") получить всю необходимую информацию о состоянии Вашей операционной системы можно, просто просматривая якобы существующие файлы в этой файловой системе. Формат /proc очень плохо стандартизован и постоянно меняется не только при переходе между разными вариантами Unix, но даже от версии к версии Linux. Первоначально эта файловая система была предназначена только для получения справочной информации о системе, но никак не для управления ей. То есть любая попытка записи в эти псевдофайлы попросту игнорировалась. К сожалению, через некоторое время исходная парадигма забылась, /proc перегрузили несвойственными ей функциями и теперь не только запись, но даже простая попытка чтения из некоторых файлов может в некоторых случаях изменить состояние системы. В Linux для управления системой долго использовалась директория /proc/sys. Файлы в этой директории можно не только читать но и изменять, изменяя тем самым системные параметры связанные с этими файлами. В версии 2.6 ядра значительная часть функциональности /proc/sys была вынесена в новую файловую систему sysfs, монтируемую на директорию /sys (понятно, что монтировать что угодно можно куда угодно. Никто не в состоянии запретить Вам смонтировать procfs на /mnt/floppy. Просто это не принято).
Первое, что Вы увидите по "ls /proc" - это большое количество субдиректорий со странными именами состоящими из одних цифр. Их количество должно быть равно количеству процессов в таблице задач. В каждой такой директории хранится информация о состоянии и ресурсах процесса с этим номером. Именно отсюда берет свою информацию известная Вам программа ps. (Вообще все стандартные информационные программы, начиная от mount без параметров и кончая free берут свои данные именно из /proc).
Поясним назначение некоторых файлов из /proc/<номерпроцесса>:
cwd - символьная ссылка на текущую директорию процесса
fd - директория, которая теоретически должна содержать ссылки на все открытые этим процессом файлы. Ссылка при этом имеет имя == номеру дескриптора с которым этот файл открыт в данном процессе.
root - ссылка на корневую директорию файловой системы. После chroot может отличаться от "/".
cmdline - аргументы командной строки с которыми был вызван процесс.
environ - переменные окружения
exe - ссылка на исполняемый файл
maps - карта выделенного процессу адресного пространства
...
/root - во всех нормальных вариантах Линукса в этой директории расположена домашняя директория суперпользователя root. В нашем случае, директория используется как свалка... ладно, скажем "как склад" для хранения архивов файлов из которых будет восстановлено содержимое пользовательского раздела при жесткой перезагрузке.
/sbin - ("system binary") директория в которой хранятся системные утилиты. Как правило только суперпользователь (система привилегий в Unix примитивна до безобразия: есть суперпользователь и все остальные) имеет право их использовать. Поэтому для остальных пользователей этого каталог даже не включен в переменную PATH. Не потому, конечно, чтобы они не могли случайно их запустить и все испортить - обычный пользователь всегда может использовать полное имя файла "/sbin/iptables" или "/sbin/insmod". Только это ничего не даст - программы аварийно завершатся с сообщением о недостаточных привилегиях.
Точно так же как и директории bin и lib, sbin "един в двух лицах": кроме самого каталога /sbin есть еще /usr/sbin причем что хранить в последнем вроде бы совершенно непонятно. По аналогии с остальными подобными директориями в /sbin необходимо было бы хранить "общесистемные", а в /usr/sbin "пользовательские" системные утилиты. Причем, по смыслу самого каталога sbin исключительно для использования суперпользователем. К сожалению, фраза "пользовательские системные утилиты для суперпользователя" напрочь лишена какого-либо смысла.
/tmp - самый простой каталог, служит исключительно для временных файлов, то есть для файлов, которые не жалко потерять между перезагрузками. Очень часто располагается на RAM-диске что обеспечивает исключительно быстрый доступ к временным файлам. Размер электронного диска (glibc 2.2 и старше рассчитывают, что он будет монтирован на /dev/shm) у Линукс всегда ограничен сразу в момент монтирования этого диска. Строго говоря, существуют два разных вида RAM-дисков (я имею в виду tmpfs о которой шла речь и собственно ramdisk, т.е. /dev/ram* и rdev -r), но забивать себе голову последними не стоит.
P.S. уже ночь и текст получился какой-то неудачный.... завтра либо перепишу либо вообще сотру его на фиг.
Точно так же как и директории bin и lib, sbin "един в двух лицах": кроме самого каталога /sbin есть еще /usr/sbin причем что хранить в последнем вроде бы совершенно непонятно. По аналогии с остальными подобными директориями в /sbin необходимо было бы хранить "общесистемные", а в /usr/sbin "пользовательские" системные утилиты. Причем, по смыслу самого каталога sbin исключительно для использования суперпользователем. К сожалению, фраза "пользовательские системные утилиты для суперпользователя" напрочь лишена какого-либо смысла.
/tmp - самый простой каталог, служит исключительно для временных файлов, то есть для файлов, которые не жалко потерять между перезагрузками. Очень часто располагается на RAM-диске что обеспечивает исключительно быстрый доступ к временным файлам. Размер электронного диска (glibc 2.2 и старше рассчитывают, что он будет монтирован на /dev/shm) у Линукс всегда ограничен сразу в момент монтирования этого диска. Строго говоря, существуют два разных вида RAM-дисков (я имею в виду tmpfs о которой шла речь и собственно ramdisk, т.е. /dev/ram* и rdev -r), но забивать себе голову последними не стоит.
P.S. уже ночь и текст получился какой-то неудачный.... завтра либо перепишу либо вообще сотру его на фиг.
1
Вот уже что то из тумана непознанного начинает проступать и становится позвнаваемым....
zaurus SL 760