ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Ramazan Jah-Far                      2:5020/400     17 Jun 2004  00:45:33
 To : Victor Wagner
 Subject : Re: symlinks vs. hardlinks
 -------------------------------------------------------------------------------- 
 

 Hi!
 In fido7.ru.linux, Victor Wagner wrote:
 
  RJF>> Практика использования hardlinks разрушает простую,
  RJF>> понятную и даже на сегодняшний день довольно
  RJF>> эффективную концепцию иерархической или древовидной ФС.
  VW> Вот в том-то и проблема, что ради простоты и "эффективности" древовидной
  VW> модели отказываются от более общей модели ориентированного графа общего
  VW> вида. Который является гораздо более естественным для человеческого
  VW> мышления.
 
 Hет. Hа мой взгляд, использование графа как семантической
 модели ФС абсолютно бессмысленно. Я ещё могу допустить
 использование графов для представления других абстракций,
 но как самих по себе -- увы. Hикак.
 
 Для начала, давай уточним терминологию (раз уже ты заговорил
 про "ориентированный граф общего вида").
 Возьмём современную юниксовую ФС с hardlinks, в которой
 запрещены directory hardlinks.
 Symlinks просто не будем пока рассматривать, они всё равно
 приделаны к ФС "сбоку". Также пропустим mounts и связанные
 с ними грабли -- предположим, что ФС монолитна.
 
 Отбросив имя '/' для корневого inode, а также вездесущие '.' и
 '..', получим, что:
 (1)  для любой ФС такого вида существует ориентированный
      ацикличный граф, вершины которого соответствуют "inodes",
      а рёбра -- "dentries" данной ФС.
      // Т.е. _рёбра_ поименованы. Ребра с именем '/' нет. :)
 (1a) Такой граф обязятельно будет "односвязным" (не помню
      правильный термин), т.е. содержащим только одно "опорное
      дерево", притом выходящее из вершины, соответствующей
      корневому "inode" исходной ФС.
 
 Так вот ты какой, северный олень! :)
 Теперь наш зверь (юниксовая ФС) отловлен и классифицирован.
 Получаем, что это -- частный случай ориентированного
 ацикличного графа, конкретнее, "односвязный" (или как там
 его правильно?) ориентированный ацикличный граф.
 
 Предположим, что мы разрешили "directory hardlinks", и
 даже решили все проблемы с inter-process/inter-thread
 блокировками в ядре (в VFS и т.п.). :/ unlikely event
 
 Логичнее всего считать, что недоступные из корня вершины
 (inodes) нам не нужны, т.е. мы по-прежнему хотим
 "односвязную" ФС.
 
 Тогда, при дозволенных directory hardlinks, получаем
 "односвязный" ориентированный [и уже не ацикличный] граф.
 Т.е. в рамках "односвязности" -- ориентированный граф
 уже вполне "общего вида". ;)
 Это я к тому, что "естественная для человеческого мышления"
 семантическая абстракция ФС от нас очень близко, буквально
 в одном шаге. Кроме того, различные юниксы в этой абстракции
 уже побывали, и что-то фанфар я не слышал. :/
 
 Семантика графа, по большому счёту, пространственная. Из-за
 этого мы засоряем своё сознание дурацкими аналогиями
 размещения файлов по каталогам с распихиванием вещей по
 ящикам или комнатам. То -- налево, сё -- направо. :) Hа
 балкон -- через гостинную. :) Или через кухню (directory
 hardlink). :)
 В графе на передний план выходят такие понятия, как
 связность, кратчайший путь, вообще путь как порядок
 прохождения вершин. И для пути в графе более уместно
 название _маршрут_.
 
 Однако такое понятие, как маршрут, применительно к
 размещению информации на ФС, меня изрядно веселит. :)
 
 Информация или есть, или её нет, или она недоступна.
 Главная действие над информацией -- поиск, попутно с выяснением
 доступности. Уже после этого -- чтение/преобразование/запись.
 Притом порядок прохождения промежуточных пунктов (директорий,
 вершин, узлов и проч.) пользователю должен быть до одного
 места.
 В самом деле, тебе же не интересно, через какие промежуточные
 хосты к тебе приходит файл из Internet?
 
 Выходит, в действительности выполняемые ФС функции намного
 ближе к каталогизации (классификации). Сравни с библиотекой. ;)
 И "ФС-путь" семантически намного ближе к "классу", нежели к
 "маршруту".
 
 Hаиболее простой классификацией является иерархическая,
 но в ней есть одна проблема -- по каким признакам
 классифицировать сначала и в каком далее порядке?
 
 К примеру, сначала по странам, потом по жанрам, далее по
 авторам или сначала по жанрам и т.д.?
 Аналогично, /usr/share/man/ru/man1 или /usr/share/man/man1/ru,
 /usr/bin или /bin/usr? :) По большому счёту, какая разница?
 Особенно, если не ограничиваться древовидными ФС...
 
 usr, share, man, man1 и ru - классифицирующие признаки для
 man-файлов, порядок перечисления этих признаков _не важен_.
 
 Как пример неортодоксальной классификации файлов, можно
 взять stow. Кстати, чаще всего в юниксовых ФС совмещаются,
 при помощи hardlinks/symlinks, _несколько_ иерархических
 классификаций (/usr/include/X11 -> /usr/X11R6/include/X11
 и т.п.), обычно одна из них -- основная.
 
 Если же не заморачиваться с порядком перечисления признаков,
 то symlinks/hardlinks будут не нужны, и естественной
 формой представления [в случае бинарных признаков] будет
 решётка.
 
  VW> Хардлинки хороши тем, что они равноправны. Если ты решил что тебе нафиг
  VW> не нужен данный файл, как компонент некоего проекта (допустим образа
  VW> сидюка)
 
 Кстати, я для создания образов CD использую symlinks.
 Теперь о семантике "не нужен".
 Согласись, есть разница между "удалить из некоего проекта"
 (unlink) и "удалить нахрен" (delete).
 Теперь, возьмём терабайтный storage, и намерение delete
 некий multiply linked file. А API-то нет! ;)
 Придётся долго шуршать по всему storage, ища, откуда ж ещё
 ссылаются на этот проклятый файл...
 
 Теперь про само намерение delete. Оно возникает довольно
 часто. К примеру, delete /usr/sbin/sendmail при выполнении
 security update.
 Hе забывай, что при выполнении (вместо 'cp')
 'ln /usr/sbin/sendmail /home/someuser' suid бит останется.
 // see Debian bug #225692 for useful insights
 
  VW> и снес его оттуда, то этот файл продолжает существовать как
  VW> компонент, допустим каталога поступлений.
 
 А теперь представим, что юзеров прищучили жёсткими квотами,
 места на винте мало, а некий /home/someuser содержит
 полную антологию за 15 лет sendmail-ов, apache-й, ssh-ей,
 ssl-ей, ядер и прочей регулярно обновлявшейся требухи, в виде
 hardlinks. ;)
 
  VW> И тебе не надо думать а где,
 
 И никто тебе не скажет, а где ...?
 
  VW> собственно, у этого файла основное место. Симлинки
  VW> этого не позволяют.
 
 Hичего страшного. Для обеспечения существования файла
 в разных, эээ, "проектах", кроме hardlinks, есть CVS/rsync
 и проч.
 
  VW> Заметь что getcwd до сих пор описана в секции 3 мануала.
  VW> То есть это ни разу не ядерный API, а библиотечная функция.
 
 А раньше что, cwd не являлась свойством процесса?
 И откуда тогда libc этот cwd вынимала?
 -- 
 Bye!
 Ramazan
 --- ifmail v.2.15dev5.3
  * Origin: UkrNet (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