Scott Long добавил в дерево исходных кодов FreeBSD CURRENT две утилиты для управления контроллерами LSI: mptutil (http://lists.freebsd.org/pipermail/svn-src-all/2009-August/0...) и mfiutil (http://lists.freebsd.org/pipermail/svn-src-all/2009-August/0...). С их помощью можно проверять состояние контроллеров и дисков, создавать и изменять атрибуты RAID массивов, выполнять обновление firmware.URL: http://lists.freebsd.org/pipermail/svn-src-all/2009-August/0...
Новость: http://www.opennet.me/opennews/art.shtml?num=23053
М-да. Они всё ещё кипятят… http://www.openbsd.org/cgi-bin/man.cgi?query=bioctl&sektion=...
ну зачет опеночникам. и что?
>ну зачет опеночникам. и что?Да странно как-то. Фреймворк для сенсоров давно портировали, а bio(4), с ними, к слову, завязанный, почему-то нет. Неужели удобнее было написать новую прогу, чем получить готовый рабочий комплект, с поддержкой далеко не только MegaRAID?
в упор не могу с ходу вспомнить что в fbsd base есть для управления hw raid`ами, все тулзы которые юзал ставил через порты. Если таки нет ничего в base то вполне логично (мне кажется) что нет смысла (пока) делать что-то универсальное а-ля bio вашего, хотя религиозно оно вернее,да:-)
atacontrol
>atacontrolмне, я считаю, везло. то что умеет ata(4) HW RAID я бы не стал называть наверное.
откуда инфа про фремворк для сенсоров, пруфлинк в студию.
>откуда инфа про фремворк для сенсоров, пруфлинк в студию.А гуглом пользоваться негламурно, да? http://www.google.com/search?q=sensors+framework+imported+to...
Этот фреймворк не был принят.
>Этот фреймворк не был принят.Был принят, и был отозван, см. ниже мой коммент по этому поводу.
> Да странно как-то. Фреймворк для сенсоров давно портировалиА через неделю выкинули, потому что pile of crap. С чем я полностью согласен.
>> Да странно как-то. Фреймворк для сенсоров давно портировали
>
>А через неделю выкинули, потому что pile of crap. С чем я
>полностью согласен.Портировать != закоммитить. ;) Кстати, чем оно _на_ваш_взгляд_ есть pile of crap (особенно по сравнению с тем, что имеет место быть в качестве альтернативы — например, SUID-бинарники с прямым доступом к шине ISA).
Для тех кто не в курсе - краткое описание событий с kerneltrap ( http://kerneltrap.org/OpenBSD/BSDCan_2008_Hardware_Sensors_F... ):
Porting the Framework to FreeBSD
Constantine ported the drivers framework to FreeBSD as part of a Google Summer of Code project in 2007. During the project, he ported the sensors API and docs, and ported two drivers from OpenBSD (lm and it) and the coretemp FreeBSD driver. He also ported the sysctl, sensorsd and systat userland apps. Throughout the effort, he fixed many smaller bugs that he found in the process, as well as a 10-year old OpenBSD bug and a 12-year old FreeBSD bug.
The patch was completed on September 13th, 2007, but the FreeBSD HEAD branch was still frozen. On September 25th, Constantine received an unexpected email from Hasso Tepper saying that his patch would be merged into DragonFly BSD. It was committed to DragonFly BSD on October 2nd, less than a month after his patch had been completed.
The patch was finally merged into FreeBSD 8.0 -current by Alexander Leidinger on October 14th the same week that the RELENG_7 branch was created and the FreeBSD code freeze ended. However, it was backed out the next day on the request of Poul-Henning Kamp, who complimented the efforts of the SoC project but questioned whether the framework was needed in FreeBSD, and whether the code had a FreeBSD feel.
A lengthy discussion followed, with many people on both sides of the argument. Constantine explained that the framework may not be necessary in FreeBSD due to some "sysctl magic" introduced by Poul-Henning Kamp. In OpenBSD sysctl's are static and you can't create random sysctl nodes on the fly, whereas in FreeBSD you can. He added that there were also questions about whether all of this should be done in userland rather than in the kernel.
In the end, Constantine still felt like he gained quite a bit of experience with the drivers, and was glad to see the code make it into DragonFly BSD. _He_noted_that_the_patch_is_still_available_and_should_still_apply.
(выделенно мной — Pers)
Ссылка на ман по управлению SoftRAID, ага.. не смешите.
>Ссылка на ман по управлению SoftRAID, ага.. не смешите.Научитесь читать сначала. На английском. Внимательно читать, а не выхватывать 2-3 слова из контекста. Эта утилита предназначена для манипулирования как хардварными RAID-контроллерами (о чём, собственно, и речь), так и для управления softraid(4) (то единственное, что вы соизволили заметить).
Наверное, вам самому обязательно нужно научиться читать и понимать прочитанное.Сравните функциональность mfiutil, которая практически аналогична MegaCLI,
и возможности bioctl. Умеет bioctl создавать новый том, добавлять/вынимать диск из тома, управлять политиками кеширования как тома, так и составляющих дисков ? Включать patrol read, или его планирование ?
>Наверное, вам самому обязательно нужно научиться читать и понимать прочитанное.
>
>Сравните функциональность mfiutil, которая практически аналогична MegaCLI,
>и возможности bioctl. Умеет bioctl создавать новый том, добавлять/вынимать диск из тома,
>управлять политиками кеширования как тома, так и составляющих дисков ? Включать
>patrol read, или его планирование ?bioctl умеет поддерживать RAID в работоспособном состоянии (наблюдать за состоянием, запускать ребилд...). Всё остальное вообще-то определяется в случае нормального процесса администрирования один раз при настройке контроллера через его BIOS. Впрочем, кому что нужно, за всех решать, конечно, не могу и не буду...
И опять же, bioctl - штука универсальная. А это, например, заметно облегчает работу всяким nagios'ам (точнее, их разработчикам и пользователям).
>[оверквотинг удален]
>>
>>Сравните функциональность mfiutil, которая практически аналогична MegaCLI,
>>и возможности bioctl. Умеет bioctl создавать новый том, добавлять/вынимать диск из тома,
>>управлять политиками кеширования как тома, так и составляющих дисков ? Включать
>>patrol read, или его планирование ?
>
>bioctl умеет поддерживать RAID в работоспособном состоянии (наблюдать за состоянием, запускать ребилд...).
>Всё остальное вообще-то определяется в случае нормального процесса администрирования один раз
>при настройке контроллера через его BIOS. Впрочем, кому что нужно, за
>всех решать, конечно, не могу и не буду...Конечно, потребность в колбасе определяется ее наличием.
Для однодисковой машинки, или для двухдискового зеркала, вы, конечно же правы.
Но для типичного использования контроллеров класса mfi, средство полноценного управления из под host OS обязательны.>И опять же, bioctl - штука универсальная. А это, например, заметно облегчает
>работу всяким nagios'ам (точнее, их разработчикам и пользователям).Для мониторинга - возможно. А управлять он не умеет.
Кроме того,я сильно подозреваю, что {mfi,mpt}utils впервые показали интерфейс управления без NDA (мне лень спросить, поэтому "подозреваю").
>Кроме того,я сильно подозреваю, что {mfi,mpt}utils впервые показали интерфейс управления без NDA
>(мне лень спросить, поэтому "подозреваю").По-моему, тоже. MegaRAID, собсно, потому и рекомендуется под *BSD, что хоть он и местами краповый, но зато софтовая поддержка благодаря хоть какому-то сотрудничеству имеется. Здесь некоторые трогательные подробности есть, кстати: http://openbsd.org/lyrics.html#38 (левая колонка).
Универсальное решение не всегда удобно.
Пример с mfi(4): в Open/Net-BSD, где bioctl, пришлось добавлять много кода к драйверу. В Free/DragonFly этот же функционал реализован в самой утилите, поэтому было достаточно сделать проброс команд от mfiutil в драйвере.
Фришное решение еще и платформонезависимое. Мне не составило труда принести mfiutil в OS X, для использования с драйвером для LSI-железок, который я написал: https://github.com/druga/osx-goodies/tree/master/raid
> Универсальное решение не всегда удобно.
> Пример с mfi(4): в Open/Net-BSD, где bioctl, пришлось добавлять много кода к
> драйверу. В Free/DragonFly этот же функционал реализован в самой утилите, поэтому
> было достаточно сделать проброс команд от mfiutil в драйвере.Просто в одном случае больше кода в драйвере, в другом - в утилите. Что лучше - спорный вопрос. С одной стороны, чем меньше кода в ядре - тем вроде как лучше. С другой, чем лучше изоляция устройств от userspace - вроде тоже как лучше...
> Фришное решение еще и платформонезависимое. Мне не составило труда принести mfiutil в
> OS X, для использования с драйвером для LSI-железок, который я написал:
> https://github.com/druga/osx-goodies/tree/master/raidЭм. Если я перенесу код bioctl из OpenBSD на Bitrig и он заработает - это тоже будет платформонезависимость? :-D
> Эм. Если я перенесу код bioctl из OpenBSD на Bitrig и он
> заработает - это тоже будет платформонезависимость? :-DНу это не очень сравнение, bitrig - унылый форк опенка, и bioctl из импортнутого дерева вроде и не убирали. Фряху и OS X же, уже давно мало, что роднит.
А вот тащить bioctl в какую-то реально иную ось - занятие долгое и безблагодатное, он же поди еще и гвоздями прибит к опенку.
>> Эм. Если я перенесу код bioctl из OpenBSD на Bitrig и он
>> заработает - это тоже будет платформонезависимость? :-D
> Ну это не очень сравнение, bitrig - унылый форк опенка, и bioctl
> из импортнутого дерева вроде и не убирали. Фряху и OS X
> же, уже давно мало, что роднит.По всей видимости, не так уж и мало. Я, конечно, малость передёрнул, но всё-таки: говорить о кроссплатформенности можно было бы в случае лёгкого переноса на какой-нибудь Solaris. А так - нечестно как-то. :)
> А вот тащить bioctl в какую-то реально иную ось - занятие долгое
> и безблагодатное, он же поди еще и гвоздями прибит к опенку.Ровно настолько же, насколько интерфейс любого другого драйвера прибит к ОС, под которую разработан. :)
> По всей видимости, не так уж и мало. Я, конечно, малость передёрнул,
> но всё-таки: говорить о кроссплатформенности можно было бы в случае лёгкого
> переноса на какой-нибудь Solaris. А так - нечестно как-то. :)Если эта тема вам интересна, можете почитать на досуге. OS X и FreeBSD во многом далеки друг от друга настолько, насколько OpenBSD далек от Solaris'а.
> Ровно настолько же, насколько интерфейс любого другого драйвера прибит к ОС, под
> которую разработан. :)Фреймворки и утилиты можно писать без тонны привязок к ОС. Драйвера - другая тема.