Tue, Aug 15, 2006 at 13:09:50, spell wrote about "Re: [uanog] Re: AAAA... kernel: g_vfs_done():md0c.bde[WRITE(offset=610686730":
Именно это и значит: 'c' означает всё то пространство (ранее - только диск, сейчас может быть слайс, раздел GPT или вообще произвольный объект geom'а, например, софтовое зеркало) на котором заведен данный disklabel. В ядре сделана жёсткая связь что при индексе раздела 2 (соответствующем букве 'c') берётся весь объект целиком. А что это значит в практическом применении?
Ну то и значит:) Как ещё ответить на этот вопрос?
Кто и как использует раздел c?
Сейчас он используется наравне с устройством всего делимого disklabel'ом объекта (то есть /dev/ad0s1 и /dev/ad0s1c всегда одно и то же если оба существуют). Но ещё в 4ке были свои особенности для compatibility slice - /dev/ad0c был не равен /dev/ad0, а был вместо этого равен /dev/ad0s1c или разделу 'c' другого слайса который определен как 2.0-compatible. А ещё раньше это был единственный путь адресоваться ко всему диску ( можно считать что /dev/ad0 не было). То есть сейчас смысл 'c' - совместимость со старыми багами;) Отдельного собственного смысла у него нет.
Вряд ли. Сокращение 'a' по сравнению с 'c' на 16 секторов - стандартное поведение bsdlabel при выставлении начальной метки. Но ведь Паша не к /dev/md0a обращается, а к /dev/md0c... Ну может дело в недоработке этого особенного treatment раздела c... К его неадекватному использованию. Он не предназначен для оформления подразделов в нём. А зачем нужно это смещение в 16 секторов?
Затем что первые 16 секторов отведены под disklabel и загрузчики. Собственные типы разделов (UFS, swap, CCD) всегда пропускают начало своего раздела под disklabel и загрузчики, но для других видов разделов гарантировать это нельзя. Поэтому по новой идеологии лучше всегда пропускать 8K, чем иметь потом возможные проблемы с тем что драйвер FS запорет загрузчик.
Я думаю что его никто не примет по следующим причинам:
- раздел 'c' принципиально не предназначен (и никогда не был) для монтирования чего-либо под ним или разделения его на части. Он предназначен исключительно для доступа к полному содержимому того контейнера в котором данный disklabel.
а для чего он предназначен? и если не предназначен для монтирования, почему никто не ругается на, например, newfs *c ?
Видимо, потому, что никто не счёл нужным проверять не стреляет ли админ себе в ногу. У админа с рутом это далеко не единственный путь всё испортить.
- ситуация тривиально исправляется устранением использования 'c' и перехода напрямую к внешнему контейнеру (в обсуждаемом случае получится /dev/md0.bde) да, но.. это вопрос устойчивости и юзабилити.. все таки лучше бы сразу отсекались попытки сделать что-то непредусмотренное, чем позволялись с тем чтобы потом система неспешно ругалась непонятными словами с непонятными последствиями (т.к. не понятно, в момент этого сообщения об ошибке, чем все таки заканчивается запись на диск - успехом или неуспехом).
См. выше. Если админу вообще ничего не позволять он не сможет работать, а если хоть немного отпустить то всегда найдётся способ убить систему.
"а шо тэпэр робити?...". Не иначе как backup&restore... похоже на то...
Собственно а зачем? /dev/md0c совпадал с /dev/md0. Если просто убрать disklabel то всей разницы будет несоздание /dev/md0a и /dev/md0c, а данные будут по тому же пути и никуда не денутся. Я не знаю как BDE находит свои описатели, но вполне вероятно что оно их найдёт в /dev/md0 и полетит дальше как ни в чём ни бывало:))
действительно :)
достаточно сделать
umount /dev/md0c.bde gbde detach /dev/md0c gbde attach /dev/md0 mount /dev/md0.bde ...
Во-во. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message