Tue, Aug 15, 2006 at 11:54:59, spell wrote about "[uanog] Re: AAAA... kernel: g_vfs_done():md0c.bde[WRITE(offset=610686730":
Вобще конечно лучше начать с понимания что есть "c" в терминах bsdlabel-а. Кто знает эту тайну, поделитесь знанием или докой :) А то кроме "c has special meaning and relates to entire disk" ничего не попадается :)
Именно это и значит: 'c' означает всё то пространство (ранее - только диск, сейчас может быть слайс, раздел GPT или вообще произвольный объект geom'а, например, софтовое зеркало) на котором заведен данный disklabel. В ядре сделана жёсткая связь что при индексе раздела 2 (соответствующем букве 'c') берётся весь объект целиком. При этом понимание немного отличается для <=4 и >=5: при GEOM'е (начиная с 5ки) создание буквенных разделов происходит только если действительно найден disklabel, а в 4ке для ряда объектов (сидюки, memory devices) были насильственно введены имеющие один и тот же смысл 'a' и 'c', а кроме того - так называемый compatibility slice (полностью - FreeBSD 2.0 compatibility slice), соответствующий тому слайсу который загрузчик счёл бы загрузочным; но начиная с 5ки его тоже нет.
А то что "a" имеет отличный от "c" размер, когда весь диск отдан под один partition ("a"), наводит на мысль, и может отсюда и растет ситуация с записью за пределы диска.
Вряд ли. Сокращение 'a' по сравнению с 'c' на 16 секторов - стандартное поведение bsdlabel при выставлении начальной метки. Но ведь Паша не к /dev/md0a обращается, а к /dev/md0c...
В любом случае, мне кажется, это мясо для send-pr.
Я думаю что его никто не примет по следующим причинам: - раздел 'c' принципиально не предназначен (и никогда не был) для монтирования чего-либо под ним или разделения его на части. Он предназначен исключительно для доступа к полному содержимому того контейнера в котором данный disklabel. - ситуация тривиально исправляется устранением использования 'c' и перехода напрямую к внешнему контейнеру (в обсуждаемом случае получится /dev/md0.bde)
"а шо тэпэр робити?...". Не иначе как backup&restore... похоже на то...
Собственно а зачем? /dev/md0c совпадал с /dev/md0. Если просто убрать disklabel то всей разницы будет несоздание /dev/md0a и /dev/md0c, а данные будут по тому же пути и никуда не денутся. Я не знаю как BDE находит свои описатели, но вполне вероятно что оно их найдёт в /dev/md0 и полетит дальше как ни в чём ни бывало:)) -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message