On Tue, Aug 15, 2006 at 01:22:39PM +0300, Valentin Nechayev wrote:
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') берётся весь объект целиком. А что это значит в практическом применении?
Ну то и значит:) Как ещё ответить на этот вопрос?
Не понятно :) На практике выходит что использование /dev/md0c не эквивалентно использованию /dev/md0, значит это либо бага, либо фича :) Если бага, надо send-pr, если фича - надо найти этому объяснение :) Какие есть декларируемые рекомендации и легальные действия над девайсами /dev/*c ?
Кто и как использует раздел c?
Сейчас он используется наравне с устройством всего делимого disklabel'ом объекта (то есть /dev/ad0s1 и /dev/ad0s1c всегда одно и то же если оба существуют). Но ещё в 4ке были свои особенности для compatibility slice - /dev/ad0c был не равен /dev/ad0, а был вместо этого равен /dev/ad0s1c или разделу 'c' другого слайса который определен как 2.0-compatible. А ещё раньше это был единственный путь адресоваться ко всему диску ( можно считать что /dev/ad0 не было).
То есть сейчас смысл 'c' - совместимость со старыми багами;) Отдельного собственного смысла у него нет.
Понятно. А в чем заключается "непредназначенность" раздела "c" для рядовых операций типа newfs, mount, etc ?
Вряд ли. Сокращение 'a' по сравнению с 'c' на 16 секторов - стандартное поведение bsdlabel при выставлении начальной метки. Но ведь Паша не к /dev/md0a обращается, а к /dev/md0c... Ну может дело в недоработке этого особенного treatment раздела c... К его неадекватному использованию. Он не предназначен для оформления подразделов в нём.
В нашем случае подразделы в нем не создавались. На нем делалась файловая система.
- раздел 'c' принципиально не предназначен (и никогда не был) для монтирования чего-либо под ним или разделения его на части. Он предназначен исключительно для доступа к полному содержимому того контейнера в котором данный disklabel. а для чего он предназначен? и если не предназначен для монтирования, почему никто не ругается на, например, newfs *c ?
Видимо, потому, что никто не счёл нужным проверять не стреляет ли админ себе в ногу. У админа с рутом это далеко не единственный путь всё испортить.
хорошо. пусть разрешается стрелять в ногу. но хорошо бы если бы у админа была возможность знать что он делает, знать какой будет эффект, знать что это действие влечет наличие дырки в ноге. вот я хочу знать что это за зверь - раздел "с" и с чем его едят. а подход "не знаешь - не трогай" тоже не годится, так как в перспективе выливается в ситуацию, когда ОС может всего много, но реально используется из этого мало, так как остальное фиг его знает как работает.
См. выше. Если админу вообще ничего не позволять он не сможет работать, а если хоть немного отпустить то всегда найдётся способ убить систему.
критерием здесь является потенциальная известность последствий. команда "rm -rf /" на send-pr не тянет, так как известно что будет. команда "kldload somemod.ko", приводящая систему к панике - на send-pr тянет, если в man somemod не сказано, что задуманная функция этого модуля - паниковать систему. хотя в обоих случаях, казалось бы, админ сам убивает/вешает систему. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message