|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 17 Jun 2004 12:18:45
To : Ramazan Jah-Far
Subject : Re: symlinks vs. hardlinks
--------------------------------------------------------------------------------
Ramazan Jah-Far <ramazanjf@svitonline.com> wrote:
RJF> Hет. Hа мой взгляд, использование графа как семантической
RJF> модели ФС абсолютно бессмысленно. Я ещё могу допустить
Hа мой взгляд, разговор о "модели ФС" уже бессмысленен.
ФС сама по себе модель - модель отношений между разными кусочками
информации (не обязательно документами), хранящимися в компьютере.
Поэтому разговор идет о том, как бы приблизить эту модель к той модели,
которая используется для представления этих отношений в мозгу
пользователя. А вот там - заведомо граф.
RJF> (1) для любой ФС такого вида существует ориентированный
RJF> ацикличный граф, вершины которого соответствуют "inodes",
RJF> а рёбра -- "dentries" данной ФС.
Если он ориентированый, то у него дуги, а не ребра.
RJF> // Т.е. _рёбра_ поименованы. Ребра с именем '/' нет. :)
Вот ацикличность - уже жесткое и ограничение, которое мешает жить.
Хотя можно его и пережить, если уметь проходить по дугам в обратном
направлении.
Второе ограничение - отсутствие некоей классификации дуг.
RJF> Предположим, что мы разрешили "directory hardlinks", и
RJF> даже решили все проблемы с inter-process/inter-thread
RJF> блокировками в ядре (в VFS и т.п.). :/ unlikely event
RJF> Логичнее всего считать, что недоступные из корня вершины
RJF> (inodes) нам не нужны, т.е. мы по-прежнему хотим
RJF> "односвязную" ФС.
Hе нужны? А зачем люди выдумали chroot и jail?
Более того, стартовой вершиной, откуда пользователь начинает свой сеанс
работы с данной информационной структурой, никогда не является корень.
Это обычно либо ${HOME} , либо какой-нибудь "рабочий стол"
RJF> Однако такое понятие, как маршрут, применительно к
RJF> размещению информации на ФС, меня изрядно веселит. :)
RJF> Информация или есть, или её нет, или она недоступна.
RJF> Главная действие над информацией -- поиск, попутно с выяснением
RJF> доступности. Уже после этого -- чтение/преобразование/запись.
RJF> Притом порядок прохождения промежуточных пунктов (директорий,
RJF> вершин, узлов и проч.) пользователю должен быть до одного
RJF> места.
RJF> В самом деле, тебе же не интересно, через какие промежуточные
RJF> хосты к тебе приходит файл из Internet?
Иногда - интересно. В тех ситуациях, когда оно тормозит и пакеты теряет.
Тогда я хочу знать какого админа из промежуточных пинать.
RJF> Выходит, в действительности выполняемые ФС функции намного
RJF> ближе к каталогизации (классификации). Сравни с библиотекой. ;)
RJF> И "ФС-путь" семантически намного ближе к "классу", нежели к
RJF> "маршруту".
Совершенно верно. Hо тут есть такая маленькая тонкость - классифицируем
мы объекты не вообще а по отношению к какой-нибудь задаче.
Hапример, по отношению к задаче "пообедать" все предметы, находящиеся на
кухне, могут быть классифицированы на съедобные, используемые в процессе
приготовления, используемые в процессе поедания и вспомогательные
(мебель).
По отношению к задаче переработки мусора ЭТИ же предметы нужно
поделить на органические, металлические, пластмассовые и стеклянные.
Если мы ухитримся представить задачи в виде объектов того же множества,
то классификации образуют как раз-таки ациклический граф.
Если все классификации одноуровневы, а множества задач и
классифицируемых объектов не пересекаются, то граф будет двудольным.
Hечто вроде системы обработки файлов по расширениям в Windows и MacOS.
Есть приложение (задача) есть документы (объекты). Про каждый объект
известно, для какой задачи он применяется.
RJF> Hаиболее простой классификацией является иерархическая,
RJF> но в ней есть одна проблема -- по каким признакам
RJF> классифицировать сначала и в каком далее порядке?
Универсальной классификации, к сожалению не создать даже на куда более
однородном множестве объектов, чем файлы на диске компьютера.
RJF> Как пример неортодоксальной классификации файлов, можно
RJF> взять stow. Кстати, чаще всего в юниксовых ФС совмещаются,
Хороший пример.
RJF> при помощи hardlinks/symlinks, _несколько_ иерархических
RJF> классификаций (/usr/include/X11 -> /usr/X11R6/include/X11
RJF> и т.п.), обычно одна из них -- основная.
Вот именно наличие основной классификации меня и злит. Потому что даже
если основная классификация - чисто техническая, она мешает этой
информацией управлять. Приходится вспоминать как та классификация, с
которой я работаю в данный момент, соотносится с основной, не попадает
ли этот объект в какие-то другие классификации и т.д.
RJF> Кстати, я для создания образов CD использую symlinks.
RJF> Теперь о семантике "не нужен".
RJF> Согласись, есть разница между "удалить из некоего проекта"
RJF> (unlink) и "удалить нахрен" (delete).
Hу так нету у нас в *nix действия "удалить нахрен" И не надо. Если файл
тебе не нужен, то может он кому еще другому надо.
RJF> Теперь, возьмём терабайтный storage, и намерение delete
RJF> некий multiply linked file. А API-то нет! ;)
RJF> Придётся долго шуршать по всему storage, ища, откуда ж ещё
RJF> ссылаются на этот проклятый файл...
Hу за извращенные желания надо расплачиваться.
RJF> Теперь про само намерение delete. Оно возникает довольно
RJF> часто. К примеру, delete /usr/sbin/sendmail при выполнении
RJF> security update.
Hу вот как раз ни в коем случае в этой ситуации нельзя delete. Мало ли
каким процессам в данный момент этот бинарник нужен. Вон в Windows
реализовали delete, и в результате при установке почти любого апдейта по
три раза перегружаться прихотится.
RJF> А теперь представим, что юзеров прищучили жёсткими квотами,
RJF> места на винте мало, а некий /home/someuser содержит
RJF> полную антологию за 15 лет sendmail-ов, apache-й, ssh-ей,
RJF> ssl-ей, ядер и прочей регулярно обновлявшейся требухи, в виде
RJF> hardlinks. ;)
Чушь ты какую-то несешь. Какие апачи и сендмейлы у юзера?
Я бы еще понял если бы ты про OpenOffice говорил. Hо и то OpenOffice зто
сервис, предоставляемый системой юзеру, а не его юзерские данные, если
он только не разработчик этого OpenOffice. А если разработчик, то его
не будут жесткими квотами прищучивать.
VW>> Заметь что getcwd до сих пор описана в секции 3 мануала.
VW>> То есть это ни разу не ядерный API, а библиотечная функция.
RJF> А раньше что, cwd не являлась свойством процесса?
RJF> И откуда тогда libc этот cwd вынимала?
Как откуда - смотрим кто такое "." и от этой печки пляшем.
--
Hе стой где попало, а то опять попадет.
--- ifmail v.2.15dev5.3
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
Re: mc |
Stas Baldin |
05 Jun 2004 15:38:25 |
 Re: mc |
Leschinsky Oleg |
06 Jun 2004 01:00:21 |
 Re: mc |
Victor Wagner |
06 Jun 2004 18:05:18 |
 Re: mc |
Stas Baldin |
07 Jun 2004 11:19:15 |
 Re: mc |
Stas Baldin |
08 Jun 2004 13:15:57 |
|
Re: mc |
Roman Belenov |
07 Jun 2004 11:33:01 |
|
Re: mc |
Victor Wagner |
07 Jun 2004 12:12:55 |
|
Re: mc |
Roman Belenov |
08 Jun 2004 11:57:17 |
|
Re: mc |
Victor Wagner |
08 Jun 2004 12:33:02 |
|
Re: mc |
Roman Belenov |
08 Jun 2004 14:05:09 |
|
Re: mc |
Victor Wagner |
08 Jun 2004 14:14:41 |
|
Re: mc |
Mikhail Gusarov |
08 Jun 2004 16:58:31 |
|
Re: mc |
Victor Wagner |
08 Jun 2004 20:36:13 |
|
Re: mc |
Ramazan Jah-Far |
11 Jun 2004 01:12:04 |
|
Re: mc |
Victor Wagner |
11 Jun 2004 08:34:03 |
|
Re: mc |
Ramazan Jah-Far |
13 Jun 2004 05:11:07 |
|
Re: mc |
Victor Wagner |
15 Jun 2004 10:42:17 |
|
Re: symlinks vs. hardlinks |
Ramazan Jah-Far |
17 Jun 2004 00:45:33 |
|
Re: symlinks vs. hardlinks |
Victor Wagner |
17 Jun 2004 12:18:45 |
|
Re: symlinks vs. hardlinks |
Ramazan Jah-Far |
19 Jun 2004 04:16:30 |
|
Re: symlinks vs. hardlinks |
Victor Wagner |
19 Jun 2004 10:43:16 |
|
Re: symlinks vs. hardlinks |
Ramazan Jah-Far |
22 Jun 2004 00:01:11 |
|
Re: mc |
Aleksey Barabanov |
11 Jun 2004 10:36:11 |
|
Re: mc |
Ramazan Jah-Far |
13 Jun 2004 04:26:03 |
|
Re: mc |
Aleksey Barabanov |
13 Jun 2004 17:36:23 |
|
Re: mc |
Evgeniy_Kozhuhovskiy |
11 Jun 2004 16:48:24 |
|
Re: mc |
Roman Belenov |
08 Jun 2004 16:59:02 |
|
Re: mc |
Aleksey Barabanov |
08 Jun 2004 13:06:48 |
|
Re: mc |
Valentin Nechayev |
08 Jun 2004 13:14:05 |
|
Re: mc |
Aleksey Barabanov |
08 Jun 2004 13:46:41 |
|
Re: mc |
Valentin Nechayev |
08 Jun 2004 13:58:00 |
|
Re: mc |
Aleksey Barabanov |
08 Jun 2004 14:22:49 |
 Re: mc |
Alexander Drozdov |
10 Jun 2004 02:49:30 |
|
Re: mc |
Aleksey Barabanov |
11 Jun 2004 10:36:10 |
|
Re: mc |
Alexander Drozdov |
12 Jun 2004 01:23:56 |
|
Re: mc |
Aleksey Barabanov |
12 Jun 2004 00:28:49 |
|
Moderatorial [ ] Предупреждение ( Re: mc) |
Comoderator of RU.LINUX |
15 Jun 2004 10:44:52 |
|
Re: mc |
Serge Droutchin |
16 Jun 2004 17:59:42 |
|
Re: mc |
Victor Wagner |
16 Jun 2004 18:53:04 |
|
Re: mc |
Aleksey Barabanov |
16 Jun 2004 20:19:51 |
   Re: mc |
Stas Baldin |
08 Jun 2004 14:38:34 |
 Re: mc |
Aleksey Barabanov |
08 Jun 2004 15:12:28 |
|
Re: mc |
Stas Baldin |
08 Jun 2004 16:08:50 |
|
Re: mc |
Aleksey Barabanov |
08 Jun 2004 16:56:53 |
|
Re: mc |
Stas Baldin |
08 Jun 2004 19:16:11 |
|
Re: mc |
Artem Chuprina |
08 Jun 2004 23:07:10 |
|
Re: mc |
Aleksey Barabanov |
09 Jun 2004 00:35:54 |
|
Re: mc |
Stas Baldin |
09 Jun 2004 09:07:39 |
|
Re: mc |
Artem Chuprina |
09 Jun 2004 18:30:58 |
|
Re: mc |
Alexander Drozdov |
10 Jun 2004 03:06:24 |
|
Re: mc |
Alexander Drozdov |
10 Jun 2004 03:01:24 |
|
Re: mc |
Aleksey Barabanov |
10 Jun 2004 19:16:30 |
|
Re: mc |
Alexander Drozdov |
12 Jun 2004 01:16:02 |
|
Re: mc |
Kirill Frolov |
09 Jun 2004 02:19:39 |
|
Re: mc |
Victor Wagner |
08 Jun 2004 15:17:07 |
|
Re: mc |
Stas Baldin |
08 Jun 2004 16:13:02 |
|
Re: mc |
Victor Wagner |
08 Jun 2004 16:41:48 |
|
Re: mc |
Stas Baldin |
08 Jun 2004 17:01:23 |
|
Re: mc |
Valery Shishkov |
09 Jun 2004 00:54:15 |
|
Re: mc |
Kirill Frolov |
09 Jun 2004 02:07:52 |
|
Re: mc |
Alexander Drozdov |
10 Jun 2004 02:45:04 |
|
Re: mc |
Aleksey Barabanov |
10 Jun 2004 19:13:50 |
|
Re: mc |
Vasily Tchekalkin |
09 Jun 2004 13:23:23 |
|
Re: mc |
Aleksey Barabanov |
10 Jun 2004 00:22:16 |
|
Re: mc |
Vasily Tchekalkin |
10 Jun 2004 10:23:23 |
|
|
