Re: [devel] unmount procedure

Re: [devel] unmount procedure

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Wed, Apr 27, 2005 at 01:06:34PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> >
> >Может, так лучше:
> >1. размонтируем все tmpfs, которые не /dev;
> >2. деактивируем все swap;
> >3. размонтируем все FS в обычном порядке.
> > 
> Да, именно так.
> Только надо проверить, не сломает ли это livecd, где на tmpfs лежат r/w 
> branch'и unionfs'а.

Хм, производные файловые системы типа unionfs надо пытаться размонтировать
ещё раньше.

Похоже, задача медленно но верно превращается в обход дерева.
Вот только связи не всегда очевидны, и не всегда отражены в /proc/mounts.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] unmount procedure

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

* Dmitry V. Levin <ldv@> [050427 13:23]:
> Похоже, задача медленно но верно превращается в обход дерева.
> Вот только связи не всегда очевидны, и не всегда отражены в /proc/mounts.
Похожая задача решена в etcnet для включения/выключения
интерфейсов.

-- 
Regards, Sir Raorn.
-------------------
> > Я забыл включить в build requires новые kernel-build-tools.
> > Sorry.
> Петр! А комментарии последуют? Или kernel-doc, и вперед? Чем
Вы шутите?  Какие комментарии 24 мая?  Раньше понедельника, думаю, ждать
не стоит.
		-- ldv in sisyphus@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] unmount procedure

[Anton Farygin]

Dmitry V. Levin wrote:

>On Wed, Apr 27, 2005 at 01:06:34PM +0400, Anton Farygin wrote:
>  
>
>>Dmitry V. Levin wrote:
>>    
>>
>>>Может, так лучше:
>>>1. размонтируем все tmpfs, которые не /dev;
>>>2. деактивируем все swap;
>>>3. размонтируем все FS в обычном порядке.
>>>
>>>      
>>>
>>Да, именно так.
>>Только надо проверить, не сломает ли это livecd, где на tmpfs лежат r/w 
>>branch'и unionfs'а.
>>    
>>
>
>Хм, производные файловые системы типа unionfs надо пытаться размонтировать
>ещё раньше.
>
>Похоже, задача медленно но верно превращается в обход дерева.
>Вот только связи не всегда очевидны, и не всегда отражены в /proc/mounts.
>  
>
unionfs может быть точно не отражен.

На самом деле для unionfs не составляет проблем потеря данных в одном из 
брэнчей. Так что здесь не должно ничего страшного возникнуть.

Rgds,
Rider

[devel] Re: unmount procedure

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Wed, Apr 27, 2005 at 02:28:35PM +0400, Alexey I. Froloff wrote:
> > Похоже, задача медленно но верно превращается в обход дерева.
> > Вот только связи не всегда очевидны, и не всегда отражены в
> > /proc/mounts.
> Похожая задача решена в etcnet для включения/выключения
> интерфейсов.

Это libdep.sh напрашивается.  Ещё в управление сервисами... хотя
бы на уровне допиливания текущей схемы, вроде в SuSE видел хаки в
эту сторону.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: unmount procedure

[Денис Смирнов]

On Wed, Apr 27, 2005 at 02:22:12PM +0300, Michael Shigorin wrote:

MS> Это libdep.sh напрашивается.  Ещё в управление сервисами... хотя
MS> бы на уровне допиливания текущей схемы, вроде в SuSE видел хаки в
MS> эту сторону.

Была гениальнейшая идея -- сделать это на основе make :) Он и
многопоточность поддерживает, и дерево сам развернёт. 

-- 
С уважением, Денис

http://freesource.info

Re: [devel] Re: unmount procedure

[Alexey Rusakov]

On 27.04.2005 19:22, Денис Смирнов wrote:
> On Wed, Apr 27, 2005 at 02:22:12PM +0300, Michael Shigorin wrote:
> 
> MS> Это libdep.sh напрашивается.  Ещё в управление сервисами... хотя
> MS> бы на уровне допиливания текущей схемы, вроде в SuSE видел хаки в
> MS> эту сторону.
> 
> Была гениальнейшая идея -- сделать это на основе make :) Он и
> многопоточность поддерживает, и дерево сам развернёт. 
Издеваетесь? Вы ещё ant предложите. XML и всё такое, Морозову понравится :)

-- 
   Alexey "Ktirf" Rusakov

Re: [devel] Re: unmount procedure

[Денис Смирнов]

On Wed, Apr 27, 2005 at 07:26:01PM +0400, Alexey Rusakov wrote:

>>Была гениальнейшая идея -- сделать это на основе make :) Он и
>>многопоточность поддерживает, и дерево сам развернёт. 
AR> Издеваетесь? Вы ещё ant предложите. XML и всё такое, Морозову понравится :)

Бр-р-р-р-р. Не надо меня ТАК пугать. Пожалуйста :)

-- 
С уважением, Денис

http://freesource.info

Re: [devel] Re: unmount procedure

[Alexey Rusakov]

On 27.04.2005 21:21, Денис Смирнов wrote:
> On Wed, Apr 27, 2005 at 07:26:01PM +0400, Alexey Rusakov wrote:
> 
>>>Была гениальнейшая идея -- сделать это на основе make :) Он и
>>>многопоточность поддерживает, и дерево сам развернёт. 
> AR> Издеваетесь? Вы ещё ant предложите. XML и всё такое, Морозову понравится :)
> 
> Бр-р-р-р-р. Не надо меня ТАК пугать. Пожалуйста :)
А что, make сильно лучше? Его придётся перетаскивать в /bin, 
просматривать на предмет надёжной работы от рута. Я уже не говорю о том, 
что он до сих пор ухитряется по-глупому ломаться силами апстрима.

-- 
   Alexey "Ktirf" Rusakov

Re: [devel] Re: unmount procedure

[Alexey Rusakov]

Sviataslau Svirydau wrote:

>Michael Shigorin wrote:
>  
>
>>On Wed, Apr 27, 2005 at 02:28:35PM +0400, Alexey I. Froloff wrote:
>>
>>    
>>
>>>>Похоже, задача медленно но верно превращается в обход дерева.
>>>>Вот только связи не всегда очевидны, и не всегда отражены в
>>>>/proc/mounts.
>>>>        
>>>>
>>>Похожая задача решена в etcnet для включения/выключения
>>>интерфейсов.
>>>      
>>>
>>Это libdep.sh напрашивается.  Ещё в управление сервисами... хотя
>>бы на уровне допиливания текущей схемы, вроде в SuSE видел хаки в
>>эту сторону.
>>    
>>
>
>А как можно это сделать на уровне допиливания текущей схемы?
>
>В SuSE это не то, чтобы хаки, а вполне работающее нормальное решение со 
>своими тараканами :)
>[...skipped...]
>Вот... в общем, идея неплохая там... удобная...
>  
>
Там идея очень серьёзно опирается на существование чУдной вещи под 
названием SuSEconfig. Собственно, из этого вытекает очень многое. В 
частности, наличие файлов .local специально для того, чтобы можно было 
что-то делать ручками, а не через YaST. В принципе, это не так уж плохо.
В общем, при наличии некоего всеобщего скрипта ("to rule them all") с 
соответствующей инфраструктурой можно и сервисы перенумеровать, и 
зависимости между сервисами контролировать, и за правами критических 
файлов следить... Одна беда - нет у нас (пока?) такой инфраструктуры.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Re: unmount procedure

[Sviataslau Svirydau]

Michael Shigorin wrote:
> On Wed, Apr 27, 2005 at 02:28:35PM +0400, Alexey I. Froloff wrote:
> 
>>>Похоже, задача медленно но верно превращается в обход дерева.
>>>Вот только связи не всегда очевидны, и не всегда отражены в
>>>/proc/mounts.
>>
>>Похожая задача решена в etcnet для включения/выключения
>>интерфейсов.
> 
> 
> Это libdep.sh напрашивается.  Ещё в управление сервисами... хотя
> бы на уровне допиливания текущей схемы, вроде в SuSE видел хаки в
> эту сторону.

А как можно это сделать на уровне допиливания текущей схемы?

В SuSE это не то, чтобы хаки, а вполне работающее нормальное решение со 
своими тараканами :)
Суть в том, что сервис содержит в себе описание о своих зависимостях, 
вот пример:

### BEGIN INIT INFO
# Provides: myservice
# Required-Start: $network $remote_fs otherd +anotherd
# X-UnitedLinux-Should-Start: ypbind hwscan $syslog $named
# Required-Stop: $network $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start my super-service
### END INIT INFO

На основе такой информации строятся ссылки в /etc/rcX.d/, причем там нет 
разброса от 00 до 99, а занимаются последовательные номера от 00 (или 
01, не помню), и используется столько номеров, сколько потребуется... то 
есть, может дойти до 16-18, например. Ессесна, что в зависимости от 
конфигурации у одного и того же сервиса може быть разный стартовый номер...

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

Кстати, фича с зависимостями используется у SuSE в SCPM - если при смене 
   профайла меняется конфигурация сервиса, то будет перестартован этот 
сервис и все, которые от него зависят. В правильном порядке, ессесна.

Теперь о тараканах... по кр.мере в 8.1/9.0/9.1 был такой баг, что если в 
/etc/init.d/ сделать (резервную) копию стартскрипта с целью покорежить 
оригинал, что у системы управления сервисами сносило башню, поскольку 
было 2 сервиса, которые провайдят одно и то же.

Вот... в общем, идея неплохая там... удобная...

-- 
Best Regards,
Sviatoslav Sviridov <Sviataslau_Svirydau at epam.com>
phone:  +375 (17) 210 1662, ext. 1503
fax:    +375 (17) 210 1168
mobile: +375 (29) 641 4214
-- 
Memory fault - where am I?