Всем добрый вечер.
Дистрибутив: Proxmox 2.1
Версия Debian: 6.0.6
Ядро: 2.6.32-17-pve
Утилита для тестирования: fio
Конфиг для записи: write.ini:
[writetest]
blocksize=4k
filename=/dev/sda2
rw=randwrite
#direct=1
buffered=1
ioengine=libaio
iodepth=4

Конфиг для чтения:
[readtest]
blocksize=4k
filename=/dev/sda2
rw=randread
#direct=1
buffered=1
ioengine=libaio
iodepth=4

Обращаю ваше внимание что тестируется не скорость записи или чтения, а отзывчивость системы и работа планировщика. Отзывчивость оценивается по количеству уровню iops операции чтения. Latency пока предлагаю не оценивать.

Планировщик: deadline
/sys/block/sda/queue/iosched/fifo_batch:16
/sys/block/sda/queue/iosched/front_merges:1
/sys/block/sda/queue/iosched/read_expire:500
/sys/block/sda/queue/iosched/write_expire:5000
/sys/block/sda/queue/iosched/writes_starved:2

NCQ:
/sys/block/sda/device/queue_depth:1

Проверяем в режиме простоя:
Чтение с раздела:
read : io=11328KB, bw=318406B/s, iops=77, runt= 36431msec
slat (msec): min=2, max=36, avg=12.86, stdev= 3.95
clat (usec): min=2, max=68510, avg=38565.74, stdev=7217.68
bw (KB/s) : min= 272, max= 347, per=100.12%, avg=310.38, stdev=15.79

iostat -mdx 1:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 78.00 0.00 0.30 0.00 8.00 1.00 12.78 12.78 99.70


Запись на раздел:
write: io=4643MB, bw=238160KB/s, iops=59540, runt= 19964msec
slat (usec): min=2, max=7661K, avg=15.69, stdev=9763.96
clat (usec): min=5, max=7661K, avg=50.75, stdev=16911.66
bw (KB/s) : min= 1530, max=973280, per=334.49%, avg=796625.82, stdev=381905.95

iostat -mdx 1:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 2.00 0.00 436.00 0.00 1.72 8.09 143.28 339.99 2.29 100.00

Естественно iostat продолжает показывать запись на диск даже после остановки fio:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 1.00 0.00 436.00 0.00 1.70 8.00 143.66 330.46 2.29 100.00

Пробуем прочитать данные с раздела /dev/sda1:
[readtest]
blocksize=4k
filename=/dev/sda1
rw=randread
#direct=1
buffered=1
ioengine=libaio
iodepth=4

Результаты:
read : io=3732KB, bw=61752B/s, iops=15, runt= 61885msec
slat (msec): min=40, max=157, avg=66.33, stdev=13.15
clat (usec): min=2, max=418926, avg=198389.78, stdev=29420.46
bw (KB/s) : min= 13, max= 70, per=99.68%, avg=59.81, stdev= 7.34

iostat -mdx 1:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 1.00 15.00 240.00 0.06 0.94 8.03 142.12 548.40 3.92 100.00

Видно, что чтение «худо - бедно» идет.

Пытаемся прочесть данные с /dev/sda2(Не повторяйте этого дома!):
[readtest]
blocksize=4k
filename=/dev/sda2
rw=randread
#direct=1
buffered=1
ioengine=libaio
iodepth=4

Результаты:
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=4
Starting 1 process
Jobs: 1 (f=1): [r] [inf% done] [0K/0K /s] [0/0 iops] [eta 1158050441d:06h:59m:26s]

iostat -mdx 1:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 1.00 0.00 435.00 0.00 1.71 8.04 301.64 793.95 2.30 100.00
s

Как видим ни одного iops на чтение не потрачено. И это уже после остановки fio.

Пробуем читать с помощью dd:
dd if=/dev/sda2 of=/dev/null bs=4K
17403+0 records in
17402+0 records out
71278592 bytes (71 MB) copied, 98.3468 s, 725 kB/s

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 187.00 3.00 4.00 330.00 0.75 1.29 12.48 302.52 920.32 2.99 100.00

Что-то мы смогли прочитать, но тратилось около 4-5 iops. Что на мой взгляд крайне низкая цифра.

Отключение в fio буфера и установка режима direct не дали никакого эффекта.
[readtest]
blocksize=4k
filename=/dev/sda2
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=4

Эта ситуация сохраняется до тех пор пока весь кэш buffered не будет сброшен на диск.

Также прошу обратить внимание, что если операция чтения и записи выполняются в режиме direct, то блокировки чтения не происходит:

read : io=29780KB, bw=213850B/s, iops=52, runt=142598msec
slat (usec): min=2, max=25, avg= 5.00, stdev= 1.16
clat (msec): min=10, max=182, avg=76.59, stdev=26.05
bw (KB/s) : min= 162, max= 308, per=100.26%, avg=208.54, stdev=19.48

write: io=35432KB, bw=208744B/s, iops=50, runt=173812msec
slat (usec): min=2, max=27, avg= 5.21, stdev= 1.42
clat (usec): min=139, max=462406, avg=78472.54, stdev=61807.28
bw (KB/s) : min= 82, max= 1653, per=102.28%, avg=207.64, stdev=175.78

iostat -mdx 1:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 53.00 32.00 0.21 0.12 8.00 8.00 92.02 11.76 100.00

Обратите внимание что в этом случае количество io которое тратиться на чтение больше чем то, что тратится на запись.

Есть у кого-нибудь идеи почему так происходит? Что поковырять?

P.S.: Участвует ли планировщик в режиме записи/чтения direct?

Добрый день.

Изучаю протокол OSPF и принцыпы построения сетей на его основе. В процессе работы построил испытательную сеть: http://flic.kr/p/bq7K7K

Хотелось бы узнать правильно ли я выделил опорную область: R5;R6;R9, темно-фиолетовые линии

Дальнейшая настройка предполагает, выделение следующих областей:
Area 1: R1;R3
Area 2: R2;R4
Area 3: R8;R6
Area 4: R7;R5
Area 5: R10;R9

Опорную область выделял согласно рекомендаций компании Cisco о
построении сетей на основе протокола ospf: «Опорная область должна
быть построена на стабильных каналах и и не терять состояния
связности». Но в таком случае возникает ситуация в которой
маршрутизаторы R5,R6 являются маршрутизаторами ABR для 4
областей(возможно я ошибаюсь) что противоречит рекомендациям Cisco
относительно максимального количества областей(согласно рекомендации
не более 3).

Было еще предположение построить опорную область на основе следующих маршрутизаторов: R3:R4:R5:R6:R9

В таком случае получается три дополнительныз области:
Area 1: R7:R5:R6:R8:R9:R10
Area 2: R3:R1
Area 3: R4:R2

Жду коменнтариев и корректировок(с описанием выбора). Заранее, большое спасибо.

Задумался об автоматизации процесса резервирования виртуальных машин на платформах openvz, kvm. Так как backup HN не требуется то возникает, вполне законное желание, осуществлять перекрестный backup. Особенно если учесть, что винчестеры нынче дешевые, да и raid обычно нулевой используется. Процесс резервирования видится следующим: Имеется два компонента Сервер и Клиент. Сервер выполняет процесс резервирования для виртуальных машин которые на нем хостятся. В зависимости от типа виртуализации процесс резервирования может отличаться, соответственно должны использоваться утилиты предоставленные авторами механизма виртуализации, либо инструмент который пожелает использовать администратор. После того как процесс снятия резервных копий окончен, сервер рассылает(клиентам) уведомления, после чего клиенты осуществляют процедуру выгрузки копий зарезервированных на сервере виртуальных машин. Также клиенты должны с определенной периодичностью проверять наличие последних обновлений доступных на сервере. Таким образом решается проблема потерявшихся в пути уведомлений. По истечении таймаута клиент самостоятельно спросит сервер и выгрузит последние копии машин. Понятие Клиент и Сервер существуют в рамках одной сессии передачи данных, так как для одних VPS, HW является клиентам(выгружая их с другой машины) для других сервером(предоставляя свои ресурсы гостям). В случае если в дальнейшем появиться желание выделить отдельный сервер для хранения резервных копий, будет достаточно обозначить его как клиента для всех VPS.

Примечания: Уведомления должны передаваться не только в рамках одной широковещательной сети. Гарантии что промежуточные маршрутизаторы поддерживают multicast также нет. Механизм передачи должен позволять контролировать использование пропускной способности сети, на стадии старта Имеется Архив. В него складываются данные которые снимаются единожды и в дальнейшем не требуют обновления. Должна присутствовать возможность сказать клиенту, что он хранит архив, который он самостоятельно синхронизирует согласно представленной выше схеме.

Прошу читателей покритиковать предложенную схему backup. Также если вы знаете об инструментах которые полностью или частично реализуют необходимый функционал, прошу указать их.

На данный момент видятся следующие задачи: Передача файлов между несколькими ВМ, с проверкой контрольных сумм Запус задачи начала процесса резервирования по графику Рассылка и прием notify сообщений

Премного благодарен за любую критику и наводку на инструменты.

Добрый день.

Distrib: Fedora 13
CUPS: 1.4.4

Наблюдаю ситуацию, когда во время старта системы и запуска сервисов не происходит применение содержимого файла cupsd.conf. CUPS стартует нормально, в штатном режиме, но конфигурация которая используется, аналогична той что была при установке системы.

# chkconfig | egrep cups
cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Пытался найти файл в котором указана дефолтная конфигурация:

# locate cups*
/etc/cups/cupsd.conf
/etc/cups/cupsd.conf.default
/etc/cups/cupsd.conf.rpmsave
/usr/share/apps/kdeprint/cupsd.conf.template
/usr/share/man/man5/cupsd.conf.5.gz

После удаления файла /etc/cups/cupsd.conf.default и перезагрузки системы, настройки не подхватились. Предположил что во время правки возможно изменение прав доступа провел процедуру верификации пакета:

# rpm -V cups
.M....... c /etc/cups/subscriptions.conf

# ls -l cupsd.conf*
-rw-r----- 1 root lp 4384 Oct 3 16:26 cupsd.conf
-rw-r----- 1 root lp 4164 Jan 7 2011 cupsd.conf.default

Собственно, значит что все с правами доступа нормально.

Самое удивительное то, что если перезапустить cups командой service cups restart, что в общем должно быть аналогично процессу запуска при старте, файл cupsd.conf читается и новый сервис запускается с применением параметров.

На данный момент рабочая станция перезагружается крайне редко, и один раз выполнить команду проблем не представляет, да и если ее в rc.local добавить все скорее всего будет хорошо.

Но думаю имеется более кошерный способ. Хотелось бы услышать ваши комментарии.

Еще, на Fedora 15 такой проблемы не наблюдается.

Добрый день.

Разбираюсь с моделью функционирования selinux. Но немогу найди достойного описания основных принципов постороения ролей, учетных записей, доменов и т.д. Есть несколько достойных книг на английском языке, но читать методологию на английском не очень получается.

Решений отдельных задач в интернете много, но вот описания методологии работы нет.

Буду признателен за любую ссылку. А также за наставления гуру в данных вопросах.

Ссылки:

http://www.opennet.ru/base/sec/selinux_tips.txt.html

http://www.opennet.ru/base/sec/intro_selinux.txt.html

Здравствуйте, есть следующая проблема:
Необходимо, чтобы пользователь на удаленной машине посредством ssh тунеля мог выполнить скрипт на сервере, не используя команды sudo.

Скрипт на сервере правит таблицу маршрутизации используя утелиту ip. Попытка дать конкретному пользователю права на исполнение данной команды не превели к должному результату. Работает только в случае наличия прав суперпользователя. Дальнейшие изыскания показали что процесс внедрения расширенных групповых политик в ядро заглох, как утверждается за ненадобностью.

Для ясности:

user$: ssh user@server script.sh --- вызов скрипта на сервере
Вводит пароль.

Хотелось бы что бы пользователь немог разрушить систему в случае его плохого настроения. :-)

З.Ы.: Если есть где ответ ткните носом - нипутевого.