Знакомьтесь, LVM!

А работа дисковой системы не становится медленней от этой LVM?

Не становится :-) Часто используемые файлы все равно в кэше лежат, а для того, что не в кэше, лишние 10 инструкций погоды не сделают.

2 no-dashi скажи плиз , как ты создавал загрузочный initrd к lvm2 , оч. нужно...

1) нахрена oracle LVM если все равно на шоте биндинг на RAW device ?
Тоесть, можно пояснить, какой реальный польза от LVM в этом случае?

2) если это девелоперская машина (о чем можно косвенно судить по 2.6.8.1), то нахрена вообше использовать RAW device ? Не, я понимаю что лучше "тренироваться на кошках", но это приводит к тому, что надо "распрощаться" сразу с местом выделенным для raw под Оракл. В случае файловой системы всеж немножнко гибче, не отжираеться сразу все место.

А так.. удачи :)

P.S. на металинке давноым давно 5 патчсет раздают.

afaik, lvm -- logical volume manager ^^^^^^^

>Левый xterm

Прикольно звучит, если от контекста оторвать.

>ext2/ext3 - увы, на ходу ресайзиться не умеет

afaik умеет если на ядро наложить патч ext2online

> 1) нахрена oracle LVM если все равно на шоте биндинг на RAW device ? > Тоесть, можно пояснить, какой реальный польза от LVM в этом случае?

Для начала, уважаемый может показать настройки оракла, у которого в качестве датафайла указан какой-нибудь /dev/sda10 или чего-нибудь в этом духе? :-)

> В случае файловой системы всеж немножнко гибче, не отжираеться сразу все место.

man lvresize :-) Нарастить пространство всегда можно. А еще гибкость расположения датафайлов на файловых системах выражается в 151% wio - Krause и just тебе расскажут :-)

> скажи плиз , как ты создавал загрузочный initrd к lvm2 , оч. нужно...

А я его не создавал - у меня / нормальным разделом :-) Но сдается мне, что /sbin/dmsetup.static, /sbin/lvm.static и правильный linuxrc тебе помогут :-)

Вы прикалываетесь? или где??

Что показать??
#raw -a
/dev/raw/raw1: bound to major 8, minor 18

и т.д.

А потом

>create tablespace test datafile '/dev/raw/raw1' size 1000M REUSE .. тра ла ла..

Вприниципе, можно задать все биндинги при создании базы.


И причем/зачем там LVM :)

>> А еще гибкость расположения датафайлов на файловых системах выражается в 151% wio - Krause и just тебе расскажут :-)

Если внимательно перечитать,то можно заметить,что я говорил о девелоперской машине в случае файловой системы, где wio и другие умные слова на предмет производительности нафиг никому не нужны.

Или я ошибся?? речь не иначе как о продакшен сервере, и вы пускаете в продакшн ядро 2.6.8.1 ??? и как скорость?? :))

>>Для начала, уважаемый может показать настройки оракла, у которого в качестве датафайла указан какой-нибудь /dev/sda10 или чего-нибудь в этом духе? :-)

Или Вы типа этого хотели увидеть??

SQL> select t.name from v$datafile t where t.name like '%raw%';

NAME
--------------------------------------------------------------------------------
/dev/raw/raw1

> Если внимательно перечитать,то можно заметить,что я говорил о
> девелоперской машине в случае файловой системы, где wio и другие
> умные слова на предмет производительности нафиг никому не нужны.

Породы кошек должны совпадать, чтобы баги лезли в ожидаемых местах :-)

> Или Вы типа этого хотели увидеть?? > > SQL> select t.name from v$datafile t where t.name like '%raw%'; > > NAME > -------------------------------------------------------------------------------- > /dev/raw/raw1

Прямая ссылка на устройство не в текстовом файле? Смелое решение :-)

>>Породы кошек должны совпадать, чтобы баги лезли в ожидаемых местах :-)

Это отчасти верно, но это не ВАШИ баги :)
Если датафайл создан без ошибок, то как девелопера Вас больше не интресует как физически он живет, за исключением занятого места. Я глубо за RAW, (не Вам мне про IO рассказывать :) ), но на девелоперской машине это приводит к отжиранию места, и по большому счету, излишество.
Если вам уж и довелось совмешать две разные професии (DBA & developer) то научитесь отделять мух от котлет, как девелопера вас вообще ничего не должно интресовать кроме хоста, порта и SIDa. Даже опреационная сиситема :))


P.S. а вот насчет багов, всеже бегом на металинк за патчсетом :)

>>Прямая ссылка на устройство не в текстовом файле? Смелое решение :-)

Ага. Зачем лишние прослойки.
Чем с точки зрения оракла

/my/super/patch/to/oracledatafile/datafile.dbf

отличается от

/dev/raw/raw1 ?

Может быть я Вас удивлю, но ничем :)

Некоторые, правда, лепять симлинки на raw для придания им "человеческих" имен, но я предпочитаю просто писать коментарии.
Кроме того, вроде бы как типовая опрерация. Я вот и подивился какую ж роль играет LVM (ничего против оной не имею) при биндинге на RAW :)

> Если вам уж и довелось совмешать две разные професии (DBA & developer)

Так это самое совмещение DBA/DBD/OSA и есть моя козырная карта, за которую меня и приглашают на работу :-)

Как DBA меня интересуют особенности настройки оракла под различные условия, как OSA - особенности поведения в LVM, а как DBD - каким образом получить от этого &^#$%*(^% "Паруса" то, что мне нужно в том виде, в каком нужно :-)

> но на девелоперской машине это приводит к отжиранию места, и по большому счету, излишество.

При 80GB на диске жалкие 8GB под игрушечную базу погоды не сделают :-)

> Чем с точки зрения оракла /my/super/patch/to/oracledatafile/datafile.dbf отличается от /dev/raw/raw1 ?

Действительно, не отличается ничем, кроме того, что неудобно переезжать на другую систему - особенно если вдруг окажется, что там уже есть инстанс, у которого один из датафайлов тоже ссылается на /dev/raw/raw1 :-)

> вот и подивился какую ж роль играет LVM (ничего против оной не имею) при биндинге на RAW

Например, такую: lvresize -L +512M /dev/athena/MAIN_temp01 :-)

>>При 80GB на диске жалкие 8GB под игрушечную базу погоды не сделают :-)

Вот странный человек :))
Мусор (читай музыка, фильмы, книги(не настольные) и т.д.) стремяться сожрять все свободжное место :) будь его хоть 80Гиг, хоть 180 ( у меня кстати больше :)

>>Так это самое совмещение DBA/DBD/OSA и есть моя козырная карта
На самом деле, это не всегда так.
Я думаю, в дальнейшем Вам всеж прийдеться останавливаться на чем то одном, а две остальные уйдут в "факультатив". Я не стану ввзязываться в спор и объяснять Вам почему, но так произойдет с большой вероятностью.

>>Действительно, не отличается ничем, кроме того, что неудобно переезжать на другую систему - особенно если вдруг окажется, что там уже есть инстанс


А.. ну да ну да :)
Остаеться понять, кто и зачем ставить второй инстанс на сервере.
В случае тестовых, девелоперских и т.д.. Я не фижу вообше смысл в RAW.

>>Например, такую: lvresize -L +512M /dev/athena/MAIN_temp01 :-)

Осталость еще ораклу "объяснить" новый размер файла, или вы AUTOEXTEND предпочитаете?? И еще не иначе как без квот.

Вобщем подоьбная ситуация решаеться просто добавлением нового датафайла (на практике нового диска) через ALTER .

Я ценю Ваши познания как OSA и частично DBA (хотя я то и другое у меня в факультативе). Это все очень интересно, на за такой финт на продакшен сервере я бы Вас уволил :) Ничего личного.

Удачного дня. Увы, Пора работать.

> Я думаю, в дальнейшем Вам всеж прийдеться останавливаться на чем то одном

Надеюсь, что не придется - ибо узкая специализация всех специалистов погубит эту цивилизацию :-)

> Мусор (читай музыка, фильмы, книги(не настольные) и т.д.) стремяться сожрять все свободжное место

А я на работе работаю, и как следствие, фильмов и книг у меня нет :-)

> Осталость еще ораклу "объяснить" новый размер файла, или вы AUTOEXTEND предпочитаете?

Вообще-то, я предпочитаю alter tablespace xxx add datafile и lvcreate -L <размер> -n <инстанс>_<тэйблспейс><номерфайла> <имя группы> :-)

IMHO так оно правильнее, и место расходуется ровно по мере необходимости :-)

P.S.: так как насчет 16-ти разделов на SCSI-винте, прониклись полезностью LVM? :-)

> Увы, Пора работать.

Одно другому не мешает :-)

>>IMHO так оно правильнее, и место расходуется ровно по мере необходимости :-)

Эх.. о разных мы вещах говорим :() кроме RDBMS на сервере место больше никто не жрет, так приянято. ОС лиш подложка для RDBMS. Иначе, это не сервер баз данных. Максимум еще живет примитивнй web frontend, но он место не жрет. Если нужно место, то просто добавляються сырые диски.


>>P.S.: так как насчет 16-ти разделов на SCSI-винте, прониклись полезностью LVM? :-)

Из той же оперы что и первый вопрос. Я не знаю серверных задач для которых диски нужно вообще бить на части. В идеале, один диск - один raw. На пракике таки приходиться бить, но максимум на 2-3 части. 16 это из области "шаловливые ручки".

И если так уж надо объеденить несколько дисков в один большой для создания датафайла большего размера чем диск, то делаеться это АППАРАТНО (смотреть в сторону RAID котнролеров).

> Я не знаю серверных задач для которых диски нужно вообще бить на части. В идеале, один диск - один raw.

Хреновая мысля (IMHO). Например, побился у вас датафайл (нерадивый админ чего нибудь напутал) - и если возникает необходимость восстановления, датафайл можно вывести в оффлайн, восстановить его, и снова поднять в онлайн. В случае с "одним, но большим raw" - увы, вы погасите весь тэйблспейс, да и время восстановления сильно возрастет.

P.S.: ну не доверяю я большим файлам, со времен информикса и 8-ки не доверяю :-)

> И если так уж надо объеденить несколько дисков в один большой
> для создания датафайла большего размера чем диск, то делаеться
> это АППАРАТНО (смотреть в сторону RAID котнролеров)

Ага, а в особенности круто все добавляется, если рэйд не из серии 0/1/0+1 :-)

>> Например, побился у вас датафайл (нерадивый админ чего нибудь напутал)

Хреновая мысля (ИХМО) держать нерадивого админа :)
Во первых, случай из ряда вон выходяший,во вторых бакап же есть :)

И еще, что значит "побился" ?? Вот так вот работал, и взял и побился?? тока не надо рассказывать про выключение питания и все такое.. для этого тут полно других "ушей"
В крайнейм случае - бакап должен быть в любом случае с включеным ARCHIVE LOG


>>ну не доверяю я большим файлам, со времен информикса и 8-ки не доверяю :-)
Я доверяю здравому смыслу

>>Ага, а в особенности круто все добавляется, если рэйд не из серии 0/1/0+1 :-)

Сер изврашенец на предмет держать 5 райд под RDBMS ?? :)
Кто там про скорсоть IO заикался :))

P.S. не придумывайте сферического коня в вакууме. Если уж дискутировать , то рассматривать "здравые решения", а не "так может быть впринципе". Это я о диске у 16 партиций да 5 райде под RDBMS.

davinchi

Да, кстати, это не совсем LVM, это LVM2 - LVM нет в 2.6, однако новый LVM гораздо лучше, плюс при помощи device-mapper'а, можно "нарезать" устройство кусками по n Byte и слить в одно в случайном порядке :)

Мы используем его (LVM) как основу нашей безопасности (еще vserver)

> плюс при помощи device-mapper'а, можно "нарезать"
> устройство кусками по n Byte и слить в одно в случайном порядке :)
> Мы используем его (LVM) как основу нашей безопасности (еще vserver)

А не проще использовать CRYPT-target ? :-)

а loop-aes кто-нить юзал? как он в продакшн на 2-4 процессорных серверах под экстремальными нагрузками живет? или че другое посоветуйте?

Ezzh

Ну чтож, поздравляю, через четыре года, после появления динамических томов в виндах их наконец-то скопировали в линухе...:)

P.S. Я не утверждаю что в виндах они появились первыми - вообщем-то мелкомягкие их у веритаса купили...:)

> Через четыре года, после появления динамических томов в виндах их наконец-то скопировали в линухе...:)

Ты действительно так глуп, или прикидываешься? Первая версия LVM (0.5) вышла в 1999 году, LVM версии 1 в 2001 году. На уровне юзерспейсовых утилит от LVM 0.9 (2000-й год) она отличалась в основном багфиксами.

Тебе что - как всегда, лишь бы языком помотать?

Ну да, и все знают кто придумал интырнет, lvm уже сто лет как имеется в AIX

Что-то я не всосал, здесь все тормозят или у меня единственного LVM на ядре 2.4 пашет уже 2,5 года?