Ну так запатч сорц чтобы в зависимости от того чья запись юзался разный шедулер. Или ты надеешься что у них есть такая же конфигурация? :)

> для остальных на /dev/sda1 - as
> на /dev/sda2, где живет /var - deadline
> на /dev/sda3, где живет своп - noop

А подевайсово и так можно рулить, вон человек написал как шедулеры на девайс менять. Так что боян - фич уже есть.

> И ваще, предлагаю добавить в структуру elf_header поля для привязки екзешника
> к  планировщикам I/O и шыдулеру :D

Ну так сорц тебе в руки и компилер в спину :))

Это одна из техник, вместе с прочими, такими, как в новости, прирост может быть выше.

5-7% это лучше чем 0%. И вообще, это весьма приличный прирост в определенных случаях.

Поэтому какойнить ext4 еще и реализует delayed allocation, в надежде нагрести побольше данных которые можно более-менее линейно записать потом на диск.

Другими словами, это интерфейс для оптимизации работы с данными.

Ага. :) Только народ его в 9'ке увидел:

> http://ivoras.net/freebsd/freebsd9.html
> Generic GEOM IO schedulers
> Status: Committed to -CURRENT
> Will appear in 9.0: sure

При том это диагноз. Гарантирующий на 99.9% что субъект никогда не сможет понять как все это на самом деле работает и почему оно именно вот так. Особо клинические еще и умудряются гордиться своей тупостью, например считая указатели чем-то таким из ряда вон.

В те поры не могли принимать решения для удобства ssd по причине отсутствия таковых :)

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

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

и мне не понятно.
ни разу не попадался.
>Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом".

врёшь как троцкий.
на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся.
драйверов нема.

Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед. Только LO собирать это безумие, бинарный пакет нормально работает.

Неумением понимать, что ценность изменённых (dirty) страниц в кэше диска значительно меньше страниц активных процессов. То есть грубый ляп дизайна MM (VM в терминах BSD).
Появился в 2.1 (для ширнармасс - в 2.2). До этого или не было, или не проявлялся.

Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их вон на выбор есть, а будет еще больше.

В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).

Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень характерный эффект на большинстве бенчмарков ;)

> Чтобы они что-то значали в скорости поиска свободных
> блоков, нужно иметь ФС размером порядка 16 ТБ и больше.

А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто пи...т как дышит. А тебе не приходило в бошку что компактную стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши засираются и прочее, а? Или ты думаешь что все новые дизайнф ФС экстенты стали чисто для красоты использовать? ;)

Ну да, все так. У арчеводов кстати вообще довольно много дельных статей на вике. Молодцы парни, приятно почитать прямо. Кстати там же изложен довольно нахальный по своей изобретательности метод как проверить что trim работает и советы как его включить (его включение позволит ssd работать несколько быстрее при записи больших кусков данных).

> Плохо будет только если компилять на SSD, но этот вопрос я уже решил.

Плохо будет если много писать. От чего именно произойдет эта запись - ssd как-то не сильно важно. По этой причине кстати своп на ssd если и стоит класть то разве что с swapiness = 1, чтобы только на самый крайний случай был. Хотя с 8 гб оный можно просто не юзать совсем, имхо.