2007-08-30

старый новый груб

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

решил поделиться впечатлениями, и фичами, которые сам для себя недавно открыл. просьба дополнять в каментах :)

ну и для наглядности, попробу сравнить его с лило.

  1. груб интерактивный. он не требует при правке конфига переустановки в отличии от лило. более того, он предоставляет режим командной строки - прямо при загрузки его можно перенастроить и (!) сохранить эти настройки, или установить в другой БР
  2. груб поддерживат намного больше архитектур и применений: сетевая загрузка, ia64, раритетные risc, разнообразные фс(ext, reiser, ntfs, fat, ffs, ufs, xfs, jfs, ит.д.), сетевая консоль, serial-консоль, tftp, nfs, xen и многое, многое другое
  3. с другой стороны, то что лило не связан ни с одним разделом или файлами раздела позволяет ему пережить снос своей системы, но, после этого он как правило ничего загрузить уже не может :) а вынос boot в отдельный раздел делает груб универсальным загружчиком не зависящим от какой-то системы
  4. груб имеет свой сайт и поддерживаемую документацию, лило почти заброшен (свои фунции он выполняет уже много-много лет без изменений)
  5. груб может грузить не только линукс, но и бзд, макос, ос/2, виндос, дос, солярку, qnx, xen, и другие ОС
  6. может использоваться как загружчик с флешки/дискетки/сидюка/сети.
интересные фичи:
  • автодополнение. нажмите таб, и получайте удовлетворение :) дополняет: параметры, адреса разделов, имена и пути файлов и наверно многое другое :)
  • поиск (!!) как найти из 10 разделов нужный boot? наберите find /vmlinux-2.6.23-rc4 (или find /stage1 или find /boot/stage1) и получите адрес нужного раздела.
  • savedefault - позволяет сохранить текущий выбор как умолчательный.
timeout saved
title XXXX
...
savedefault
  • мепинг. пример загрузка с исо-образа:
title Boot from iso on a harddisk
map (hdX,Y)/your.iso (hdZ)
map --rehook
chainloader (hdZ)+1
rootnoverify (hdZ)
boot
  • fallback. "резервный" вариант загрузки:
default saved # грузить сохранненный умолчательным
fallback 1 # указываем резервные варианты (может быть несколько)

title A # основная система, 0
root (hd0,0)
kernel /kernel
savedefault fallback # сохраняем умолчательным резервный вариант

title B #резервная система, 1
root (hd2,0)
kernel /kernel
savedefault

и добавить grub-set-default в инитскрипт для того чтоб груб мог знать что система загружена успешно.
так же можно указать savedefault N для того чтоб при следующей загрузке грузился вариант N.
  • защита паролем. как отдельных пунктов, так и редактирования, командного режима, или выбора.
#открытый пароль
password blabla
#пароль в md5
password --md5 $1$U$JK7xFegdxWH6VuppCUSIb
#при вводе пароля использовать другой конфиг
password PASSWORD /boot/grub/menu-admins.lst

#пункт запаролен общим паролем
title password protected
lock
....

#свой пароль
title passwd2
password XXX
....
остальное можно найти тут

FreeBSD vs Linux

решил попытать счастья с фрей. некоторые индивиды упорно настаивали что она по всем параметрам лучше чем родная линуха.
пытаясь переключить эту черепаху на 2ю передачу софтапдейтами нарыл такую херню :)

и решил воспользоваться этим как основой для сравнения, и откоментировать по полной :)

1) Reliability
обе ос rock solid. обе поддерживают резервирование (рейды, карпы и т.д.), балансировку (виртуальные серверы и т.д.).
но мое имхо: современные линуксы поддерживают некоторые кластерные технологии, позволяющие задействовать более гибкое резервирование аппаратного обеспечения (есественно специализированного), поддерживаеться multipath, утяжеленная поддержка многопроцессорных систем, и сильносвязанных кластеров.

2) Performance
в оригинале сравнивался линукс 2.2 с какой-то то там фрей :)
2.4 - новый сетевой стек, асинхронная работа большинства подсистем, намного более быстрая ФС.
2.6 - серьезная модификация дисковой подсистемы и подсистемы памяти. улучшены планировщики процессов, планировщик ввода/вывода и многое другое.
так что если и системы не равны по производительности, то разница проявляесть в специфических задачах. и конечно это все можно сильно тюнить :)
по поводу сильно нагруженных стерверов - некоторые стервера kernel.org отдают в сутки более 3Тб (см какти), аналогичная ситуация с серверами redhat.com, ibiblio.org, osuosl.org и многими другими - сервера работают годами под предельной нагрузкой.

3) Security
обе системы имееют мощные средства обеспечения безопасности включая системы мандаторных списков доступа (MAC). НО. обе системы по умолчанию не используют утяжеленные политики. средства линукс: selinux, pax, grsecurity, apparmor, rsbac, hardened gcc, pie, pic - позволяют настроить и политики отдельных приложений, и роли, и обеспечить защиту програмных ошибок, защиту от сплойтов, ограничить права супер-юзера, и очень, очень многое другое. легко настраиваються (настройка политик по примеру, утилиты с графическим пользовательским интерфейсом, и т.д.).
многие дистрибутивы линукса сертифицированы по ISO CC: RHEL(3,4,5), SLES(8,9,10). да, сертификация проводиться для определенного железо. но линукс неоднократно проходил эту проверку на уровне eal4+. и все средства, использованные в этих дистрибутивах - доступны все дистростроителям и пользователям. т.е. можно свой сервер сделать безопасным на очень высоком уровне.
проблемы безопасности отдельных програм - общие для обоих систем, т.к. обе системы используют много общего ПО. в линукс системы безопасности позволяют свести опасность от таких уязвимостей к минимуму.
файрвол: pf в bsd и netfilter в линукс - очень мощные штуки. только в бзд очень часто используют некий ipfw, отзывы о котором не столь лестные :)

4) ФС
linux: ext3, ext4, reiserfs, reiser4, xfs, jfs, gpfs, coda, afs - все как на подбор высопроизводительные, журналируемые и надежные ФС.
bsd: ffs/ufs/ufs2 - в последних версиях, с софтапдейтами (которые я ну никак не могу включить :)), с журналированием (хотя его тоже никогде не видел), почти полностью синхронные (а значит очень надежные, и не менее медленные :))
в случае сильных сбоев синхронную фс стоит считать более надежной. но журналирование, и бесперебойники ставят под очень сильный вопрос целесообразность этого.
асинхронные фс линукс намного(ну как минимум заметно) быстрее.

5) дрова
в обоих ОС бывают проблемы с дровами. НО.
т.к. линукс официально поддерживаеться многими крупными производителями серверного оборудования - с серверами у линукс проблемы не возникают.
с десктопами - линукс отлично работает в большинством оборудования - поддерживаеться большинство чипсетов, очень многие ide и sata контроллеры (кроме наколенных поделок, но и с ними со временем разбираються), все популярные звуковые карты (слышал только что есть проблемы с x-fi), usb, почти все существующие сетевые карты, для видеокарт от нвидиа и ати есть дрова от производителей, очень многое беспроводное оборудование легко устанавливаеться и нормально работает.
код драйверов часто заимствуют друг у друга, так что у фри проблемы с дровами не так уж и сильно большие.

6) комерческое ПО
линукс - признанная платформа, под которую выпускают свое ПО ibm, intel, sun, vmware, 1C, oracle, opera, google, nero, nvidia, sgi, mathsoft, id software, epic games, transgaming, loki games и многие, многие другие.
если нет нативного ПО есть wine (Wine Is Not Emulator), значительно расширяющий диапазон доступного ПО. есть cedega, позволяющая запускать очень-очень многие игры.
есть и эмуляторы и виртуальные машины, позволяющие запускать все остальное.
фрибсда - имеет бинарную поддержку линукс. которая позволяет пытаться запускать вышеперечисленный софт, с тем или иным результатом.

7) свободный софт
его дофига. стоит только заглянуть на freshmeat.net, sourceforge.com, code.google.
успешно работает под обоими системами.
последнее время тенденция: больше софта изначально разрабатываеться (а затем успешно работает) под линукс.

8) средства разработки
конечно весь софт доступен и под бзд, я не спорю. НО.
GNU/Linux, GNU Compiler Collection , gnu vim, gnu emacs, gnu debugger - средства разработки почти под любой язык программирования :)
java (под бзд с ней бывают большие проблемы, линукс - официально поддерживаеться), C# (gnu mono :)), qt, gtk, и много-много скриптовых языков - все изначально разрабатываеться именно под линукс :)
ну и конечно linux совместим с posix, имеет lsb, и если не делать явных глупостей, софт скомпилированный под линукс успешно выполняеться под линукс.

9) инфраструктура разработки
бред полный :)
фрибсд - один проект + порты. результат - все целосно, но в рамках собственно фрибсд юзер не имеет выбора и поставлен перед фактом (про порты я не говорю :))
линукс - один огромный(см. kernel.org :)) проект ядра, плюс дистрибутивы - сборки ядра и софта для определенных целей, вкусов, вероисповеданий. результат - линукс КРАЙНЕ гибкий, чрезвычайно универсален, очень модульный, и независимый. всегда есть альтернативы, всегда есть выбор.
недостатки - можно наткнуться на бинарную несовместимость, необходимо делать выбор.

10) поддержка
фрибсд - впервые слышу :) хотя на фрибсд.орг говориться что она есть :)
линукс - бесплатная поддержка сообществом (как бзд наверно), бесплатная поддержка дистростроителя, плятная поддержка дистростроителя, поддержка 24х7 от дистростроителя, поддержка от вендора железа, поддержка 24х7 от вендора железа. ничуть не хуже чем у комерческих юниксов :)

11) цена владения
без коментариев. как хочеш так и считай. многие считают что по этому пункту венда нам даеться аллахом даром (или с доплатой).

2007-08-18

размышления о dhcp

столкнулся с проблемой: провайдер обвинил меня в неправильной маршрутизации, дескать все мои проблемы с сетью - только мои проблемы, так как у всех все нормально работает.

далее я выяснил, что провайдер выдает через dhcp 5 маршрутов. мой тазик принимает только дефолт. причем только дефолт принимали как мой тазик, так и wrt54gl, который я использовал как роутер.

раскопки показали, что клиент dhcp от isc не совместим с стандартом. точнее, как написали на сайте "Both the client and the server provide functionality that, while not strictly required by the protocol, is very useful in practice" :)

но поиски по портежу показали что есть альтернативы:
$ eix dchp -c
[I] net-misc/dhcp (3.0.3-r9@19.03.2007): ISC Dynamic Host Configuration Protocol
[I] net-misc/dhcpcd (3.0.16-r1@18.08.2007): A DHCP client
[N] net-misc/selfdhcp (~0.2a): a small stealth network autoconfigure software.
[N] net-misc/udhcp (0.9.9_pre20041216-r4): udhcp Server/Client Package

1й из них - от isc, от которого я решил отказаться.
2й - сразу заработал, и принял все как и следовало :)

вывод: не все что от такого крутого имени, есть хорошо.

п.с. надо посмотреть, может бинд у них тоже такой "интересный"?

п.п.с. есть еще клиенты не содержащие в своем названии dhcp :) это pump, dibbler, может и другие.

п.п.п.с удобные средства управлениями dhcp предлагае /etc/conf.d/net, стоит просмотреть на это тему /etc/conf.d/net.example - можно выбирать клиент dhcp, и тонко его настраивать

2007-08-08

atime or noatime? that's the question

на lkml торвальдс начал немаленький флейм, посвященный вопросам производительности ФС и ипции atime.
некоторые разработчики заявляют, что noatime позволяет получить прирост производительности интенсивного чтения с диска до 50%

ну и соответственно я решил это протестить. заодно потестить не только на екст3, на которую лились все обвинения, но и рейзер.
суть теста: рекурсивный греп по дереву портежа. с atime, и без него. поиск на время. причем в 2х режимах: с "холодным" кешем, и с прокешированым деревом. тест повторю по 2 раза.
почему именно портеж? потому что на большом количестве файлов большее количество раз надо выполнять обновление atime, следовательнее будет более заметен результат. другими аналогичными примерами могли бы быть: компиляция большой программы, работа почтового сервера под большой нагрузкой, и т.д.

1) рейзер (3я версия, из 2.6.23-гит6), atime
Cold cache:
real 5m12.021s
user 0m13.316s
sys 0m7.575s
Warm cache:
real 3m39.969s
user 0m13.341s
sys 0m6.831s

Cold cache:
real 5m43.197s
user 0m13.491s
sys 0m8.068s
Warm cache:
real 5m19.285s
user 0m13.426s
sys 0m8.343s


2) рейзер (3я версия, из 2.6.23-гит6), noatime
Cold cache:
real 4m26.874s
user 0m13.172s
sys 0m7.058s
Warm cache:
real 2m57.963s
user 0m13.373s
sys 0m6.871s

Cold cache:
real 4m24.752s
user 0m13.237s
sys 0m7.149s
Warm cache:
real 2m47.410s
user 0m13.277s
sys 0m6.116s


3) екст3 (2.6.23-гит6), atime
Cold cache:
real 10m34.207s
user 0m13.986s
sys 0m6.704s
Warm cache:
real 0m16.512s
user 0m13.073s
sys 0m2.427s

Cold cache:
real 10m51.976s
user 0m13.450s
sys 0m6.677s
Warm cache:
real 0m16.305s
user 0m13.018s
sys 0m2.445s


4) екст3 (2.6.23-гит6), noatime
Cold cache:
real 8m36.656s
user 0m13.007s
sys 0m5.223s
Warm cache:
real 0m14.773s
user 0m12.878s
sys 0m1.892s

Cold cache:
real 8m29.148s
user 0m12.869s
sys 0m5.148s
Warm cache:
real 0m14.791s
user 0m12.895s
sys 0m1.894s


что сразу заметно:
  • с использованием кеша екст3 - просто молния
  • дир_индекс намного быстре происходит работа с большими каталогами
  • разнице atime - noatime хоть и не вдвое, но все-таки весьма заметна
  • на портеже рейдер эффективнее чем екст :(
причина 1го - то, что рейзер использует свои, оптимизированные, функции работы с блочными устройствами. и не смотря на все заявления ганса, это вовсе не плюс, т.к. их никто фактически не поддерживает и не развивает, и она не использует многие достижения подсистемы ио линукса.

причина 2го - то что с использованием dir_index содержимое каталого хешируеться и храниться в бинарном дереве - точно так же как и на рейзере. но на экст3 это делаеться не со всеми каталогами (в моем случае - меньше трети) - потому экст3 и проигрывает. хотя экст4, которую я тестировал приблизительно в таких же условиях - порвала рейзер в клочья.

выводы: все использую noatime. часто вместо него имеет смысл использовать inotify. или mtime.