|
|
3.71, pavlinux (ok), 17:15, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
А можна на /dev/sda, для MySQL юзать CFQ, а для марьяжа noop ?
для остальных на /dev/sda1 - as
на /dev/sda2, где живет /var - deadline
на /dev/sda3, где живет своп - noop
А можна при (iowait < 5) - юзать noop, а выше переключатся на CFS
А при (iowait < 5) на /dev/sda1, но 10 < loadaverage < 50 y MySQL, переключатся на deadline, выше на CFS, ниже - noop
А можна, всем кто обращается к /var/log, с 3 до 6 утра юзать CFS, остальное время deadline.
И ваще, предлагаю добавить в структуру elf_header поля для привязки екзешника
к планировщикам I/O и шыдулеру :D
| |
|
|
5.94, pavlinux (ok), 19:33, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +4 +/– |
> Ты бы подумал головой? Планировщик IO на разделах одного блочного ус-ва не
> имеет смысла
Ты бы подумал головой? Чем раздел раздел блочного уст-ва отличается
от всего блочного устройства. А так же подумать на темы: Может ли
блочное устройство быть разделом более высшей иерархии. Что такое LVM.
Что такое RAID. Нахера я сюда написал. Зачем я живу.
| |
|
4.79, Аноним (-), 18:03, 11/01/2012 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> А можна на /dev/sda, для MySQL юзать CFQ, а для марьяжа noop?
Ну так запатч сорц чтобы в зависимости от того чья запись юзался разный шедулер. Или ты надеешься что у них есть такая же конфигурация? :)
> для остальных на /dev/sda1 - as
> на /dev/sda2, где живет /var - deadline
> на /dev/sda3, где живет своп - noop
А подевайсово и так можно рулить, вон человек написал как шедулеры на девайс менять. Так что боян - фич уже есть.
> И ваще, предлагаю добавить в структуру elf_header поля для привязки екзешника
> к планировщикам I/O и шыдулеру :D
Ну так сорц тебе в руки и компилер в спину :))
| |
|
|
6.123, Аноним (-), 06:55, 12/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Ну если многое написанное это флудъ, то о динамической смене шедулера при
> простое я б задумался.
Типа, шедулить ничегонеделание накопителя да еще динамически менять алгоритм ничегонеделания? А что, идея. Правда физический смысл этого мне не совсем понятен, наверное это что-то типа нарезки вакуума на дольки ножом.
| |
|
7.153, pavlinux (ok), 23:42, 12/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> Ну если многое написанное это флудъ, то о динамической смене шедулера при
>> простое я б задумался.
> Типа, шедулить ничегонеделание накопителя да еще динамически менять алгоритм ничегонеделания?
> А что, идея. Правда физический смысл этого мне не совсем понятен,
> наверное это что-то типа нарезки вакуума на дольки ножом.
Ну как критерий ничегонеделания, я предложил if ( iowait < 5 )
Смысл переколбашивать приоритеты, очереди, приоритеты очередей, для 5 задач.
Обычная FIFO (noop) быстрее все раскидает.
| |
|
|
|
|
|
|
1.2, klalafuda (?), 21:10, 10/01/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Может быть я конечно ошибаюсь, но разве сегодня кто-то вообще пытается делать оптимизацию дискового IO на основании 'время перемещения головок, зависимость времени записи от расположения данных на диске'? С учетом того, что у всех винтов уже сто лет в обед как на борту по N мегабайт кеша да и AFAIU получить реальную, физическую, геометрию винта - это ещё постараться нужно на уровне фирмваря ибо отрепортить винт может хоть 10ть пластин а реально там стоит скажем две..
| |
|
|
3.8, iZEN (ok), 23:10, 10/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –3 +/– |
> Man NCQ, хотя бы. Относительно свежая технология, встраиванием которой не так давно много кто был заморочен.
И насколько процентов увеличивается производительность совремнных винчестеров при задействовании NCQ? Процентов 5-7, наверное. Как-то несерьёзно. Очередь команд маленькая, чтобы хорошо оптимизировать дисковый I/O.
| |
|
4.12, Аноним (-), 23:39, 10/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> И насколько процентов увеличивается производительность совремнных винчестеров при задействовании NCQ? Процентов 5-7, наверное. Как-то несерьёзно. Очередь команд маленькая, чтобы хорошо оптимизировать дисковый I/O.
Это одна из техник, вместе с прочими, такими, как в новости, прирост может быть выше.
| |
|
|
|
1.7, iZEN (ok), 23:07, 10/01/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –2 +/– |
Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный планировщик I/O, которому в общем-то по барабану, с каким накопилем он работает — с HDD или SSD.
| |
|
|
|
4.40, Аноним (-), 07:49, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> Можно как-то размазывать эту манную кашу порциями, дабы дикого тупизма
> всем и сразу не получилось, но ... шибко это пофик контролеру
> накопителя, он сам умный.
Так цель размазки не сделать ssd быстрее чем он есть, а разделить кашу между получателями относительно честным образом. А не так что один сожрал всю кастрюлю а остальные полдня голодными и злыми сидели.
| |
|
5.62, uniman (?), 15:54, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> И iZen прав, планировщик geom_io действительно простой
>> http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/
>> http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/geom_io.c?revision=2292
> Да, только заявлять, что его простота - это превосходство над Linux глупо.
Найдите хоть слово, где я написал о "превосходство над ХХХ"
Неужели вы нашли в моем тексте такой сферический идиотизм?
> И, кстати, его простота как раз приводит зачастую к тормозам, об
> этом уже не раз упоминалось в списках рассылки.
Рассуждения о "торморзах" неплохо бы подкреплять аргументами.
А то выглядит как путстая трепотня из пустого в порожнее.
| |
|
6.96, xxx (??), 19:34, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Найдите хоть слово, где я написал о "превосходство над ХХХ"
> Неужели вы нашли в моем тексте такой сферический идиотизм?
Это касалось iZen'а и его любви везде упоминать FreeBSD как верх совершенства.
> Рассуждения о "торморзах" неплохо бы подкреплять аргументами.
Разработчики FreeBSD приводят аргументы, см. списки рассылки, BSDCan (гугл).
> А то выглядит как путстая трепотня из пустого в порожнее.
Пуствая трепотня - это рассуждать о планировщиках ввода-вывода Linux и GEOM, не зная их архитектуры и устройства.
| |
|
7.112, uniman (ok), 21:49, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> Найдите хоть слово, где я написал о "превосходство над ХХХ"
>> Неужели вы нашли в моем тексте такой сферический идиотизм?
> Это касалось iZen'а и его любви везде упоминать FreeBSD как верх совершенства.
Не, а че, товарищь в антитезу масссового упоминающим про верх совершенства систему XXX.
>> Рассуждения о "торморзах" неплохо бы подкреплять аргументами.
> Разработчики FreeBSD приводят аргументы, см. списки рассылки, BSDCan (гугл).
Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые".
>> А то выглядит как путстая трепотня из пустого в порожнее.
> Пуствая трепотня - это рассуждать о планировщиках ввода-вывода Linux и GEOM, не
> зная их архитектуры и устройства.
90% _это_ делают на форумах о сиcтеме XXX? И че? :)
| |
|
|
|
|
|
2.20, Аноним (-), 00:53, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
в GEOM намеренно отказались от учёта физических параметров
> винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный
> планировщик I/O, которому в общем-то по барабану
Так вот почему дисковые операции так аццки торбозят на бзде... Я думал это только FFS виновата, а оказывается еще и это.
| |
|
3.22, iZEN (ok), 01:25, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –3 +/– |
> Так вот почему дисковые операции так аццки торбозят на бзде... Я думал это только FFS виновата, а оказывается еще и это.
Тормозили в 2005-2007г.г., когда был GIANT_LOCK. Сейчас этого нет — избавились от глобальных блокировок в ряде ключевых мест.
(Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно? Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом".)
Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков? На Фре это легко и непринуждённо, так сказать, лагов не почувствуешь.
| |
|
4.24, ананим (?), 02:30, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно?
и мне не понятно.
ни разу не попадался.
>Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом".
врёшь как троцкий.
на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся.
драйверов нема.
| |
|
5.38, Аноним (-), 07:46, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –2 +/– |
> и мне не понятно.
> ни разу не попадался.
Мне тоже. Но изену же виднее. Хоть он и видел линуксы только на картинке.
> врёшь как троцкий.
> на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся.
> драйверов нема.
Тсс! Не мешай господам теоретикам обогащать лужи метаном!
| |
|
6.65, Michael Shigorin (ok), 16:06, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> А я вот его частенько ощущаю.
Притащили недавно восьмигиговую USB-флэшку, попросили занулить. Оставил, вскоре отошёл. Прихожу -- даже мышиный курсор не шавелится. Ну, думаю, ОНО. Оставил ещё, благо время обеденное, что ли. Прихожу -- прочухалось.
Флэшка, как коллега и упоминала, навернулась и только делала вид, что принимает данные.
| |
|
7.68, savant (ok), 16:23, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
>> А я вот его частенько ощущаю.
> Притащили недавно восьмигиговую USB-флэшку, попросили занулить. Оставил, вскоре отошёл.
> Прихожу -- даже мышиный курсор не шавелится. Ну, думаю,
> ОНО. Оставил ещё, благо время обеденное, что ли. Прихожу
> -- прочухалось.
> Флэшка, как коллега и упоминала, навернулась и только делала вид, что принимает
> данные.
ещё ощутить можно, если систему загнать в своппинг и пытаться например шариться в интернете. из-за iowait система вполне себе прилегает на "подумать" и это может продолжаться очень долго.
| |
|
|
|
4.60, фтыш (?), 14:53, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
>Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков?
Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед. Только LO собирать это безумие, бинарный пакет нормально работает.
| |
|
5.75, iZEN (ok), 17:50, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>>Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков?
> Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед.
А если не ставить приоритеты? (Я не ставлю.)
> Только
> LO собирать это безумие, бинарный пакет нормально работает.
У меня на этот счёт нет никаких заморочек, поскольку привык собирать всё ПО из дерева портов. Системный Clang, кстати, компилирует ПО быстрее, чем GCC — так, десктопное окружение на Xfce (firefox, thunderbird, gedit, gnome-mplayer и т.д.) с нуля собирается примерно за 3 часа. С GCC на это тратиться 4-5 часов.
| |
|
|
3.63, uniman (?), 16:01, 11/01/2012 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –2 +/– |
> Так вот почему дисковые операции так аццки торбозят на бзде...
Бздя - это новая файловая система в Linux?
Попробуйте использовать ее надлежащим способом или обратиться за советом по использованию.
>Я думал
Интересное наблюдение :)
> это только FFS виновата, а оказывается еще и это.
С добрым утром! На дворе UFS2+journal & ZFS.
Виноваты в глобальном потеплении теперь они.
| |
|
|
|
|
5.157, uniman (ok), 02:19, 13/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?
> Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их
> вон на выбор есть, а будет еще больше.
То есть критерии стратегирования файловой системы вы сформулировать не компетентны.
1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости применения различных планировщиков дискового ввода-вывода? Ну хотя бы что эти планировщики планируют?
Можно с указанием фрагментов исходных текстов. Я пойму.
2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?) что-то не получается в достижении трубуемого отклика и прочих технических параметров от файловых систем?
| |
|
|
7.167, uniman (ok), 22:01, 13/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> То есть критерии стратегирования файловой системы вы сформулировать не компетентны.
> Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители.
Те, в разработке интефейсов к которым вы примете горячее участие.
Впереди планеты всей.
Не теряйте, батенька, времени.
http://www.t10.org/intro.htm
>> Ну хотя бы что эти планировщики планируют?
>> Можно с указанием фрагментов исходных текстов. Я пойму.
> Все исходники есть на kernel.org. Для cfq вроде кто-то ...
... где-то.
Понятно.
PS
Универсальный алгоритм:
- Ваш код гавно!
- Но ты смотрел его?
- Не смотрел, патамучно ваш код гавно!
- Почему?
- Ваш код гавно, а кто так не считает, те казлы!
Opensource world. Next generation.
| |
|
|
|
|
|
|
|
|
|
|
7.115, uniman (ok), 21:59, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
> Еще один неандерталец, который явно не в курсе что у флеша нет
> понятия записи как таковой, а есть расщепление этой операции на две
> взаимодополняющие - erase и program.
Ну спасибо. Теперь буду жить по другому. Стану бриться и перестану ругаться матом.
Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI.
Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже стану носить галстук.
| |
|
|
|
|
|
|
|
2.11, uniman (?), 23:18, 10/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +5 +/– |
> "FIOPS во многом подобен используемому ныне планировщику CFQ, также имеющему несколько
> оптимизаций для твердотельных дисков..."
> Сколько можно говорить, что SSD это не диски, а накопители, ну нету там дисков нет!
... планировщику CFQ, также имеющему несколько оптимизаций для твердотельных квадратиков..." :)
Сорри, не удержался :)
| |
|
|
|
3.44, Аноним (-), 09:14, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов.
Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать?
| |
|
4.73, iZEN (ok), 17:45, 11/01/2012 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
>>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
>>> максимально фрагментируют данные, в противном случае будет чтение из одного модуля
>> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок
>> в группу чипов, размазав записи и чтения на кучу чипов.
> Минимальный блок для записи - 128K вроде как. Сколько там размер сектора?
> 512b. Вот и получаем что для изменения одного битика нужно переписать
> целый блок. В современных ssd конечно cow, но писать всё-равно будет
> одним блоком, правда на другой чип.
В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
| |
|
|
6.77, iZEN (ok), 18:00, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
> В zfs под рейды точили походу,
Не только. ZFS разрабатывали в том числе для использования с SSD. ;) Все эти кширующие техники для ZIL и L2ARC описаны в применении к SSD (с быстрыми SLC и медленными MLC, соответственно).
Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD хорошо и эффективно.
| |
|
7.99, Аноним (-), 19:38, 11/01/2012 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
> хорошо и эффективно.
А майкрософт на своем сайте так и вообще рассказывал что виндус сервер обгоняет линукс. Верить бложику чувака из коммерческой компании? Спасибочки, а ничего что у пиарщиков всегда их продукт самый лучший? Что ж ты будешь делать если услышишь пиар конкурирующих компаний? Неужели разорвешься на 2 части? :)
| |
|
|
|
|
3.72, iZEN (ok), 17:16, 11/01/2012 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
> вам будет икаться от души.
User294, почему ты не логинишься под своим ником? Тебе же сто раз объясняли, что битовые карты никакой существенной роли в производительности записи на ФС не несут. Чтобы они что-то значали в скорости поиска свободных блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
| |
|
4.89, Аноним (-), 19:11, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> User294, почему ты не логинишься под своим ником? Тебе же сто раз
> объясняли, что битовые карты никакой существенной роли в производительности записи на
> ФС не несут.
Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень характерный эффект на большинстве бенчмарков ;)
> Чтобы они что-то значали в скорости поиска свободных
> блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто пи...т как дышит. А тебе не приходило в бошку что компактную стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши засираются и прочее, а? Или ты думаешь что все новые дизайнф ФС экстенты стали чисто для красоты использовать? ;)
| |
|
|
6.106, Аноним (-), 20:46, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Карта свободных блоков — битмапы — кэшируются в ОЗУ.
И что? Это не отменяет нужды читать/писать их на диск (озу знаешь ли не энергонезависимое) и модифиицровать довольно крупные битмапы.
> Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см.
> "FreeBSD. Архитектура и реализация").
Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий бсдун. Остальные это называют окаменелым пометом мамонта.
>> засираются и прочее, а? Или ты думаешь что все новые дизайнф
>> ФС экстенты стали чисто для красоты использовать? ;)
> Экстенты из другой оперы.
Обычно из той же самой. Или уж занятость блоков описывается битмапой, или уж какой-то компактной структурой, например упакованой в дерево.
| |
|
|
|
|
|
|
|
3.45, Аноним (-), 09:25, 11/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Понятно, спасибо. Вообще, я под это дело аж 8 гигов памяти купил на ноут. В итоге в tmpfs переехали не только /tmp, /run, /var, но и сборка всех пакетов ABSом автоматом выполняется в /tmp, все кэши пакетного менеджера там же и кэш браузера (синхрится на винт автоматом, когда нужно).
Так вот я к чему. После всех этих оптимизаций подумываю вернуть журналирование (у меня ext4), а то как-то боязно, да и до настройки бекапов автоматических руки пока не дошли. По различным тестам и замерам (на арчвики, например), количество записываемых данных возрастет лишь на 3%. Плохо будет только если компилять на SSD, но этот вопрос я уже решил.
| |
|
|
|
6.121, Аноним (-), 00:54, 12/01/2012 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Скажем так, не то что бы совсем не бывает по 512, но от модели к модели этот параметр может разниться, да.
А ext4 выбрал по двум причинам: перечитал кучу материала на этот счет, в т.ч. рекомендации OCZ на их форуме, и у меня есть хоть какой-то опыт работы и восстановления данных на ext4, что может пригодиться при отсутствии журнала.
| |
|
|
4.92, Аноним (-), 19:30, 11/01/2012 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> (на арчвики, например), количество записываемых данных возрастет лишь на 3%.
Ну да, все так. У арчеводов кстати вообще довольно много дельных статей на вике. Молодцы парни, приятно почитать прямо. Кстати там же изложен довольно нахальный по своей изобретательности метод как проверить что trim работает и советы как его включить (его включение позволит ssd работать несколько быстрее при записи больших кусков данных).
> Плохо будет только если компилять на SSD, но этот вопрос я уже решил.
Плохо будет если много писать. От чего именно произойдет эта запись - ssd как-то не сильно важно. По этой причине кстати своп на ssd если и стоит класть то разве что с swapiness = 1, чтобы только на самый крайний случай был. Хотя с 8 гб оный можно просто не юзать совсем, имхо.
| |
|
|
2.59, Stax (ok), 14:44, 11/01/2012 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +2 +/– |
CFQ совсем не дурак, он различает винчестеры и SSD (/sys/block/sdX/queue/rotational = 0) и меняет алгоритм. Но настоятельно рекомендуется для SSD в шедулере CFQ включать slice_idle = 0 для перехода в режим IOPS - алгоритм меняется, чтобы он будет сравнивал IOPS'ы, а не время выполнения запроса. (http://www.mjmwired.net/kernel/Documentation/cgroups/blkio-controller.txt)
Это убирает отставание от deadline в линейных скоростях, из-за которого некоторые руководства рекомендуют deadline на SSD, но оставляет все остальные фичи CFQ, вроде шедулинга по группам, вычисление приоритетов шедулинга и т.д.
| |
|
|