> > Наиболее часто используются сетевые файловые системы NCPFS (для доступа к серверам Novell NetWare),

> Наиболее часто используемая? Шухер! Некрофилы в городе!

В свое время использовались часто, да и сейчас тоже. У нас последний сервера нетвари умер год назад, на ЖД до сих пор используется вовсю. Может выгляните из института в реальную жизнь?

> "сервер Windows" -- спасибо за 5 минут здорового смеха

Да на здоровье. Могу повторить эту фразу еще десять раз. Кстати именно из-за таких в свое время смеявшихся сейчас во всех крупных компаниях развернуты среди прочего Active Directory и Exchange. Смешинкой не подавились? По спине постучать?

> Параметра "timeout" не существует.

Да, согласен. Мой баг - ХЗ откуда взялся.

> Собственно говоря, всегда можно выбрать обратно. Могу помочь более-менее быстро перегнать.

Тоже дело. Одно только "но" - поскольку я не собираюсь этим заниматься, то вся работа по правке и поддержанию в корректном состоянии TeX'овской части ляжет на вас.

> Оооо, либо я чего-то не так понял ранее, либо чего-то я пропустил, но такое ощущение, что кое-кто стал приглядываться к LaTeX? Гхмм, и как впечатление?

Именно что не поняли и пропустили :) В университетские годы LyX + Pybliographer были моей любимой связкой для написания научных работ. Впечатление соответствующее :)

> Одно только "но" - поскольку я не собираюсь этим заниматься, то вся работа по правке и поддержанию в корректном состоянии TeX'овской части ляжет на вас.

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

>В университетские годы LyX + Pybliographer были моей любимой связкой для написания научных работ. Впечатление соответствующее :)

Что ж - это радует. А что такое Pybliographer? Что такое гоогл я знаю, но хотелось бы услышать авторский комментарий. :)

>Сейчас Вас будут бить. Возможно, даже ногами :) P.S. tex\latex читается как тех\латех

Полагаю ногами хочет Вас отпинать Ваш преподователь английского.

А это такая приблуда, в которую удобно забивать библиографию. Интеграция с LyX ровно такая:

http://pybliographer.sourceforge.net/documentation/x222.html

Стоит ли говорить, что ворд и рядом не валялся :)

Предлагаю выпустить книгу "Linux.org.ru не для идиотов", которая заставит таки юных лоровцев.. АСИЛИТЬ ЦИТАТЫ, МАТЬ ВАШУ!!!!! Я заипался, заипался, заипался прыгать по ссылкам, только чтобы посмотреть, кто кому отвечает!!! :((( И эти людишки ещёс мнят себя пупом земли! =О

>> P.S. tex\latex читается как тех\латех

> Полагаю ногами хочет Вас отпинать Ваш преподователь английского.

А причём здесь английский? Кроме английского есть много других языков, например, греческий.

> # xfs_freeze /home

Требуется только для LVM1 (ядра 2.4).

> # lvcreate -s -L 10G -n home_snapshot /dev/chimera/home

> # xfs_freeze -u /home

Аналогично.

> # dd if=/dev/chimera/home_snapshot of=/dev/st0
> # lvremove /dev/chimera/home_snapshot

> > "сервер Windows" -- спасибо за 5 минут здорового смеха

> Да на здоровье. Могу повторить эту фразу еще десять раз.

Если хорошую шутку повторить несколько раз подряд -- она испортится.

> Кстати именно из-за таких в свое время смеявшихся сейчас во всех
> крупных компаниях развернуты среди прочего Active Directory и Exchange.

И словно мухи тут и там, ходят слухи по домам,
И беззубые старухи их разносят по умам.

Во-первых, отучиваемся отвечать за всю сеть (C). Во-вторых -- если у
кого-то мало ума и сильно много денег -- пускай хоть все отдадут m$.
Не мои же деньги тратят...

> Модуль может быть выгружен, если число ссылок на него станет равно 0.

Тут есть небольшая заморочка. Некоторые модули (например, драйверы сетевых
карт) вообще не ведут подсчет ссылок. rmmod радостно и беззаботно
выгружет такой модуль, даже если интерфейс поднят и используется. Надо
ли объяснять, что ни к чему хорошему это не приводит?

> > Собственно говоря, всегда можно выбрать обратно. Могу помочь более-менее
> > быстро перегнать.

> Тоже дело. Одно только "но" - поскольку я не собираюсь этим заниматься,

Пальцы мешают в дверь проходить? Хотите Вы или нет, но большАя часть
документации к GNU/Linux набрана в TeX (texinfo).

>> "сервер Windows" -- спасибо за 5 минут здорового смеха > Да на здоровье

коректнее было бы написать "Windows-сервер"

> Тут есть небольшая заморочка. Некоторые модули (например, драйверы сетевых карт) вообще не ведут подсчет ссылок

Немного неверно :-) Такие драйвера ведут подсчет ссылок - но немного по другому. Когда ты rmmod'ишь драйвер сетевой, ничего страшного не происходит - интерфейс не совсем мягко, но тем не менее корректно шатдаунится.

> Хотите Вы или нет, но большАя часть документации к GNU/Linux набрана в TeX (texinfo).

Ради бога. Хотите вести в правильном формате - охотно передам вам бразды правления, ведите в чем хотите. Эта штука отнимает немало времени нервов, буду только рад от нее избавиться.

> > # xfs_freeze /home

> Требуется только для LVM1 (ядра 2.4).

Не уверен. Ссылочкой не поделитесь? А то что-то я такого не упомню.

> > > # xfs_freeze /home

> > Требуется только для LVM1 (ядра 2.4).

> Не уверен.

Зато я уверен -- в свое стукнулcя об эти грабли...

AFAIK, функциональность подобная xfs_freeze (и VFS lock patch для
LVM1) включена в ядра >= 2.6.9 (для всех ФС). Более того, если Вы
действительно попытаетесь "заморозить" XFS и сделать потом с нее snaphost,
то lvcreate будет "висеть" до тех пор, пока не "разморозят" ФС.

> Ссылочкой не поделитесь? А то что-то я такого не упомню.

http://tldp.org/HOWTO/LVM-HOWTO/index.html

В частности,

Revision 0.15 2005-06-09 Revised by: ajl
Removed references to xfs_freeze - it is no longer needed;

http://osdir.com/ml/suse.sles-e/2005-02/msg00053.html

> > > 1) xfs_freeze -f /mnt/test
> > 2) lvcreate -s -L500M --name test-snap /dev/system/test
> > 3) xfs_freeze -u /mnt/test
> >
> > Step 2 hangs indefinitely on my machines
>
> Update - this is not a bug but a feature! Apparently the xfs_freeze
> command is no longer required because the lvcreate snapshot command now
> includes the same functionality. Time to modify those scripts...

> Такие драйвера ведут подсчет ссылок - но немного по другому. Когда ты
> rmmod'ишь драйвер сетевой, ничего страшного не происходит - интерфейс
> не совсем мягко, но тем не менее корректно шатдаунится.

1. Ну нифига ж себе -- "ничего страшного"! В старые добрые времена rmmod
в таких случаях говорил "device or resource is busy", и это было хорошо.

2. В статье этого не указано. Написано, что если счетчик ссылок на
модуль -- ноль, то модуль не используется и его можно без зазрения совести
удалять, и _вообще_ ничего не случится. IMHO, следует сказать, что это не
всегда так.

> Ну нифига ж себе -- "ничего страшного"! В старые добрые времена rmmod в таких случаях говорил "device or resource is busy", и это было хорошо.

Оно и сейчас говорить что device busy - но только если он действительно busy. Пример - примонтируйте раздел с SATA-девайса, и попробуйте удалить драйвер контроллера или sd. Сетевой интерфейс под словом "устройство" подразумевает немного другую сущность, потому он и позволяет такое сделать.

> если Вы действительно попытаетесь "заморозить" XFS и сделать потом с нее snaphost, то lvcreate будет "висеть" до тех пор, пока не "разморозят" ФС.

Точно. На моей памяти такая блокировка действительно была в "ранних" 2.6, но в более поздних ее убрали. Теперь судя по результатам теста снова появилась :-)

Спасибо что заметили

> Оно и сейчас говорить что device busy - но только если он действительно
> busy. Пример - примонтируйте раздел с SATA-девайса, и попробуйте удалить
> драйвер контроллера или sd.

Не всегда. Пример. Подымаем интерфейс, монтируем NFS, делаем

rmmod <имя_драйвера_сетевой_карты>

rmmod ни слова не говоря выгружает драйвер (даже если / на NFS). Через
некоторое время вся эта красота заканчивается Oops'ом.

> Сетевой интерфейс под словом "устройство" подразумевает немного другую
> сущность, потому он и позволяет такое сделать.

Я считаю, что это баг. Если интерфейс поднят, то по-хорошему

rmmod <имя_драйвера_сетевой_карты>

должен грязно выругаться и завершиться с ошибкой. А вместо этого происходит
полное непотребство (см. пример с NFS). Думаю, что стоит это уродское
поведение хотя бы задокументировать.

> rmmod ни слова не говоря выгружает драйвер (даже если / на NFS). Через некоторое время вся эта красота заканчивается Oops'ом.

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

И "заканчивается Oops'ом" оно не из-за отрубания интерфейса, а из-за ошибки на рутовой ФС и умирания init'а с перепугу :-)

> должен грязно выругаться и завершиться с ошибкой.

С чего бы вдруг? Ведь в действительности интерфейс действительно никем не юзается: сокеты, как единственные постоянные объекты, живут сами по себе (на уровне tcp), а интерфейс как таковой это лишь линия связи, транспорт - и не более.

> Думаю, что стоит это уродское поведение хотя бы задокументировать.

Документировать может и стоит, но называть его "скотским" я бы не стал :-) Кстати когда-то давно так и было - пока не "завалишь" все соответствующие интерфейсы, драйвер не выгружался, но валить интерфейсы все равно никто не мог запретить - так что какая разница, валят ли интерфейс через ifconfig ... down или путем rmmod?

> > rmmod ни слова не говоря выгружает драйвер (даже если / на NFS).
> > Через некоторое время вся эта красота заканчивается Oops'ом.

> Это фича.

Это в альтернативной ОС такое бл^W поведение сойдет за фичу. А в Linux
такие "фичи" сначала документируют, а потом исправляют. И -- если руки
дотянутся -- бьют морду тому пи^W представителю меньшинств, который эту
"фичу" напейсал.

> какая разница, валят ли интерфейс через ifconfig ... down или путем rmmod?

А какая разница, ФС отмонтировать по umount или rmmod xfs ?

Разница -- огромная. ifconfig eth0 down -- я сам недвусмысленно попросил
попросил прибить интерфейс, и сам отвечаю за последствия. Хотя было бы
неплохо, чтобы ifconfig вел себя как umount: есть открытые соединения -- не
трогать интерфейс, если только не сказали -f (force) или -l (lazy).

> > должен грязно выругаться и завершиться с ошибкой.

> > С чего бы вдруг? Ведь в действительности интерфейс действительно никем не
> > юзается:

++двоемыслие

> > сокеты, как единственные постоянные объекты, живут сами по себе
> > (на уровне tcp),

В том то и дело, что сами по себе они не живут.

> а интерфейс как таковой это лишь линия связи, транспорт -- и не более.

Ага, и отключат интерфейс -- TCP пакеты пойдут с помощью отца, сына и
святаго духа :)

> > сокеты, как единственные постоянные объекты, живут сами по себе (на уровне tcp),

> В том то и дело, что сами по себе они не живут.

Предлагаю вам проверить. Откройте соединение на какой-нибудь хост (например по ssh), затем пристрелите интерфейс (ifconfig eth0 down), потом запустите netstat -na, и посмотрите - умерло ли соединение или нет (подсказка - они живее всех живых). Если поднимите интерфейс снова с тем же адресом - то продолжите работать как ни в чем не бывало. Я так делал много раз (не добровольно, а из-за обрыва связи) - если по соединению нет активности, наличие или отсутствие интерфейса роли не играет.

Если мне не верите - посмотрите inet_sock.h, там есть структура inet_sock. Сокет и соединение живут отдельно от интерфейса, поскольку им пофиг через какой интерфейс пакеты будут уходить.

Наличие IP-адреса на интерфейсе на самом деле лишь дань традиции - вы можете навешать свой IP-адрес на lo с маской /32, и указать маршрут на свою локалку через route add ... dev eth0, при этом eth0 поднять и адреса не задавать - и все равно ваш комп можно будет пинговать и на него можно будет подключаться. То что вам будет подключиться к кому-то еще не так просто - но это прочто вопрос реализации типичного tcp-клиента, где connect() делается без bind()

> Это в альтернативной ОС такое бл^W поведение сойдет за фичу.

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

Это все к тому, что интерфейс в постоянном режиме реально никто не юзает, и наличие счетчика ссылок = 0 у сетевого адаптера вполне законно.

> неплохо, чтобы ifconfig вел себя как umount

Наоборот - очень неплохо было бы, чтобы umount вел себя как ifconfig: при вызове umount все операции I/O бы замораживались, буферы сбрасывались, ФС синкалась и отмонтировалась, а все у кого есть на ней открытые файлы получали бы I/O error.

> ifconfig eth0 down -- я сам недвусмысленно попросил попросил прибить интерфейс

А когда вы драйвер rmmod-ите, вы также недвусмысленно говорите "мне все устройства им обслуживаемые нафиг не нужны". А коли не нужны - какие проблемы? Это как { rm -rf /; } - если вызвали, значит надо.

про сетевые интерфейсы и rmmod

> Предлагаю вам проверить. Откройте соединение на какой-нибудь хост (например
> по ssh), затем пристрелите интерфейс (ifconfig eth0 down), потом запустите
> netstat -na, и посмотрите - умерло ли соединение или нет (подсказка - они
> живее всех живых).

Я знаю, что такой маразм действительно имеет место. Еще хотел узнать -- какой
м^Hчудак это придумал, и по заслугам отблагодарить. ("Мы бы каждый -- кто
чем -- выражал благодарность, / Молотилкой колхозник, рабочий ключом, /
Враг народа -- киркою, протезом -- афганец, / Ну а я б кой-кому засветил
кирпичом.")

> Если поднимите интерфейс снова с тем же адресом - то продолжите работать
> как ни в чем не бывало.

ЕСЛИ. Но подымать его уже некому будет.

> В альтернативной ОС как раз наоборот, сокет жестко завязан на интерфейс, и
> с обрывом связи (например на выделенной линии) все коннекты которые уходили
> с адреса этого интерфейса тут же рубятся,

И правильно сделано.

> в отличие от топика, в котором можно без проблем переконнектиться и работать
> как ни в чем не бывало,

Ага, с разгону.

1. Далеко не всякий протокол, реализованный поверх TCP, так сможет, у него
свое состояние есть. Жизненный пример -- сетевые/распределенные ФС.

2. Часто важно время доставки пакета. TCP, конечно, не дает никаких гарантий,
но как правило пакеты ходят за разумное время. Так что можно делать такие вещи:

# tar xf - /mnt | rsbep | dvbackup --verbose --prefix 120 | \
ssh box-with-dv-camera \
'ionice -c1 dvconnect --send --buffers 512 --device /dev/video1394/0 -- -'

Но если во время этого уронить интерфейс... Толку с того, что якобы "можно
спокойно переконнектиться" -- никакого, уже buffer underrun...

> А когда вы драйвер rmmod-ите, вы также недвусмысленно говорите "мне все
> устройства им обслуживаемые нафиг не нужны".

Это rmmod -f -- "мне не нужен этот драйвер и все устройства". А rmmod должен
выгружать _неиспользуемые_ модули.

В конце концов, почему rmmod raid1 -- ругается, а rmmod tg3 -- нет?

> > неплохо, чтобы ifconfig вел себя как umount

> Наоборот - очень неплохо было бы, чтобы umount вел себя как ifconfig:
> при вызове umount все операции I/O бы замораживались, буферы сбрасывались,
> ФС синкалась и отмонтировалась, а все у кого есть на ней открытые файлы
> получали бы I/O error.


Где гарантия что данные будут в непротиворечивом состоянии? Например,

$ tar xf /mnt/backup.tar.gz -C ~ . &
# umount /mnt

Если umount (не приведи Великие Боги) будет себя так вести, получится
вместо backup'а хлам.

Вам не нужны Ваши данные? Есть гораздо более простой способ от них
избавиться (rm -rf).

> Если мне не верите - посмотрите inet_sock.h, там есть структура inet_sock.
> Сокет и соединение живут отдельно от интерфейса,

Design error.

> поскольку им пофиг через какой интерфейс пакеты будут уходить.

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

> Где гарантия что данные будут в непротиворечивом состоянии? Например,

> $ tar xf /mnt/backup.tar.gz -C ~ . &

> # umount /mnt

> Если umount (не приведи Великие Боги) будет себя так вести, получится вместо backup'а хлам.

А вот фиг. Все будет в порядке - кроме того файла который в это время перезаписывался. Я ведь уже приводил последовательность - сначала заморозка записи, потом сброс буферов, потом отмонтирование и разморозка с I/O error, и это ничем не отличается от той ситуации как если бы вы нажали tar'у Ctrl+C или сделали killall tar.

> > поскольку им пофиг через какой интерфейс пакеты будут уходить.

> Нет, не пофиг.

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

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

Как раз пофиг. Получили no route to host? Ну и что. Просто повторяем
попытку - ибо на самом деле эта ошибка могла прийти и с удаленного
маршрутизатора с той же вероятностью, с какой была сгенерирована
вашим хостом, и это никакая не катастрофа вселенского масштаба.

[root@host]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.23.2.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.255.0   0.0.0.0         255.255.255.0   U     0      0        0 vmnet1
0.0.0.0         172.23.2.6      0.0.0.0         UG    0      0        0 eth0
[root@host]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:18:71:80:26:DF  
          inet6 addr: fe80::218:71ff:fe80:26df/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:974 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:106111 (103.6 KiB)  TX bytes:10801 (10.5 KiB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8556 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8556 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:57420780 (54.7 MiB)  TX bytes:57420780 (54.7 MiB)

lo:1      Link encap:Local Loopback  
          inet addr:172.23.2.114  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

vmnet1    Link encap:Ethernet  HWaddr 00:50:56:C0:00:01  
          inet addr:192.168.255.1  Bcast:192.168.255.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:391196 errors:0 dropped:0 overruns:0 frame:0
          TX packets:402783 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[root@host]# telnet 172.23.2.5 25
Trying 172.23.2.5...
Connected to 172.23.2.5.
Escape character is '^]'.
220 ***.**.** ESMTP Sendmail 
^]quit
telnet> quit
Connection closed.
[root@host]#

Это блин не чудо и не баг - это НОРМАЛЬНОЕ поведение нормального
IP-стека. Ему как раз пофиг на количество и наличие интерфейсов,
отличать бы только свои пакеты от чужих (то есть знать свои IP-адреса).

> Но если во время этого уронить интерфейс... Толку с того, что якобы "можно спокойно переконнектиться" -- никакого, уже buffer underrun...

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

> И правильно сделано [в контексте про оффтопик]

Писсееец... А как же вы тогда сможете например заменить сетевую карту без остановки работы сервера???

Прочитал несколько страниц. Пока немного замечаний. Первое, все-таки следует расшифровывать сокращения хотя бы при первом их употреблении. Иначе на офлайновую книгу не потянет вообще, приходится лезть в google. Далее, в графе о модулях, если упомянул утилиты работы с ними, то дай примеры использования на реальной задаче. Так глядишь, и на книгу насобираешь;-) В графе про организацию памяти я не понял, как это "из них первый гигабайт резервируется для себя ядром", если в системе всего, скажем, 128 мегабайт? Imho, следует писать попроще, как если пишешь для первокла...курсников. В целом, нормально, можно улучшить за счет детализации (почувствуй себя Львом Николаевичем) и переписывания некоторых тёмных мест.

> А как же вы тогда сможете например заменить сетевую карту без остановки
> работы сервера???

ifconfig ... down -- это УЖЕ остановка сервера.

> Вы что, всерьез уверены что пакеты имеют право уходить только
> через тот интерфейс, на чей IP-адрес был повешен порождающий
> эти пакеты сокет?!

Нет. Но не через всякий интерфейс есть маршрут к хосту назначения. Например,
через lo пакеты точно далеко не уйдут.

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

> Как раз пофиг.

Ни разу.

$ ssh root@natbox
[Вырубаем все интерфейсы]
# ifconfig eth0 down; ifconfig eth1 down

> Получили no route to host? Ну и что. Просто повторяем попытку

Все, приплыли! Повторять попытку уже НЕКОМУ. Остается надеяться,
что heartbeat таки перезапустит машину.

> Ему как раз пофиг на количество и наличие интерфейсов,
^^^^^^^
Осталось только решить -- таки как передавать пакеты? С помощью Силы
или святого духа?

> А вот фиг. Все будет в порядке - кроме того файла который в это время
> перезаписывался.

А этого уже достаточно. Между файлами есть соотношения, знаете ли. Пример:
если хотя бы один файл в ~/src/foo/.git/objects/??/ испорчен -- то все,
трындец коту Ваське.

> Наоборот - очень неплохо было бы, чтобы umount вел себя как ifconfig:

Прежде чем покушаться на POSIX семантику ФС, попробуйте поработать с
какой-нибудь существующей не-POSIX (или не совсем POSIX) ФС -- NFS
(особенно soft mount), AFS, Coda, etc. Подобные желания быстро пропадут.

> ifconfig ... down -- это УЖЕ остановка сервера.

Сейчас в десктопах часто уже по два интерфейса. down одному, up другому - вполне нормально.

> $ ssh root@natbox

> [Вырубаем все интерфейсы]

> # ifconfig eth0 down; ifconfig eth1 down

> Повторять попытку уже НЕКОМУ.

Терпеть не могу Sun-ch'а, но таки напомню про дверь, яйца и прищемить.

> Но не через всякий интерфейс есть маршрут к хосту назначения. Например, через lo пакеты точно далеко не уйдут.

А это никого не волнует. Есть таблица маршрутизации, в соответствии с которой пакет и будет (должен быть) отправлен. И будет ли этим интерфейсом lo, vmnet, eth, ppp, tun, slip, hren и что там еще - это уже никому не интересно.

> Осталось только решить -- таки как передавать пакеты?

А не сокетовое это собачье дело - решать как пакеты передовать. Пусть хоть на дискеты записывать и на другой комп носить - но это не его, сокета, дело.

> Между файлами есть соотношения, знаете ли

Ну и что? Давайте тогда еще запретим tar'у прерываться по Ctrl+C,запретим кнопку reset, провода подачи питания приклеим к разъемам суперклеем, кнопку закрытия окна терминала запретим, /bin/kill удалим, удалим из таблицы сигналов SIGKILL и SIGTERM...

А что - это ведь все может обломать работу tar -xf !!! Это же нельзя делать!!!

> попробуйте поработать с какой-нибудь существующей не-POSIX (или не совсем POSIX) ФС -- NFS (особенно soft mount)

Всегда монтировал на рабочие станции ресурсы с NFS-серверов в soft-режиме. И по-прежнему хочу иметь возможность отмонтировать ФС тогда когда сочту нужным. Потому как если я как администратор решил, что эта ФС уже не нужна и подлежит отмонтированию - это значит она не нужна и подлежит отмонтированию.

Артем, получилось здорово.

Доработать (там редакторы, корректоры) и можно (нужно!) издавать в качестве Pocket Handbook, учебного пособия или чего-нить в этом роде.

Так что я скажу японски: оцень колосо, оцень колосо! :)

Это как афроамериканец :)