Re: сдетела геометрия диска :-(

2003-09-29 Пенетрантность Dimitry N. Naldaev
В сообщении от 27 Сентябрь 2003 09:28 Alexandra N. Kossovsky написал:
 On Fri, Sep 26, 2003 at 06:00:57PM +0400, Artem Chuprina wrote:
  DNN ЗЫЫ по поводу fdisk'а если я правлю таблицу разделов, в которой хотя
  бы DNN один раздел примантирован, то мне нужно перегружать машину, чтобы
  ядро DNN синхронезировалось с таблицей разделов :-/ раньше такого
  ограничения DNN небыло, но когда оно появилось я точно сказать не могу
  поскольку с DNN таблицами разделов приходится иметь дело достаточно
  редко... DNN соответственно по пораметру хочу перегрузиться линукс
  неуклонно DNN движется в сторону совместимости с виндой что на мой
  взгляд в корне DNN неправильно...
 
  Сколько помню работу IDE в линуксах - всегда так было.

 Это - да.
Не правда ваша в ядрах 1.х  ядро нормально перечитывало таблицу разделов и не 
требовало перезагрузки. про ядра 2.0 и 2.2 уже не помню но на каких-то из 
этих ядер тоже не нужно было перегружаться

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

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

 Дело в том, что (в нынешней реализации соответствующего куска linux
 kernel) обновить можно только _всю_ таблицу разделов. Если при этом
 границы смонтированных разделов двигали, то некоторые куски кода будут
 продолжать думать, что у смонтированных разделов прежняя геометрия,
 а другие куски кода уже будут знать про новую геометрию. Что может
 привести к задумчивым эффектам. 
это да и скорее всего текущее ограниченние просто напросто защита от дураков. 
хотя большой погоды это не делает, поскольку размер fs ядро берет не из 
таблицы разделов а из суперблока fs и если он отличается... я тут совсем 
недавно влетел в такую ситуацию:
- на разделе hda6 была ext3
- #umount /dev/hda6
- #fdisk /dev/hda
- удаляем раздел /dev/hda6
- на его месте создаем разделы hda6 и hda7
- прсим fdisk записать новую таблицу разделов на диск, fdisk записывает ее но 
говорит, что чтобы синхронизировать ее с ядром небобходима перезагрузка (!)
- перегружаю комп :-(
- после перегрузки ядро находит /dev/hda6 в fstab (ну забыл я поправить этот 
файлик пред тем как сказать reboot) и... монтирует его  при этом оно 
скромно возмущается что размер партиции и размер fs, указанный в суперблоке, 
не совпадают... при этом оно естественно использует информацию из 
суперблока...  
-- Занавес!
вобщем какой смысл был перегружать комп, если в результате у меня 
подмонтированная партиция не совпадает с тем что написано в таблице разделов 
:-/ 
кстати вообще прикольно получится если поменять размер подмонтированной 
партиции: при перегрузке, когда ядро скажет этой fs sync перед тем как ее 
окончательно размонтировать вполне может слететь таблица для logical 
разделов!!!

 А никакой ре-инициализации ide (или scsi)
 девайса при перечитывании таблицы разделов не происходит.

 Я не пытаюсь сказать, что невозможно написать код так, чтобы
 перечитывание таблицы разделов было возможно при смонтированных
 разделах. Но это непросто и, видимо, никому не нужно. Особенно никому не
 нужно ловить блох, которые появятся при таком переписывании.

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

PS а что делать с геомертий (см начало треда) никто так и не сказал :-(
а без lilo вообще-то фигово 




Re[2]: сдетела геометрия диска :-(

2003-09-27 Пенетрантность Igor Suvorov

DAE да, все правильно, так всегда было. На ура проходит переразбивка диска
DAE который не используется. 
DAE Что бы ядро перечитало таблицу разделов нужно освободить /, по горячему
DAE можно только если использовать pivot_root(8), но это сильно геморно,
DAE лучше перезагрузиться, хотя это не сильно радостно...
DAE Вот такие вот они IDE...

А что, scsi лучше?

[ns, root][/etc/mail]# fdisk /dev/sdc

Command (m for help): p

Disk /dev/sdc: 133 heads, 62 sectors, 1016 cylinders
Units = cylinders of 8246 * 512 bytes

   Device BootStart   EndBlocks   Id  System
/dev/sdc1 1   125515344   83  Linux
/dev/sdc2   126  1016   3673593   83  Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or 
resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
[ns, root][/etc/mail]# 

--
Igor



сдетела геометрия диска :-(

2003-09-26 Пенетрантность Dimitry N. Naldaev
Привет всем

Поставил новое ядро 2.4.22 взамен 2.4.18 а оно по другому определяет геометрию 
диска (?!) соответственно fdisk ругаеться что у меня париции начинаются не с 
начала целиндра, (при старой геометрии на старом ядре они начинались с начала 
целиндра, но теперь целиндров стало меньше :-/ ) lilo тоже ругается и... 
отказывается ставить какое либо ядро вообще !!!  благо 2.4.18 переехало в 
разряд old и теперь чтобы поставить новую версию ядра мне нужно перегрузить 
машину со старым ядром и только после этого я могу сказать lilo, что очень не 
удобно

как это можно пофиксить ??? пробовал высталюять геометрию ручками в командной 
строке ядра при запуске --- не помогает :-/

ЗЫ переразбивать диск в соответствии с новой геометриеий не реально !!!

ЗЫЫ по поводу fdisk'а если я правлю таблицу разделов, в которой хотя бы один 
раздел примантирован, то мне нужно перегружать машину, чтобы ядро 
синхронезировалось с таблицей разделов :-/ раньше такого ограничения небыло, 
но когда оно появилось я точно сказать не могу поскольку с таблицами разделов 
приходится иметь дело достаточно редко... соответственно по пораметру хочу 
перегрузиться линукс неуклонно движется в сторону совместимости с виндой
что на мой взгляд в корне неправильно...

Dimitry



Re: сдетела геометрия диска :-(

2003-09-26 Пенетрантность Artem Chuprina
Хмутро.

DNN ЗЫЫ по поводу fdisk'а если я правлю таблицу разделов, в которой хотя бы
DNN один раздел примантирован, то мне нужно перегружать машину, чтобы ядро
DNN синхронезировалось с таблицей разделов :-/ раньше такого ограничения
DNN небыло, но когда оно появилось я точно сказать не могу поскольку с
DNN таблицами разделов приходится иметь дело достаточно редко...
DNN соответственно по пораметру хочу перегрузиться линукс неуклонно
DNN движется в сторону совместимости с виндой что на мой взгляд в корне
DNN неправильно...

Сколько помню работу IDE в линуксах - всегда так было. Это ограничение шины,
кажется - для того, чтобы перечитать таблицу разделов, надо
проинициализировать устройство. А переинициализировать устройство, с которого
что-то смонтировано...

-- 
Artem Chuprina
RFC2822: [EMAIL PROTECTED], FIDO: 2:5020/122.256, ICQ: 13038757



Re: сдетела геометрия диска :-(

2003-09-26 Пенетрантность Alexandra N. Kossovsky
On Fri, Sep 26, 2003 at 06:00:57PM +0400, Artem Chuprina wrote:
 DNN ЗЫЫ по поводу fdisk'а если я правлю таблицу разделов, в которой хотя бы
 DNN один раздел примантирован, то мне нужно перегружать машину, чтобы ядро
 DNN синхронезировалось с таблицей разделов :-/ раньше такого ограничения
 DNN небыло, но когда оно появилось я точно сказать не могу поскольку с
 DNN таблицами разделов приходится иметь дело достаточно редко...
 DNN соответственно по пораметру хочу перегрузиться линукс неуклонно
 DNN движется в сторону совместимости с виндой что на мой взгляд в корне
 DNN неправильно...
 
 Сколько помню работу IDE в линуксах - всегда так было. 

Это - да.

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

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

Дело в том, что (в нынешней реализации соответствующего куска linux
kernel) обновить можно только _всю_ таблицу разделов. Если при этом
границы смонтированных разделов двигали, то некоторые куски кода будут
продолжать думать, что у смонтированных разделов прежняя геометрия,
а другие куски кода уже будут знать про новую геометрию. Что может
привести к задумчивым эффектам. А никакой ре-инициализации ide (или scsi) 
девайса при перечитывании таблицы разделов не происходит.

Я не пытаюсь сказать, что невозможно написать код так, чтобы
перечитывание таблицы разделов было возможно при смонтированных
разделах. Но это непросто и, видимо, никому не нужно. Особенно никому не
нужно ловить блох, которые появятся при таком переписывании.

-- 
Regards,
Sasha.
OKTET Ltd. (http://www.oktet.ru/)
e-mail: [EMAIL PROTECTED] (work) or [EMAIL PROTECTED] (home)



Re: сдетела геометрия диска :-(

2003-09-26 Пенетрантность Denis A. Egorov
Здравствуйте, Artem Chuprina!

да, все правильно, так всегда было. На ура проходит переразбивка диска
который не используется. 
Что бы ядро перечитало таблицу разделов нужно освободить /, по горячему
можно только если использовать pivot_root(8), но это сильно геморно,
лучше перезагрузиться, хотя это не сильно радостно...
Вот такие вот они IDE...

On Fri, Sep 26, 2003 at 06:00:57PM +0400, you wrote:

- Хмутро.
- 
- DNN ЗЫЫ по поводу fdisk'а если я правлю таблицу разделов, в которой хотя бы
- DNN один раздел примантирован, то мне нужно перегружать машину, чтобы ядро
- DNN синхронезировалось с таблицей разделов :-/ раньше такого ограничения
- DNN небыло, но когда оно появилось я точно сказать не могу поскольку с
- DNN таблицами разделов приходится иметь дело достаточно редко...
- DNN соответственно по пораметру хочу перегрузиться линукс неуклонно
- DNN движется в сторону совместимости с виндой что на мой взгляд в корне
- DNN неправильно...
- 
- Сколько помню работу IDE в линуксах - всегда так было. Это ограничение шины,
- кажется - для того, чтобы перечитать таблицу разделов, надо
- проинициализировать устройство. А переинициализировать устройство, с которого
- что-то смонтировано...
- 

-- 
Denis A. Egorov