AAAA... kernel: g_vfs_done():md0c.bde[WRITE(offset=610686730
FreeBSD 6.1-STABLE #0: Wed Jun 7 13:39:20 EDT 2006 Вас ист дас? kernel: g_vfs_done():md0c.bde[WRITE(offset=61068673024, length=131072)]error = 1 И доолго оно повторяется. Ну, наверно чуть ли не от начала
df /dev/md0c.bde 59802908 32037712 22980964 58% /jails Вот такое файло с md0c: -rw-r--r-- 1 root wheel 62468915200 Aug 10 04:11 jfile делалось вот так: mdconfig -a -t vnode -f jfile -u 0 bsdlabel -w md0 auto gbde init /dev/md0c -i -L /etc/md0c gbde attach /dev/md0c -l /etc/md0c newfs -b 32768 -f 4096 /dev/md0c.bde mount -o async,noatime /dev/md0c.bde /jails
И что делать ? Или где я был неправ? -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Aug 10, 2006 at 11:54:02AM +0300, Paul Arakelyan wrote:
FreeBSD 6.1-STABLE #0: Wed Jun 7 13:39:20 EDT 2006 Вас ист дас? kernel: g_vfs_done():md0c.bde[WRITE(offset=61068673024, length=131072)]error = 1 И доолго оно повторяется. Ну, наверно чуть ли не от начала
А от чего зависит появление этих мессаг? Как влияет на работу файловой системы? вот кто выводит их: if (bip->bio_error) { printf("g_vfs_done():"); g_print_bio(bip); printf("error = %d\n", bip->bio_error); } значит где-то ошибка I/O.. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Aug 10, 2006 at 11:54:02AM +0300, Paul Arakelyan wrote:
FreeBSD 6.1-STABLE #0: Wed Jun 7 13:39:20 EDT 2006 Вас ист дас? kernel: g_vfs_done():md0c.bde[WRITE(offset=61068673024, length=131072)]error = 1 И доолго оно повторяется. Ну, наверно чуть ли не от начала
Ага, появляется, похоже, во время sync().
df /dev/md0c.bde 59802908 32037712 22980964 58% /jails Вот такое файло с md0c: -rw-r--r-- 1 root wheel 62468915200 Aug 10 04:11 jfile делалось вот так: mdconfig -a -t vnode -f jfile -u 0 bsdlabel -w md0 auto gbde init /dev/md0c -i -L /etc/md0c gbde attach /dev/md0c -l /etc/md0c newfs -b 32768 -f 4096 /dev/md0c.bde mount -o async,noatime /dev/md0c.bde /jails
И что делать ? Или где я был неправ?
Ну я точно не понимаю зачем тут "c" в "md0c", но если сделать все то же самое, только на md0, то такого сообщения не появляется. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, Aug 11, 2006 at 11:23:59AM +0300, Irina Liakh wrote:
On Thu, Aug 10, 2006 at 11:54:02AM +0300, Paul Arakelyan wrote:
FreeBSD 6.1-STABLE #0: Wed Jun 7 13:39:20 EDT 2006 Вас ист дас? kernel: g_vfs_done():md0c.bde[WRITE(offset=61068673024, length=131072)]error = 1 И доолго оно повторяется. Ну, наверно чуть ли не от начала
Ага, появляется, похоже, во время sync(). оно как появилось чуть ли не смомента создания - так и до сих пор. В гугле только догадки разные. И рассказы типа "а вот отмонтировать не получается и крэшится при ребуте". Догадки сводятся к "оно пытается писать за пределы диска", НО что-то мне оно так не кажется, учитывая "зазор" в около гигабайта между размером файла-контейнера и смещением, по которому оно записать не смогло. Ещё одна догадка связана с тем, что как-то раз место кончалось - но посмотрел подробнее - так оно уже после появления этого сообщения кончалось.
df /dev/md0c.bde 59802908 32037712 22980964 58% /jails Вот такое файло с md0c: -rw-r--r-- 1 root wheel 62468915200 Aug 10 04:11 jfile делалось вот так: mdconfig -a -t vnode -f jfile -u 0 bsdlabel -w md0 auto gbde init /dev/md0c -i -L /etc/md0c gbde attach /dev/md0c -l /etc/md0c newfs -b 32768 -f 4096 /dev/md0c.bde mount -o async,noatime /dev/md0c.bde /jails
И что делать ? Или где я был неправ?
Ну я точно не понимаю зачем тут "c" в "md0c", но если сделать все то же самое, только на md0, то такого сообщения не появляется. Да как-то не подумал бы, что gbde скушает просто md0.
"а шо тэпэр робити?...". Не иначе как backup&restore... -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sat, Aug 12, 2006 at 10:01:25AM +0300, Paul Arakelyan wrote:
On Fri, Aug 11, 2006 at 11:23:59AM +0300, Irina Liakh wrote:
On Thu, Aug 10, 2006 at 11:54:02AM +0300, Paul Arakelyan wrote:
FreeBSD 6.1-STABLE #0: Wed Jun 7 13:39:20 EDT 2006 Вас ист дас? kernel: g_vfs_done():md0c.bde[WRITE(offset=61068673024, length=131072)]error = 1 И доолго оно повторяется. Ну, наверно чуть ли не от начала
Ага, появляется, похоже, во время sync(). оно как появилось чуть ли не смомента создания - так и до сих пор. В гугле только догадки разные. И рассказы типа "а вот отмонтировать не получается и крэшится при ребуте". Догадки сводятся к "оно пытается писать за пределы диска", НО что-то мне оно так не кажется, учитывая "зазор" в около гигабайта между размером файла-контейнера и смещением, по которому оно записать не смогло. Ещё одна догадка связана с тем, что как-то раз место кончалось - но посмотрел подробнее - так оно уже после появления этого сообщения кончалось.
Вобще конечно лучше начать с понимания что есть "c" в терминах bsdlabel-а. Кто знает эту тайну, поделитесь знанием или докой :) А то кроме "c has special meaning and relates to entire disk" ничего не попадается :) А то что "a" имеет отличный от "c" размер, когда весь диск отдан под один partition ("a"), наводит на мысль, и может отсюда и растет ситуация с записью за пределы диска. В любом случае, мне кажется, это мясо для send-pr.
Да как-то не подумал бы, что gbde скушает просто md0.
Оно и /dev/ad1 скушает. Ему, видимо, не нужны ни partitions ни slices, нужен любой device, на котором возможно сделать newfs
"а шо тэпэр робити?...". Не иначе как backup&restore...
похоже на то... =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
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
On Tue, Aug 15, 2006 at 12:11:35PM +0300, Valentin Nechayev wrote:
Именно это и значит: 'c' означает всё то пространство (ранее - только диск, сейчас может быть слайс, раздел GPT или вообще произвольный объект geom'а, например, софтовое зеркало) на котором заведен данный disklabel. В ядре сделана жёсткая связь что при индексе раздела 2 (соответствующем букве 'c') берётся весь объект целиком.
А что это значит в практическом применении? Кто и как использует раздел c? В чем отличие его использования от использования других разделов? (и еще см. дальше)
А то что "a" имеет отличный от "c" размер, когда весь диск отдан под один partition ("a"), наводит на мысль, и может отсюда и растет ситуация с записью за пределы диска.
Вряд ли. Сокращение 'a' по сравнению с 'c' на 16 секторов - стандартное поведение bsdlabel при выставлении начальной метки. Но ведь Паша не к /dev/md0a обращается, а к /dev/md0c...
Ну может дело в недоработке этого особенного treatment раздела c... А зачем нужно это смещение в 16 секторов?
В любом случае, мне кажется, это мясо для send-pr.
Я думаю что его никто не примет по следующим причинам:
- раздел '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 ... =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
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
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
Tue, Aug 15, 2006 at 14:20:59, spell wrote about "[uanog] Re: AAAA... kernel: g_vfs_done():md0c.bde[WRITE(offset=610686730":
Не понятно :) На практике выходит что использование /dev/md0c не эквивалентно использованию /dev/md0, значит это либо бага, либо фича :) Если бага, надо send-pr, если фича - надо найти этому объяснение :) Какие есть декларируемые рекомендации и легальные действия над девайсами /dev/*c ?
Начиная с 5.* лучше всего говорить, что *c не надо использовать вообще. JIMHO, конечно.
Понятно. А в чем заключается "непредназначенность" раздела "c" для рядовых операций типа newfs, mount, etc ? Точного механизма не знаю. Но последствия налицо.
хорошо. пусть разрешается стрелять в ногу. но хорошо бы если бы у админа была возможность знать что он делает, знать какой будет эффект, знать что это действие влечет наличие дырки в ноге. вот я хочу знать что это за зверь - раздел "с" и с чем его едят. Всё рассказано в предыдущих письмах. а подход "не знаешь - не трогай" тоже не годится, так как в перспективе выливается в ситуацию, когда ОС может всего много, но реально используется из этого мало, так как остальное фиг его знает как работает. Ирина, я с Вами полностью солидарен:)
-netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Wed, Aug 16, 2006 at 09:54:12AM +0300, Valentin Nechayev wrote:
Начиная с 5.* лучше всего говорить, что *c не надо использовать вообще. JIMHO, конечно.
на том и порешим :) а есть какая-нибудь б/м вразумительная дока по всем этим разбивкам дисков? от хэндбука меня просто плющит..
Ирина, я с Вами полностью солидарен:)
:)) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Wed, Aug 16, 2006 at 11:08:07AM +0300, Irina Liakh wrote:
On Wed, Aug 16, 2006 at 09:54:12AM +0300, Valentin Nechayev wrote:
Начиная с 5.* лучше всего говорить, что *c не надо использовать вообще. JIMHO, конечно.
на том и порешим :)
а есть какая-нибудь б/м вразумительная дока по всем этим разбивкам дисков? от хэндбука меня просто плющит.. Есть такая дока: http://www.opennet.ru/base/sys/freebsd_fs_mount.txt.html
-- Kind Regards, Alexander Shikoff AMS1-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (4)
-
Alexander Shikoff -
Irina Liakh -
Paul Arakelyan -
Valentin Nechayev