Software RAID всегда лучший выбор?

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

Для свопа и временных файлов того же Фотошопа -- легко.

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

Эхх.. вот бы набрать статистику, насколько часто и в каком объёме поситители сего сайта САМИ читают доки, аналитику, рекомендации по внедрению от вендоров, а не только местный топик Talks. :((((((

Есть впечатление, что теперь Админ с большой буквы начинается с установки Linux в фирмочке на 15-20 компов, причем без действительной потребности в работе 24х7 и отсутствием действительно важных данных (ну 1с наверно только). И вся мотивация в уставновке Linux - вырвать хоть чуть чуть рубликов засчёт оупен сорц себе на зарплату.

>САМИ читают доки,

не говорю от всех, но доки читаю всегда перед тем, как за что-либо взяться.

>аналитику, рекомендации по внедрению от вендоров,

не читаю, ибо почти всегда информация искажена в пользу того или иного вендора. Вы уж простите малограмотного, но мне, сирому и убогому быдлоадминишке кажется, что HP не будет советовать внедрять Sun, и наоборот.

>Есть впечатление, что теперь Админ с большой буквы начинается с установки Linux в фирмочке на 15-20 компов, причем без действительной потребности в работе 24х7 и отсутствием действительно важных данных (ну 1с наверно только).

да, пожалуй сейчас я работаю именно в такой фирме, правда работает у меня все именно в режиме 24х7. Да, и админом с Большой Буквы (какой бы ни была эта буква) никогда себя не считал и не считаю.

>И вся мотивация в уставновке Linux - вырвать хоть чуть чуть рубликов засчёт оупен сорц себе на зарплату.

нехороший Вы человек. Я уж и не буду указывать Вам на Вашу ошибку. По крайней мере в данном случае.

gr_buza(*) (24.08.2006 16:57:51):

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

У меня два полуторнотерабайтных RAID0 и один двухсполовинойтепабайтный RAID0 :0. Все софтовое, на SCSI ULTRA320 дисках.

Не всегда ж диски используются просто для хранения данных. Иногда (в нашем случае, например) они используются для очень временного хранения, когда задача в RAM не влезает (RAM'а у нас тоже много десятков гигов, но нужны именно терабайты, к сожалению). И тут главное -- скорость.

угу, ну разве что так.

просто хранить данные в RAID0 может позволить себе только "настоящий мужчина" :))))

gr_buza и в мыслях не было именно Вам это адресовывать... извините Все, за оффтоп... просто вырвалось.. были ситуации восставновления систем после несеръёзного подхода к сохранности данных.. в общем отпостил на эмоциях.

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

Статья правильная. Для разжижения законстеневших мозгов "инженегров", что за сисадминством пяти-десяти сервачков потеряли понимание процесса.

Hardware RAID быстрее Software в простом случае - дохлый(как вариант, перегруженный) процессор + небольшой RAID (пока хватает дохленького процессора RAID-контроллера).

В "больших" же задачах, software RAID будет даже эффективнее (например, если завязать итоговый Volume с нескольких LUN, которые приходят через разные HBA в грамотный страйп), а про фичи я вообще молчу.

биос детектит диски не так?

>> скажите, а вы застали аппаратные переключатели на клавиатурах

>Нет, может быть даже к счастью. Первое что я застал это был keyrus под дос.

Да ладно гнать про "хардварные переключатели а-ля рбильник".

У нас на EC-овских терминалах была клавиша <Рус/Лат>.

Вот и весь тумблер. Ничего никуда не нужно было "перетыкать"

Небось самоделка какая кооперативо-халтурная для писишек у вас была ;)

согласен.
Из моего скромного опыта следует то же самое. При сбое аппаратного рейда можно смело делать харакири. Софтварный рейд универсальнее (его можно поднять на любом соседнем тазике и он заработает 100%), надежнее (вынув 1 винт из mirror я смогу снять с него всю инфу без всякого рейда, а с железным хрен -- он всередину диска лупит свою инфу служебную), дешевле (потому как не стоит ничего вообще).

А сбоев аппаратных рейдов я насмотрелся 8(

есть.
md может быть partitionable уже где-то год.

Но это МЕНЕЕ удобно.

>Ставишь 4 PCI-E х1 двухканальных контроллера, на каждый по 4 диска и ужасаешься тормознутости сетевых карточек

У тя карточки неправильные ;)

Ставь вот такие http://mellanox.com/products/infinihost_iii_ex_cards_mhea281tc.php

;))

Позвольте мне зделать несколько разъяснений насчет шин PCI и PCI-X

По стандарту ширина PCI шины 32 бита и частота 33МГц перемножив получим максимальную теоретическую полосу в 133МБ/с, быстрее ничего передать не удастся по ней.

Шина PCI-X имеет ширину 64 бита и несколько вариантов частот 33/66/100/133 МГц и (тут я могу ошибаться) в спецификации 2.0 266 и 533МГц. Таким образом, если вы видете в документации к мамке PCI-X 133 (как например тут http://www.tyan.com/products/html/thunderk8qw.html), то максимальная теоретическая пропускная способность такой шины 1066МБ/с

Как и PCI, PCI-X - общая шина, то есть все устройства к ней подключенные делят между собой полосу, но в отличие от обычного PCI она автоматически начинает понижать свою частоту при более одного, подключенного к ней устройства, кстати именно по этой причине в особо крутые мамки ставят по нескольку PCI-X бриджев.

Ниже ссылка на счет возможной производительности opteron + pci-x + Linux

http://www.tu-chemnitz.de/informatik/RA/publications/p2005/mietke-pars05-shib...

> > Ставишь 4 PCI-E х1 двухканальных контроллера, на каждый по 4 диска и ужасаешься тормознутости сетевых карточек

> У тя карточки неправильные ;)
> Ставь вот такие
> http://mellanox.com/products/infinihost_iii_ex_cards_mhea281tc.php
> ;))

И на какое расстояние они будут свои 10Гбит выдавать, на 10 метров? А если у меня до коммутатора от фермы метров 70? Даже 16 говенных идешных винтов с линейкой по 70-75 mb/s как раз забьют 1 порт сей байды под завязку, в случае множества коннеков - гораздо быстрее, не говоря уже о 15k-SCSI, а там их всего 2.

>И на какое расстояние они будут свои 10Гбит выдавать, на 10 метров?

На оптике - 300м

All InfiniHost III Ex cards can be directly inserted into PCI Express x8 or wider slots of standard servers, blade servers, storage and communications platforms to enable InfiniBand fabrics. All adapter cards utilize 4X MicroGigaCN InfiniBand compliant connectors for copper cables. This copper connector provides the lowest cost 10 or 20Gb/s connection available. In addition, a pluggable media adapter module can be used for fiber connections up tp _300m_

> 16 говенных идешных винтов с линейкой по 70-75 mb/s как раз забьют 1 порт сей байды под завязку

там 4 порта по 20гигов

То есть вся полоса пропускания шины может быть забита под завязку на раз-два (ну и потом количество PCI-E / PCI-X тоже ограничено)

> При сбое аппаратного рейда можно смело делать харакири.

Да хватит про это уже. Сами виноваты, если у вас такое произошло.

Если у вас нормальный HW RAID, то его конфигурация скидывается его утилиткой на дискету, а шлейфы к дискам и диски пронумеровать (там обычно наклейки идут в комплекте). Для древнего RAID AcceleRAID 170 из 2000 года это верно. Если выгорит контроллер - поднять на таком же на соседнем или этом сервере проблемы не составит.

> По стандарту ширина PCI шины 32 бита и частота 33МГц перемножив получим максимальную теоретическую полосу в 133МБ/с, быстрее ничего передать не удастся по ней.

Вызывающе неверная информация :-) смотри спеки PCI 2.2. Но в остальном вы все очень правильно написали про шины.

Да этот вариант 32 бит и 66МГц я пропустил...

Но все равно чтобы получить 66МГц надо воткнуть эту плату в PCI-X слот ;)

>Если контроллер на шине PCI стоит, то выше 133Мбит в секунду он не прыгнет. кстати не бит, а байт ;)

Если контроллер на шине PCI стоит, то выше 133Мбит в секунду он не прыгнет. кстати не бит, а байт ;)

Да :-) Ошибся. Но вообще, если смотреть по сетевухам, они не прыгают выше средних для большинства 650-700Мбит (у меня прыгали до 840Мбит, но это предел и то при определенных условиях, если сетевуха получает больше данных, чем она может принять-передать, то пропускная падает).

Все зависит от сетевухи, буферов и режима работы - если interrupt-based, то как ни изгаляйся - все упрется в проц, если поллинг - то 2х ксеонов с головой хватит на 4 связанных гигабитных линка, но круто вырастет латентность. Т.е. либо быстрый ответ, либо пропускная способность, и ИМХО в случае толстых данных нужно второе мутить.

> т.е. чтобы не надо былозеркалить партиции, а можно было зеркалить диски

Можо. man mdadm на предмет partitionable array

> AMI MegaRAID, 5 дисков, ОС NetWare 5.1. После остановки шпинделя одного из дисков ... сервер помер.

На трех таких контроллерах диски менять доводилось "на лету" - ничего не падало, Linux 2.4 и 2.6

> А сбоев аппаратных рейдов я насмотрелся

Ага :-) Народ из майлекса как-то раз батарейку вытаскивал, чтобы оно все свои глюки позабыло :-)

Вообще-то, нормальные контроллеры хранят конфигуацию массива не только в eeprom, но и на дисках (так называемый COD).

> А сбоев аппаратных рейдов я насмотрелся

Я насмотрелся глюков и софтовых и аппаратных рейдов, но в софтовом рейде. Но в софтовом есть всякие фишки типа --assemble, --assume-clean, --force итп которые всегда помогали вернуть хотя бы частично данные, а вот когда глючит аппаратный рейд то это пипец. Тем более что половина "аппаратных" рейдов таковыми не являются. Кроме того несколько раз видел глюки бинарных дров производителя. Ну и пример из жизни. Купил один знакомый крутой рейд, а под его ядро не было дров. А generic-ядро нельзя было поставить ибо тогда сломалось бы все остальное. Пришлось железку выкинуть ибо заказывали железку из штатов в Москву и возиться с money back еще дороже вышло бы. Ну и "гигантская" производительность аппаратных рейдов это в большинстве случаев миф. Особенно в raid5. Особенно когда дисков больше сильно больше двух и цена у контролера сильно меньше 1000 баксов :)

PS убил бы promise за tx2000...

> LVM ???

LVM! Только тсс... Пусть это будет нашим секретом. ;)

> Не знаю про Raid5-6-10, но железячный Raid0 сливает софтовому по полной!

Прочитал я и те два топика. Про слабость процессоров на аппаратных raid я как-то даже не думал... :) У меня ещё смешнее ситуация была: попросили хостера в штатах собрать нам сервер, он на ибее купил мамку, процы и остальное, мамка Tyan со встроенным адаптеком, подключили диски, и первое, что я сделал, протестировал параллельную работу винчестеров (их было 2 вначале). Пока читает один или оба -- параллельность нормальная, как только один начинает писать, остальной ввод/вывод останавливается. Переписывался я даже с Justin Gibs, на что он сказал посмотреть errata на тот интелевский чипсет, что в Tyan стоял. Ничего путнего я не нашёл, но мамку сказал заменить, и на Asus с LSI проблема пропала. А 300Mb/s у меня двухканальный LSI на 6 дисках 10k rpm raid-0 вполне давал.

Кстати, кроме проблемы сброса _всех_ кешей, я проблемы с sync не заметил, работает пока не сольёт кеши. У меня были raw devices, так что umount мне бы просто не помог.

Лучше бы довели поддержку s-ata до ума - на некоторых конфигурациях работа с диском (простое копирование/удаление файла) отжирает 100% CPU. При этом, на этой же конфигурации в винде загрузки процессора нет. Мать на i915 от Intel - D915GVWB.

> конфигурация скидывается его утилиткой на дискету

Какую дискетку? Мне что, дисководы в серверах держать? Может еще и сидиромы?

> Для древнего RAID AcceleRAID 170 из 2000 года это верно.

А для современного ADAPTEC'а чего-то нет...

> Если выгорит контроллер - поднять на таком же на соседнем или этом сервере проблемы не составит.

ТО есть везде должен быть один и тот же контроллер? Круто.

На моей практике был случай, когда молния ударила в телефонную линию. Грозозащита испарилась вместе со сплитером DSL модема. На сервере вылетела материнская плата, контроллер от интела и диски выжили. Но вот пятый райд почему-то приказал долго жить. Вытащить данные с пятого рейда, что был закручен на этом сервере, стоило большую кучу дохлых енотов, так как админ той конторы был абсолютно уверен в НАЖЕДНОСТИ хардварного пятого рейда, и никаких бэкапов просто небыло. Так что давайте расставим все точки над "i". Вылететь может все что угодно, и в любой конфигурации. Потерять данные можно на любом райде, как на софтварном, так и на хардварном. У софрварных райдов, как и у хардварных, есть свои слабые и сильные стороны, и выбирать между ними надо с их учетом. А спорить, имхо, просто не о чем, для каждого конкретного случая всегда можно найти оптимальное решение.

Deimos +1

>На трех таких контроллерах диски менять доводилось "на лету" - ничего не падало, Linux 2.4 и 2.6

Да .. вот только незадача ... на Linux 6.5 Btrieve не запустить :(

Casus(*) (24.08.2006 21:25:37):

> А 300Mb/s у меня двухканальный LSI на 6 дисках 10k rpm raid-0 вполне давал.

300Mb/s -- надеюсь, мега БАЙТ/сек, а не мегаБИТ/сек?

Ну, у меня 4 10k rpm. Но LSI (2-х канальный, на PCI-X) дает только Write 153 MB/s Read 256 MB/s, и скорости эти линейно падают с увеличением параллельных читателей/писателей.

Фирмачи на неделю забирали компьютер поиграться; вернув, сказали, что большего не выжать.

Но если я втыкаю диски на SCSI порт на мамке (страйпнутые LVMом), то сразу получаю около 200 MB/s Write и почему-то чуть меньше Read, причем почти независимо от кол-ва параллельных писателей/читателей.

> ...я проблемы с sync не заметил, работает пока не сольёт кеши. У меня были raw devices, так что umount мне бы просто не помог.

Может, именно потому, что raw devices?

Я это сам наблюдал на Альтиксе под Линуксовым XFSом. И в манах написано, что sync возвращается после того, как инициирует процесс записи.

А, вообще, я думаю, это от версии ядра может зависеть.

>> конфигурация скидывается его утилиткой на дискету > Какую дискетку? Мне что, дисководы в серверах держать? Может еще и сидиромы?

Не знаю, но даже в недорогих 1U серверах SuperMicro идут и DVD и FDD.

>> Для древнего RAID AcceleRAID 170 из 2000 года это верно. > А для современного ADAPTEC'а чего-то нет...

Adaptec-у писали? ;-)

>> Если выгорит контроллер - поднять на таком же на соседнем или этом сервере проблемы не составит. > ТО есть везде должен быть один и тот же контроллер? Круто.

У нас он не выгорел, а немного сбоил - при перезагрузке винты иногда не могли раскрутиться, независимо от настроек. Приехали ребята из Тринити и все бесплатно на месте заменили (кстати там AcceleRAID 170 был не стандартный, а какой то несерийный эксклюзив с 256Мб на борту, а современные 3Ware с 64Мб ...).

> 300Mb/s -- надеюсь, мега БАЙТ/сек, а не мегаБИТ/сек?

С чего бы я на дисках стал биты считать? :) Байт, байт. На XFS. Правда потом что-то сломалось (вылетел винт в raid0, при этом смена ядра, оракла) и базу на вновьсозданном XFS oracle отказался читать, и я перенёс её на raw devices.

> Ну, у меня 4 10k rpm. Но LSI (2-х канальный, на PCI-X) дает только Write 153 MB/s Read 256 MB/s, и скорости эти линейно падают с увеличением параллельных читателей/писателей.

elevator=deadline ? Или cfq хотя бы? 10k rpm винт в начале чтения даёт около 60mb/s, к концу диска вроде 40mb/s. Сейчас точно цифры не помню. Так что по чтению у тебя полный порядок, по записи... я ж не знаю как ты пишешь на диск[и], может там журнал, может головой для обновления метаданных дёргать надо, или это raw devices?

> И в манах написано, что sync возвращается после того, как инициирует процесс записи.

Я тоже так думал. Из лохматых юниксовых лет, я вынес, что sync надо запускать дважды, что первый инициирует write out, второй не может завершиться, пока write out не закончится. Но! В Linux всё немного не так, и мне не один раз на это указали: According to the standard specification (e.g., SVID), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

> Не знаю, но даже в недорогих 1U серверах SuperMicro идут и DVD и FDD.

У хьюлеттов сидюшки идут опцией, а о флоповодах - даже не заикаются.

> Но только вот что-то плохо с примерами стораджей объемом более 10T на software raid...

если мне не изменяет память, например, в EMC CLARiiON все RAID реализованы в софте. Самый большой CLARiiON, CX3 80, может быть до 239TB.

> Ну, у меня 4 10k rpm. Но LSI (2-х канальный, на PCI-X) дает только Write 153 MB/s Read 256 MB/s, и скорости эти линейно падают с увеличением параллельных читателей/писателей.
> Фирмачи на неделю забирали компьютер поиграться; вернув, сказали, что большего не выжать.
> Но если я втыкаю диски на SCSI порт на мамке (страйпнутые LVMом), то сразу получаю около 200 MB/s Write и почему-то чуть меньше Read, причем почти независимо от кол-ва параллельных писателей/читателей.

Возможно кэш контроллера забивается быстрее, чем он может сбрасывать на диски (а линукс сим не ограничен - вся свободная и куда более шустрая оперативка к его услугам), и железяка колбасит данные на блины без всякой оптимизации шевелений головками? Скази вроде позволяет отдавать полный контроль над механикой контроллеру.

Отсюда и линейное падение... А линуха все оптимизирует еще в памяти и запись идет практически линейно, а read чуть падает, т.к. механика - не ОЗУ, головки в шахматном порядке не выстроишь и все зависит от самих винтов...

> Может, именно потому, что raw devices?
> Я это сам наблюдал на Альтиксе под Линуксовым XFSом. И в манах написано, что sync возвращается после того, как инициирует процесс записи.
> А, вообще, я думаю, это от версии ядра может зависеть.

sync висит, пока не сбросит все кэши (вообще все что есть, на любые девайсы), что на скази, что на иде, что на сата - особо весело становится при могучем объеме поступающих данных во много потоков, малой оперативке и вызванном чем-то/кем-то sync'е.

> elevator=deadline ? Или cfq хотя бы? 10k rpm винт в начале чтения даёт около 60mb/s, к концу диска вроде 40mb/s. Сейчас точно цифры не помню. Так что по чтению у тебя полный порядок, по записи... я ж не знаю как ты пишешь на диск[и], может там журнал, может головой для обновления метаданных дёргать надо, или это raw devices?

Дедлайн, сцуко такое, очень тяжко переживает параллельные чтение/запись в силу собственного устройства, cfq нужно долго и муторно тюнить, anticipatory в этом плане получше, но у него большой оверхэд по всяких перестройкам очереди на запись => тлеет проц... Для db ставим все же cfq/deadline.

И по идее в случае не-raw устройств периодичность сбоса данных на винт можно выставлять руками на всех основных файловых системах, акромя кажись нашей любимой xfs, коя требует играться с отложенной записью...

> Я тоже так думал. Из лохматых юниксовых лет, я вынес, что sync надо запускать дважды, что первый инициирует write out, второй не может завершиться, пока write out не закончится. Но! В Linux всё немного не так, и мне не один раз на это указали: According to the standard specification (e.g., SVID), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

+1, оно самое.

> если мне не изменяет память, например, в EMC CLARiiON все RAID реализованы в софте.

Ну ты ведь понимаешь, что и в том же LSI Logic RAID реализован в софте. Просто софт этот вертится на Intel XScale IOP...

> Дедлайн, сцуко такое, очень тяжко переживает параллельные чтение/запись в силу собственного устройства, cfq нужно долго и муторно тюнить, anticipatory в этом плане получше, но у него большой оверхэд по всяких перестройкам очереди на запись => тлеет проц... Для db ставим все же cfq/deadline.

Начало абзаца противоречит окончанию :) DB -- самая что ни на есть параллельность записи/чтения и при том из рандомных мест. Deadline, если я правильно помню, плохо работает на потоковых параллельных читателях/писателях, только я не помню, проблема там в скорости или в честности.

А в чём состоит тюнинг cfq? А то я особой магии за ним не помню.

Casus(25.08.2006 0:10:54):

> ...since version 1.3.20 Linux does actually wait.

Может, баги...

Я сам наблюдал это явление. Ядро 2.4 бекпортировано с 2.5.

После выхода из sync какие-то буфера не пусты. При игре с терабайтными файлами umount еще довольно долго жужжит.

> Я тоже так думал. Из лохматых юниксовых лет, я вынес, что sync надо запускать дважды, что первый инициирует write out, второй не может завершиться, пока write out не закончится. Но! В Linux всё немного не так, и мне не один раз на это указали: According to the standard specification (e.g., SVID), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

# hdparm --help 2>&1|grep flush -f flush buffer cache for device on exit

Правда hdparm больше для IDE работает, но может и для SATA/SCSI/RAID ... etc ... заработает.

> Да .. вот только незадача ... на Linux 6.5 Btrieve не запустить :(

А Pervasive SQL for Linux V8 не поможет ? :-)

>Речь идет про контроллер дисков. А это pci/x-pci.

А как же PCI-E ??? Вот тут-то и HyperTransport дает хороший эффект.

>> А по какой еще шине, кроме HyperTransport, чипсет отдает данные на процессор?

>Ой, у меня ксеоны на серваках. Это что выходит у меня процессоры с чипсетом не обмениваются?

Откуда бы тут взяться именно HyperTransport?:)

Все комменты "не асилил", столько чуши сразу - не могу вынести. Поэтому если кто уже на это указывал нашим красноглазым друзьям, звиняйте.

Я о чём? О том, что нужно думать головой. Всегда!

CPU круче, чем проц в контроллере говорите? А какова пропускная способность шины PCI? Или лучше давайте сразу возьмём PCI-X, что бы не так страшно было. Итак, PCI-X 64bit 133MHz даст нам теоретический предел 1GB/s. 2 канала USCSI-4 по 320MB/s сожрут всю эффективную пропускную способность этой шины. Другим устройствам уже шиш! Т.е. сервак может диски молотить, но уже по сети - ни-ни? Странный такой сервак... Или вы видите как ещё организовать обработку RAID-5 на CPU не пересылая данные по PCI? (Про PCIe будете кричать тогда, когда вам в руки попадёт хоть один вменяемый SCSI-контролер на этой шине) Т.е. не о 5-10% паразитной загрузке проца при переносе расчёта КС с RAID-контроллера на CPU идёт речь, а о 50-95% паразитной загрузке PCI (PCI-X) шины.

Разница собствено в чём? Или вы пересылаете по шине ровно столько, сколько нужно записать, или вы пересылаете в 2 (для RAID-1), 3 и выше (для RAID-5) раз больше информации. Тем самым ставя свой сервак на колени. Осталось только ему по-самурайски голову отрубить...

PS. Все истории о проблемах при использовании аппаратных RAID идут либо от бедности, либо от жадности. Ну либо от глупости. Для бедных и жадных - придуман софт-RAID. Для глупых - ничего не поможет. :)

PPS. И не надо говорить про SunFire x4500, это решение именно для бедных. 2GB/s Disk-Memory....

> Начало абзаца противоречит окончанию :) DB -- самая что ни на есть параллельность записи/чтения и при том из рандомных мест. Deadline, если я правильно помню, плохо работает на потоковых параллельных читателях/писателях, только я не помню, проблема там в скорости или в честности.

Именно, но "cfq" - совсем не противоречит ;)

Deadline у нас стоял где-то на простеньких базах, куда загонялись преобразованные из xml результаты каких-то автосборок, что-то в таком духе, подробнее - нужно ковырять разрабов, а мне лениво :) Суть в периодически приходящем большом количестве запросов на запись, но относительно небольшом на чтение и мелком объеме самих данных, а записываться они должны правильно и с гарантией. Ну а anticipatory держит все в кэшах, так что там проблемы с честностью...

> А в чём состоит тюнинг cfq? А то я особой магии за ним не помню.

По типу вот этого: http://nextre.it/oracledocs/ioscheduler_03.html Там еще были байки на эту тему в металинке и у самого Редхэта.