Есть такая штука как rawdevices в ядрах помоложе (если кто-то знает). Она необходима, например для подключения неформатированных разделов (хранение данных) к мощным базам данных (Oracle, DB2, Sybase). С переходом в ядре 2.6.9 на udev отсутствует утилита 'raw’, которая есть еще в дистре Fedora Code 2. Так вот, вопрос. Подскажите плиз, если это возможно, как создать в rawdevice в выше уазанном ядре.
К стати я юзаю Fedora Code 3 и мне позарез необходимо это сделать.
Заранее благодарен.
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
эээ.. я что-то пропустил?
использовать (deprecated) rawdevices из ядра ветки 2.6., которую Линус всё ещё считает нестабильной и доводку до потребного состояния отдаёт дистрибутиво-строителям, в продукции с таким ПО, как Оракл и подобным, не очень радушно относящимся к подобному ядру..
как-то это всё не вяжется.. :))
ну, если надо — то надо. пересобирай ядро, включив поддержку rawdevices, скачивай и компилируй последную доступную raw и пробуй, что у тебя получится. udev я бы посоветовал отключить и использовать /dev/*, но это хозяин — барин…
Так а в чём был смысл тогда переходить на 2.6.9? Откатись на ядро «помоложе» и не мучайся.
Судя по словам моих друзей и своему мнению, ядро 2.6 выше по производительности. В FC2-3 используется новейшее ПО, от которого совсем не хочеться отказываться. ОЧень бы хотелось найти ответ на этот вопрос. К тому же в udev все это есть. Я уже пробовал пересобирать ядро с включенным rawdevices. Утилита raw говорит 'Cannot open master raw device '/dev/rawctl' (No such file or directory)’. Но имея новое ядро я бы хотел выяснить для себя как же разработчики Баз Данных собираются обходить эту проблему.
Так уж если rawdevices — deprecated, как можно обойти его, т.е. подсоединить неформатированный раздел как character device?
Я ж не заставляю тебя менять дистрибутив ;). Просто собери там ядро, в котором всё нормально работает.
Кстати, если в федоре тебя заинтересовало лишь новейшее ПО, то ставь SuSE — там с raw devices всё нормально прямо «из коробки» (по крайней мере, в 9.1. Как обстоят дела в последней 9.2, я не знаю, т.к. не видел. Но думаю, там тоже всё нормально) ;)
Так не исопльзуй udev. Используй /dev/*. А все необходимые устройства (например, /dev/rawctl) создай вручную с помощью 'mknod’. Может так твоя проблема решится.
И на этом спасибо. Но создавать «/dev/rawctl» с помощью mknod тоже пробовал. Я облазил по этой теме все что нашел в Google. raw всегда говорит одно и тоже. Эти файлы должны создаваться самостоятельно. Но этого не происходит.
mknod создаёт только в каталоге /dev/*, а не в виртуальной файловой системе udev, в которой модули устройств сами регистрируют необходимые им устройства.
нежелательность использования udev в производственной практике заключается в том, что не дай бог гавкнется модуль этой fs — система рухнет. тут же.
такой риск никому вроде бы как не нужен.
есди эе у тебя /dev/ находится на нормальной fs, то даже в случае отказа этой fs у тебя будет система работать с теми устройствами, что были открыты на момент сбоя. что является плюсом.
более того, есть мысль вообще располагать /dev/ систему в cramfs-образе.
соотвественно, если у тебя при использовании udev не устройств, относящихся к rawdevices, то — либо нет такого модуля (не скомпилирован), либо он не подгржуен. либо, как и грозились, его выкинули.
Оракл, кстати, уже и без rawdevice работать умеет.
всю жизнь разделы были блочными устройствами.
и зачем базу делать на символьном устройстве?
хотя, может я тут чего путаю, и это только мне так кажется, что символьное устройство — это устройство с последовательным доступом…
1. А если допустим что модуль rawdevices скомпилирован но не подключен, как дать ядру знать что-б оно его подключило?
2. Совешенно верно. Символьное устройство имеет последовательный доступ. Представим такую ситуацию. Допустим БД начинает транзакцию по записи в определенную строчку таблицы. Выполняе ее и закрывает. Что будет делать блочное устройство. Оно будет кэшировать часто используемую информацию. Возможно результаты последней транзакции она и закэширует. Тут открывается новая транзакция. Пытается прочитать данные с результатов предыдущей транз. Соответственно на винчестере будет старая инфрмация и БД отдаст то что у нее есть на текущий момент. Соответственно результаты не правильны.
В случае же символьного устройства данные ложаться последовательно. Байт за байтом. И тут исключена возможность кэширования. На это и обращают внимание разработчики БД.
modprobe rawdevices
?
или добавить этот модуль в /etc/modules, чтобы подгружался при старте системы.
интересные сказки.
а как тогда реализовавыется отключение кеширование на уровне буыера жёсткого диска? а?
ихмо, это несущественно — блочное ли устройство видится или символьное.
Пробовал 'modprobe rawdevices’ — говорит не найден такой модуль.
/dev/modules.conf они переименовали на modprobe.conf
Как они видятся не важно. Работают они, на сколько я понимаю, по разному.
Пробовал к Sybase подсовывать блочные устройства. К стати работает. И Ничего не говорит. Как он себя поведет в усиленном юзании — не знаю. Но факт остается фактом — работает.
Но всетаки хотелось бы выяснить, неужели в новом ядре добавлена поддержка блочных устройств как символьных или я чего-то недопонимаю.
Эххх….
Может быть они, разработчики, тоже документацию иногда почитывают, а?
Где устанавливается вышеуказанный флаг?
Т.е. получается мне нужно просто указывать блочное устройство. Так?
при открытии длочного устройства указываются опции. «побитовым или» нужные устанавливаются.
вот туда и добавть это самое O_DIRECT.
точного кода не напишу, поскольку таким не занимался ;)
Спасибо. БОЛЬШОЕ.