Shaohua Li представил (https://lkml.org/lkml/2012/1/4/18) в списке рассылки ядра Linux начальную версию планировщика ввода-вывода FIOPS (от аббревиатуры IOPS - Input/Output Operations Per Second, количество операций ввода/вывода в секунду), предназначенного для работы с твердотельными накопителями и Flash-памятью. В настоящее время патчи носят экспериментальный характер.FIOPS во многом подобен используемому ныне планировщику CFQ, также имеющему несколько оптимизаций для твердотельных дисков, но спроектирован с оглядкой на работу исключительно с Flash-памятью. Например, FIOPS полностью игнорирует такие параметры накопителя как время перемещения головок, зависимость времени записи от расположения данных на диске, учитывает более высокие скорости записи и чтения, зависимость скорость выполнения запроса от его размера и т.д.
В настоящее время реализация имеет ряд проблем и недоработок, таких как отсутствие поддержки ioprio, механизма cgroups, поддержки трассировки, а также автом...
URL: https://lkml.org/lkml/2012/1/4/18
Новость: https://www.opennet.ru/opennews/art.shtml?num=32768
А как одновременно использовать noop и этот ваш fiops?
> А как одновременно использовать noop и этот ваш fiops?Или трусы или крестик. Хотя назначить вон тому девайсу одно, а вот энтому другое вроде как можно.
Можно.$ cat /sys/class/block/sda/queuescheduler
noop [cfq]
$ echo noop > /sys/class/block/sda/queue/scheduler
$ cat /sys/class/block/sda/queue/scheduler
[noop] cfq
$ echo cfq > /sys/class/block/sda/queue/scheduler
$ cat /sys/class/block/sda/queue/scheduler
noop [cfq]
А можна на /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
Отправил ваши пожелания разработчикам. Впредь, пожалуйста, делайте это самостоятельно.
Ты бы подумал головой? Планировщик IO на разделах одного блочного ус-ва не имеет смысла
> Ты бы подумал головой? Планировщик IO на разделах одного блочного ус-ва не
> имеет смыслаТы бы подумал головой? Чем раздел раздел блочного уст-ва отличается
от всего блочного устройства. А так же подумать на темы: Может ли
блочное устройство быть разделом более высшей иерархии. Что такое LVM.
Что такое RAID. Нахера я сюда написал. Зачем я живу.
> А можна на /dev/sda, для MySQL юзать CFQ, а для марьяжа noop?Ну так запатч сорц чтобы в зависимости от того чья запись юзался разный шедулер. Или ты надеешься что у них есть такая же конфигурация? :)
> для остальных на /dev/sda1 - as
> на /dev/sda2, где живет /var - deadline
> на /dev/sda3, где живет своп - noopА подевайсово и так можно рулить, вон человек написал как шедулеры на девайс менять. Так что боян - фич уже есть.
> И ваще, предлагаю добавить в структуру elf_header поля для привязки екзешника
> к планировщикам I/O и шыдулеру :DНу так сорц тебе в руки и компилер в спину :))
> А подевайсово и так можно рулить, вон человек написал как шедулеры на
> девайс менять. Так что боян - фич уже есть.Ну если многое написанное это флудъ, то о динамической смене шедулера при простое
я б задумался.
> Ну если многое написанное это флудъ, то о динамической смене шедулера при
> простое я б задумался.Типа, шедулить ничегонеделание накопителя да еще динамически менять алгоритм ничегонеделания? А что, идея. Правда физический смысл этого мне не совсем понятен, наверное это что-то типа нарезки вакуума на дольки ножом.
>> Ну если многое написанное это флудъ, то о динамической смене шедулера при
>> простое я б задумался.
> Типа, шедулить ничегонеделание накопителя да еще динамически менять алгоритм ничегонеделания?
> А что, идея. Правда физический смысл этого мне не совсем понятен,
> наверное это что-то типа нарезки вакуума на дольки ножом.Ну как критерий ничегонеделания, я предложил if ( iowait < 5 )
Смысл переколбашивать приоритеты, очереди, приоритеты очередей, для 5 задач.
Обычная FIFO (noop) быстрее все раскидает.
Может быть я конечно ошибаюсь, но разве сегодня кто-то вообще пытается делать оптимизацию дискового IO на основании 'время перемещения головок, зависимость времени записи от расположения данных на диске'? С учетом того, что у всех винтов уже сто лет в обед как на борту по N мегабайт кеша да и AFAIU получить реальную, физическую, геометрию винта - это ещё постараться нужно на уровне фирмваря ибо отрепортить винт может хоть 10ть пластин а реально там стоит скажем две..
время позиционирования практически линейно растёт с дистанцией перемещения головок, почти с нуля до 10мс (у медленных мобильных до 20мс)
Man NCQ, хотя бы. Относительно свежая технология, встраиванием которой не так давно много кто был заморочен.
> Man NCQ, хотя бы. Относительно свежая технология, встраиванием которой не так давно много кто был заморочен.И насколько процентов увеличивается производительность совремнных винчестеров при задействовании NCQ? Процентов 5-7, наверное. Как-то несерьёзно. Очередь команд маленькая, чтобы хорошо оптимизировать дисковый I/O.
> И насколько процентов увеличивается производительность совремнных винчестеров при задействовании NCQ? Процентов 5-7, наверное. Как-то несерьёзно. Очередь команд маленькая, чтобы хорошо оптимизировать дисковый I/O.Это одна из техник, вместе с прочими, такими, как в новости, прирост может быть выше.
> Это одна из техник, вместе с прочими, такими, как в новости, прирост
> может быть выше.Это он видимо пытался как обычно сказать "у меня нет, поэтому мне это не нужно".
> Процентов 5-7, наверное. Как-то несерьёзно.5-7% это лучше чем 0%. И вообще, это весьма приличный прирост в определенных случаях.
> NCQ? Процентов 5-7, наверное. Как-то несерьёзно. Очередь команд маленькая, чтобы хорошо
> оптимизировать дисковый I/O.Поэтому какойнить ext4 еще и реализует delayed allocation, в надежде нагрести побольше данных которые можно более-менее линейно записать потом на диск.
NCQ работает с геометрией диска только внутри девайса, со стороны ОС это просто интерфейс поддержки "многопоточности" io для диска. В общем, это как бы совсем не тот пример.
> это просто интерфейс поддержки "многопоточности" io для диска.Другими словами, это интерфейс для оптимизации работы с данными.
Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный планировщик I/O, которому в общем-то по барабану, с каким накопилем он работает — с HDD или SSD.
Судя по книжке? Ой, Великий и Могучий BSDшнег Изен оказывается не читал исходников даже, раз "судя по книжке". А гонору то сколько постоянно, а на деле оказалось... тьфу
Не, в geom есть и "продвинутый" планировщик, с 2008 анонсирован кажись.http://retis.sssup.it/~fabio/freebsd/geom_sched/proto/
# man gsched
NAME
gsched -- control utility for disk scheduler GEOM classSYNOPSIS
gsched create [-v] [-a algorithm] provider ...
gsched insert [-v] [-a algorithm] provider ...
gsched configure [-v] [-a algorithm] node ...
gsched destroy [-fv] node ...
gsched reset [-v] node ...
gsched { list | status | load | unload }DESCRIPTION
The gsched utility (also callable as geom sched ...) changes the schedul-
ing policy of the requests going to a provider.
...
# geom disk list
Geom name: ada0
Providers:
1. Name: ada0
Mediasize: 160041885696 (149G)
Sectorsize: 512
Mode: r6w6e23
descr: ST9160310AS
ident: (null)
fwsectors: 63
fwheads: 16# kldload geom_sched
# geom sched insert -a rr ada0# geom disk list
Geom name: ada0
Providers:
1. Name: ada0.sched.
Mediasize: 160041885696 (149G)
Sectorsize: 512
Mode: r6w6e23
descr: ST9160310AS
ident: (null)
fwsectors: 63
fwheads: 16Все это только и на работающей системе. Как бэ все, шедулер вставлен. Провайдер - этот тот кто сверху и к нам ближе :)
Тестировать с цифирями долго, нужно нескольк дисков, корректно нагрузить, надо думать о корректности измерений, не готов, оставляю пока на других.
http://ivoras.net/freebsd/freebsd9.html
Generic GEOM IO schedulers
Status: Committed to -CURRENT
Will appear in 9.0: sure
Authors: Luigi Rizzo, Fabio Checconi
Web: commit messageThe new framework, integrated with GEOM, allows for multiple disk IO schedulers to be used, if necessary, on different IO providers (e.g. drives). The usage of some IO schedulers can increase responsiveness in certain kinds of IO workloads, for example a mix of sequential and random IO.
http://svnweb.FreeBSD.org/base?view=revision&revision=206497
> Не, в geom есть и "продвинутый" планировщик, с 2008 анонсирован кажись.Ага. :) Только народ его в 9'ке увидел:
> http://ivoras.net/freebsd/freebsd9.html
> Generic GEOM IO schedulers
> Status: Committed to -CURRENT
> Will appear in 9.0: sure
PSишшо с картинками
http://info.iet.unipi.it/~luigi/geom_sched/
Ну не читал - дык я и не припомню чтоб он заявлял де учавствует в разработке подсистемы хранения фряхи .... насколько я помню - он жабщик :)
> - он жабщик :)При том это диагноз. Гарантирующий на 99.9% что субъект никогда не сможет понять как все это на самом деле работает и почему оно именно вот так. Особо клинические еще и умудряются гордиться своей тупостью, например считая указатели чем-то таким из ряда вон.
> Судя по книжке?Вообще полезно изучать иногда историю на предмет принятия того или иного ключевого решения. Почему именно так, а не иначе сделали, чтобы ошибок не повторять.
> Вообще полезно изучать иногда историю на предмет принятия того или иного ключевого решения.В те поры не могли принимать решения для удобства ssd по причине отсутствия таковых :)
> Судя по книжке? Ой, Великий и Могучий BSDшнег Изен оказывается не читал
> исходников даже, раз "судя по книжке". А гонору то сколько постоянно,
> а на деле оказалось... тьфу2005 год
http://www.freebsd.org/doc/ru/articles/5-roadmap/major-issue...
----
GEOM: уровень блоков GEOM был разработан с учётом работы без Giant и он позволяет работать модулям GEOM и низлежащим драйверам блочных устройств без Giant. На данный момент только драйверы ata(4) и aac(4) разделены и работают без Giant. Работа над остальными драйверами блочных устройств ведётся. Изоляция CAM-подсистемы требует отказа от использования Giant практически во всех драйверах SCSI; работа над этим ещё не начиналась. [ сейчас уже закончена ]Кроме того, в GEOM имеется опасность снижения производительности из-за обработки ею вышестоящих и нижестоящих потоков данных в потоках выполнения ядра. В решении этой проблемы может помочь улучшение и упрощение технологии переключения контекстов выполнения.
----И 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_i...Заниматься физикой - не дело GEOM.
Ниже его есть CAM - common access module, а уж он и обчаеться c ata/scsi.http://svnweb.FreeBSD.org/base/release/9.0.0/sys/cam/
И как ни планируй, все одно... если ssd накопитель занят, более они-с принять не могут и посылает драйвер нафик - то нафик так нафик. Можно как-то размазывать эту манную кашу порциями, дабы дикого тупизма всем и сразу не получилось, но ... шибко это пофик контролеру накопителя, он сам умный.
> Можно как-то размазывать эту манную кашу порциями, дабы дикого тупизма
> всем и сразу не получилось, но ... шибко это пофик контролеру
> накопителя, он сам умный.Так цель размазки не сделать ssd быстрее чем он есть, а разделить кашу между получателями относительно честным образом. А не так что один сожрал всю кастрюлю а остальные полдня голодными и злыми сидели.
> И 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_i...Да, только заявлять, что его простота - это превосходство над Linux глупо. И, кстати, его простота как раз приводит зачастую к тормозам, об этом уже не раз упоминалось в списках рассылки.
>> И 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_i...
> Да, только заявлять, что его простота - это превосходство над Linux глупо.Найдите хоть слово, где я написал о "превосходство над ХХХ"
Неужели вы нашли в моем тексте такой сферический идиотизм?> И, кстати, его простота как раз приводит зачастую к тормозам, об
> этом уже не раз упоминалось в списках рассылки.Рассуждения о "торморзах" неплохо бы подкреплять аргументами.
А то выглядит как путстая трепотня из пустого в порожнее.
> Найдите хоть слово, где я написал о "превосходство над ХХХ"
> Неужели вы нашли в моем тексте такой сферический идиотизм?Это касалось iZen'а и его любви везде упоминать FreeBSD как верх совершенства.
> Рассуждения о "торморзах" неплохо бы подкреплять аргументами.
Разработчики FreeBSD приводят аргументы, см. списки рассылки, BSDCan (гугл).
> А то выглядит как путстая трепотня из пустого в порожнее.
Пуствая трепотня - это рассуждать о планировщиках ввода-вывода Linux и GEOM, не зная их архитектуры и устройства.
>> Найдите хоть слово, где я написал о "превосходство над ХХХ"
>> Неужели вы нашли в моем тексте такой сферический идиотизм?
> Это касалось iZen'а и его любви везде упоминать FreeBSD как верх совершенства.Не, а че, товарищь в антитезу масссового упоминающим про верх совершенства систему XXX.
>> Рассуждения о "торморзах" неплохо бы подкреплять аргументами.
> Разработчики FreeBSD приводят аргументы, см. списки рассылки, BSDCan (гугл).Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые".
>> А то выглядит как путстая трепотня из пустого в порожнее.
> Пуствая трепотня - это рассуждать о планировщиках ввода-вывода Linux и GEOM, не
> зная их архитектуры и устройства.90% _это_ делают на форумах о сиcтеме XXX? И че? :)
>Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые".Нет, что ты, они технически аргументировано упоминают о проблемах GEOM.
>90% _это_ делают на форумах о сиcтеме XXX? И че? :)
А opennet чем хуже?
>>Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые".
> Нет, что ты, они технически аргументировано упоминают о проблемах GEOM.О проблемах! Ух как! С каких пор математико-инженерные задачи по продумыванию и написанию логики стали проблемами? Ну если только нечем думать, тоды да - проблема :)
Какое тусово? BSDCan 2005? Giant lock при SMP? Так уже переписали два раза.
Или что-то иное?PS Постарайтесь указывать на цитату, а то получается, слышали звон а вот где он.
Кстати, спасибо - почитал материалы конференции 2011, есть интересные моменты.
> С каких пор математико-инженерные задачи по продумыванию
> и написанию логики стали проблемами?Не вмешиваясь в выяснение благородных донов, отмечу, что по-аглицки "задача" (в т.ч. математическая) и есть "problem". :) Про инженерные зуб не дам, там и "task" проглядывает (ср. IETF). Насколько понимаю, разница в смысле -- примерно вдоль "озарение" vs "докопать".
>> С каких пор математико-инженерные задачи по продумыванию
>> и написанию логики стали проблемами?
> Не вмешиваясь в выяснение благородных донов, отмечу, что по-аглицки "задача" (в т.ч.
> математическая) и есть "problem". :)во-первых, мы не англицкие - годы совдепии изменили лингвистичекую картину настолько, что даже изначально эквивалентные понятия имеют теперь разные смыслы, а заимствованые слова также накладываются на чуждую понятийную систему и мутируют в понятии.
примеров приводить не буду, их есть навалом, кто двуязычен, тот и так поймет, кто одноязычен - много надо рассказывать.
во-вторых, problem в переводе - это очень тяжело/трудно разрешимая ситуация.проблем процесс, как обычно, в голове.
> во-первых, мы не англицкиеРазумеется.
> [...] кто двуязычен, тот и так поймет, кто одноязычен - много надо рассказывать.
А кто три+язычен, тем можно заметить, что данный Вами ниже однозначный перевод заведомо многозначного термина после объяснения семантической неэквивалентности понятийных баз смотрится особо оригинально? :)
> во-вторых, problem в переводе - это очень тяжело/трудно разрешимая ситуация.
Только в учебниках по математике (о которой упомянул) -- это задача и точка.
PS: вспомнилось: "водка хороша, но мясо протухло".
>> во-первых, мы не англицкие
> А кто три+язычен, тем можно заметить, что данный Вами ниже однозначный перевод
> заведомо многозначного термина после объяснения семантической неэквивалентности понятийных
> баз смотрится особо оригинально? :)да нифига оригинального. если в англиском это более трудная ситуация, выкрутиться из которой стоит много средств и усилий, то в русском - все, капец, неразрешимая, будем биться насмерть.
будем и дальше умничать?
> будем и дальше умничать?Будьте добры, почитайте (хотя бы) http://en.academic.ru/dic.nsf/cide/139309/Problem
Вы так трогательно апеллировали к первоисточникам в виде исходников, что я отказываюсь верить своим глазам, когда будучи посланы в словарь -- проявляете чудеса твердолобия.
>> будем и дальше умничать?
> Будьте добры, почитайте (хотя бы) http://en.academic.ru/dic.nsf/cide/139309/ProblemНе буду. У меня стоит dict локально.
Report in wake of phone hacking scandal says contact between officers and journalists has 'not been transparent enough'
A too-close relationship between senior Metropolitan police officers and sections of the media compromises the ability of both to investigate each other, an independent report in the wake of phone hacking has concluded.
...
Это Гардиан, Защитник (перевести попечитель - как-то...), одно из некоторых, которые пробегаю периодически что быть в курсе как и чем дышат в мире. Гардиан, к примеру, желтовата и санта-барбариста, но читать бывает интереснее.И я четко осознаю отличия говорящих "this is problem" и "это проблема", вплоть до придыхания и дальнейшего поведения. В том числе пишущей школо... молодых людей в форумах опеннет.
Я их периодически изучаю, пофлеймить немножко, когда есть время.Будем дальше умничать? Или вы хотите оставить за собой последнее слово? Ок, оно за вами.
PS
https://www.opennet.ru/openforum/vsluhforumID3/82394.html#214Попытался перевести молодому человеку заметку братьев Jolitz 92 года.
Долго мучался как перевести uncumbered - в русскоязычном простанстве легаси-понятия вынесены напрочь, а для америкаца или брита они как дышать.Ответ, как в том анекдоте - "ба, а ше цэ таке було? - цэ море, сынку, море".
"Мы гороховые зерна, ... вот мы вырастили смену"
>>> будем и дальше умничать?
>> Будьте добры, почитайте (хотя бы) http://en.academic.ru/dic.nsf/cide/139309/Problem
> Не буду. У меня стоит dict локально.#155
в GEOM намеренно отказались от учёта физических параметров
> винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный
> планировщик I/O, которому в общем-то по барабануТак вот почему дисковые операции так аццки торбозят на бзде... Я думал это только FFS виновата, а оказывается еще и это.
> Так вот почему дисковые операции так аццки торбозят на бзде... Я думал это только FFS виновата, а оказывается еще и это.Тормозили в 2005-2007г.г., когда был GIANT_LOCK. Сейчас этого нет — избавились от глобальных блокировок в ряде ключевых мест.
(Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно? Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом".)
Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков? На Фре это легко и непринуждённо, так сказать, лагов не почувствуешь.
>Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно?и мне не понятно.
ни разу не попадался.
>Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом".врёшь как троцкий.
на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся.
драйверов нема.
> и мне не понятно.
> ни разу не попадался.Мне тоже. Но изену же виднее. Хоть он и видел линуксы только на картинке.
> врёшь как троцкий.
> на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся.
> драйверов нема.Тсс! Не мешай господам теоретикам обогащать лужи метаном!
А я вот его частенько ощущаю.
> А я вот его частенько ощущаю.Притащили недавно восьмигиговую USB-флэшку, попросили занулить. Оставил, вскоре отошёл. Прихожу -- даже мышиный курсор не шавелится. Ну, думаю, ОНО. Оставил ещё, благо время обеденное, что ли. Прихожу -- прочухалось.
Флэшка, как коллега и упоминала, навернулась и только делала вид, что принимает данные.
>> А я вот его частенько ощущаю.
> Притащили недавно восьмигиговую USB-флэшку, попросили занулить. Оставил, вскоре отошёл.
> Прихожу -- даже мышиный курсор не шавелится. Ну, думаю,
> ОНО. Оставил ещё, благо время обеденное, что ли. Прихожу
> -- прочухалось.
> Флэшка, как коллега и упоминала, навернулась и только делала вид, что принимает
> данные.ещё ощутить можно, если систему загнать в своппинг и пытаться например шариться в интернете. из-за iowait система вполне себе прилегает на "подумать" и это может продолжаться очень долго.
> ещё ощутить можно, если систему загнать в своппинг и пытаться например шариться
> в интернете. из-за iowait система вполне себе прилегает на "подумать" и
> это может продолжаться очень долго.А я думал что она прилегает в основном потому что если процессу понадобились страницы а они вдруг раз и в свопе как назло - процесс трапнется и будет стоять колом, до тех пор пока ядро ему из свопа страниц не выдернет и не пустит его работать дальше, сделав вид что никакого трапа на самом деле не было и вообще вот она, ваша память.
Хинт: да, дисковая память на обычном магнитном диске - это очень медленный эмулятор оперативки. Грешно пользоваться оным и ругаться на то что он тормозит. By design.
> на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся.Эта грабля появилась в Linux 2.1, стукнула по нам со всего размаху с перехода на ядра 2.2 (с хостинга пришлось снять всё, что не было жизненно важно на localhost, включая mysql, и всё равно из-за этого в итоге потеряли половину тогдашних юзеров, пока не смогли проапгрейдить железо на значительно более толстое). В 2.4 она сохранялась в полный рост. В 2.6 её чуть-чуть подлечили, но не радикально.
Сегодня я её наблюдал на 3.1, когда сделал zypper up в виртуалке - через несколько минут хост-система стала колом. Итого, её не могут вылечить более 10 лет.
Ни у одной из опробованных BSD такого нет - у них грамотно расставленные приоритеты и dirty buffer вытесняется вперёд по отношению к working set живых процессов.
Переход на Linux 2.0, где этого не было, разумеется, сейчас не пройдёт, да и незачем, если есть фряха.> врёшь как троцкий.
ты - да. Трындишь не имея ни малейшего представления о фактах.
> (Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно?А это вообще мало кому понятно. Этот баг лезет далеко не везде, иначе его давно бы уже замочили. Более того, вполне вероятно что дуралеи навалили в багтрекер дюжину похожих по симптомам багов под один заголовок. Случается. Кое-какие идеи насчет улучшения латентности операций записи - были поюзаны разработчиками, см. недавние новости. Но совсем не факт что это именно фикс именно того бага и именно в понимании разных его обладателей.
> Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши,
> а в Linux десктоп весь "становится колом".)А у меня почему-то десктоп не становится колом. Странно.
> Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять
> компиляцию, допустим, LibreOffice в несколько потоков? На Фре это легко и
> непринуждённо, так сказать, лагов не почувствуешь.Кто о чем, а вшивый про баню...
>Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков?Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед. Только LO собирать это безумие, бинарный пакет нормально работает.
>>Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков?
> Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед.А если не ставить приоритеты? (Я не ставлю.)
> Только
> LO собирать это безумие, бинарный пакет нормально работает.У меня на этот счёт нет никаких заморочек, поскольку привык собирать всё ПО из дерева портов. Системный Clang, кстати, компилирует ПО быстрее, чем GCC — так, десктопное окружение на Xfce (firefox, thunderbird, gedit, gnome-mplayer и т.д.) с нуля собирается примерно за 3 часа. С GCC на это тратиться 4-5 часов.
> А если не ставить приоритеты? (Я не ставлю.)"А если рельсу?!" (анекдот про японскую пилу vs суровые сибирские мужики)
> Системный Clang, кстати, компилирует ПО быстрее, чем GCCС равным уровнем оптимизации?
> Чем он вызван, интересно?Неумением понимать, что ценность изменённых (dirty) страниц в кэше диска значительно меньше страниц активных процессов. То есть грубый ляп дизайна MM (VM в терминах BSD).
Появился в 2.1 (для ширнармасс - в 2.2). До этого или не было, или не проявлялся.
> Так вот почему дисковые операции так аццки торбозят на бзде...Бздя - это новая файловая система в Linux?
Попробуйте использовать ее надлежащим способом или обратиться за советом по использованию.>Я думал
Интересное наблюдение :)
> это только FFS виновата, а оказывается еще и это.
С добрым утром! На дворе UFS2+journal & ZFS.
Виноваты в глобальном потеплении теперь они.
> Во FreeBSD например, судя по книжке "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров винчестеров, таких, как время перемещения головки.Проще говоря, нормальный планировщик IO там написать так и не осилили.
> Проще говоря, нормальный планировщик IO там написать так и не осилили.Проще говоря, изен как обычно пытается приподнести голожопость как фичу - мол, это не мы бомжи, это так и задумано. И вообще, это такой дизайнерский изыск! Это сейчас так модно!
>> Проще говоря, нормальный планировщик IO там написать так и не осилили.
> Проще говоря, изен как обычно пытается приподнести голожопость как фичу - мол,
> это не мы бомжи, это так и задумано. И вообще, это
> такой дизайнерский изыск! Это сейчас так модно!Для тех кто в танке.
http://ivoras.net/freebsd/freebsd9.html
Generic GEOM IO schedulers
Status: Committed to -CURRENT
Will appear in 9.0: sure
Authors: Luigi Rizzo, Fabio Checconi
Web: commit messageThe new framework, integrated with GEOM, allows for multiple disk IO schedulers to be used, if necessary, on different IO providers (e.g. drives). The usage of some IO schedulers can increase responsiveness in certain kinds of IO workloads, for example a mix of sequential and random IO.
----You _can_ use multiple IO schedule. Пример со вставкой планировщика geom sched на лету уже приводил.
#man gsched
NAME
gsched -- control utility for disk scheduler GEOM classAvailable algorithms
include: rr, which implements anticipatory scheduling with
round robin service among clients; as, which implements a sim-
ple form of anticipatory scheduling with no per-client queue.
> Проще говоря, нормальный планировщик IO там написать так и не осилили.Да, он не планирует за для походы за продуктами в магазин. Это несомненно недостаток.
Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?
> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их вон на выбор есть, а будет еще больше.
>> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?
> Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их
> вон на выбор есть, а будет еще больше.То есть критерии стратегирования файловой системы вы сформулировать не компетентны.
1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости применения различных планировщиков дискового ввода-вывода? Ну хотя бы что эти планировщики планируют?
Можно с указанием фрагментов исходных текстов. Я пойму.
2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?) что-то не получается в достижении трубуемого отклика и прочих технических параметров от файловых систем?
> То есть критерии стратегирования файловой системы вы сформулировать не компетентны.Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители. Ну вот например запускают в производство MRAM. Ты знаешь какие у него физические свойства и какие из-за этого будут требования по их учету к планировщику? Я вот пока слабо представляю себе свойства всего этого.
> 1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости
> применения различных планировщиков дискового ввода-вывода?Да пожалуйста. Физические свойства флеша и вращающихся дисков настолько различны что крайне глупо шедулить их одним и тем же алгоритмом без учета их физических особенностей. Алгоритм для дисков - должен учитывать тормозной seek и стараться минимизировать перемещения голов и/или например "наказывать" тех кто много их гоняет, если допустим цель - относительно честно поделить доступ к диску между всеми. Алгоритм для флеша на seek внимание обращать не должен, а вот потенциальную тормознутость записи в некоторых ситуациях - очень даже неплохо бы учесть. Для каких-то еще типов накопителей оптимально учесть что-то еще.
> Ну хотя бы что эти планировщики планируют?
> Можно с указанием фрагментов исходных текстов. Я пойму.Все исходники есть на kernel.org. Для cfq вроде кто-то даже фрагмент постил - там где проверяется что это rotational media или нет. И алгоритм меняется, соответственно.
> 2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?)
> что-то не получается в достижении трубуемого отклика и прочих технических параметров
> от файловых систем?Да при чем тут файловые системы? Планировщик ввода-выводы делит ресурсы устройства на всех по некоей политике. В лине этому всему уделяют внимание например потому что стоит где-то хост с виртуалками. На нем орда юзеров, допустим. Будет нехорошо, если один юзер из своей виртуалки узурпирует все ресурсы железа, положив остальных на лопатки. Ну понятно что бсдельники далеки от этого (наверное потому что я как-то не видел бсд в роли host в продакшне крутящем кучи юзерских виртуалок за бабки).
>> То есть критерии стратегирования файловой системы вы сформулировать не компетентны.
> Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители.Те, в разработке интефейсов к которым вы примете горячее участие.
Впереди планеты всей.
Не теряйте, батенька, времени.
>> Ну хотя бы что эти планировщики планируют?
>> Можно с указанием фрагментов исходных текстов. Я пойму.
> Все исходники есть на kernel.org. Для cfq вроде кто-то ...... где-то.
Понятно.
PS
Универсальный алгоритм:
- Ваш код гавно!
- Но ты смотрел его?
- Не смотрел, патамучно ваш код гавно!
- Почему?
- Ваш код гавно, а кто так не считает, те казлы!Opensource world. Next generation.
> - Почему?
> - Ваш код гaвно, а кто так не считает, те казлы!А в этом что-то есть. Например, осознать что UFS всего лишь древний помет мамонта с угребищной архитектурой можно просто окинув взглядом общую архитектуру ФС. Читать целиком код этого ископаемого барахла - лишняя работа. Пусть он хоть трижды замечательный на вкус, архитектурной угребищности ФС в целом это не отменяет.
>> - Почему?
>> - Ваш код гaвно, а кто так не считает, те казлы!
> А в этом что-то есть. Например, осознать что UFS всего лишь древний
> помет мамонта с угребищной архитектурой можно просто окинув взглядом общую архитектуру
> ФС. Читать целиком код этого ископаемого барахла - лишняя работа. Пусть
> он хоть трижды замечательный на вкус, архитектурной угребищности ФС в целом
> это не отменяет.Судя по тексту, вы в этом вопросе разобрались. В каком месте код устарел и не отвечает техническим требованиям?
$ ls -l /usr/src/sys/ufs/ufs/
total 708
-rw-r--r-- 1 root wheel 3342 21 Jan 2010 README.acls
-rw-r--r-- 1 root wheel 4549 21 Jan 2010 README.extattr
-rw-r--r-- 1 root wheel 2105 23 Jul 2010 acl.h
-rw-r--r-- 1 root wheel 8526 2 Jan 23:41 dinode.h
-rw-r--r-- 1 root wheel 5848 21 Jan 2010 dir.h
-rw-r--r-- 1 root wheel 5259 17 Oct 18:13 dirhash.h
-rw-r--r-- 1 root wheel 6068 21 Jan 2010 extattr.h
-rw-r--r-- 1 root wheel 1629 21 Jan 2010 gjournal.h
-rw-r--r-- 1 root wheel 7516 2 Jan 23:41 inode.h
-rw-r--r-- 1 root wheel 9510 2 Jan 23:41 quota.h
-rw-r--r-- 1 root wheel 17313 2 Jan 23:41 ufs_acl.c
-rw-r--r-- 1 root wheel 11060 21 Jan 2010 ufs_bmap.c
-rw-r--r-- 1 root wheel 36965 2 Jan 23:41 ufs_dirhash.c
-rw-r--r-- 1 root wheel 34990 17 Oct 18:13 ufs_extattr.c
-rw-r--r-- 1 root wheel 5378 2 Jan 23:41 ufs_extern.h
-rw-r--r-- 1 root wheel 3638 2 Jan 23:41 ufs_gjournal.c
-rw-r--r-- 1 root wheel 6259 2 Jan 23:41 ufs_inode.c
-rw-r--r-- 1 root wheel 41201 2 Jan 23:41 ufs_lookup.c
-rw-r--r-- 1 root wheel 44124 15 Jan 19:56 ufs_quota.c
-rw-r--r-- 1 root wheel 5194 2 Jan 23:41 ufs_vfsops.c
-rw-r--r-- 1 root wheel 70254 2 Jan 23:41 ufs_vnops.c
-rw-r--r-- 1 root wheel 6232 2 Jan 23:41 ufsmount.hPS
Насколько понимаю, вы эксперт по файловым системам. Поэтому вам не составит труда указать.
> Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций
> от аппаратных особенностей усройств хранения?Напротив, сделали планировщик специально для конкретного типа устройств хранения.
> планировщик I/O, которому в общем-то по барабану, с каким накопилем он
> работает — с HDD или SSD.Ага, только проблема в том что для ssd и hdd удобны довольно разные "стили" обмена данными. Например, у SSD нет особого penalty за seek через полдевайса в отличие от винча. Зато ему очень удобно если данные валятся большими блоками, по размеру erase-block флеша и смещение этих данных - по началу блока накопителя. Еще файловая система может подыгрывать SSD высылая ему команду trim, указывающую что "мы больше вон те блоки не юзаем, можешь их подгрести GC'ом когда делать нечего". Сие улучшает скорость записи, т.к. контроллеру ssd приходится не решать проблемы по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу расчистить, чтобы потом по ней "с ветерком" шпарить.
> Еще файловая система может
> подыгрывать SSD высылая ему команду trim, указывающую что "мы больше вон
> те блоки не юзаем, можешь их подгрести GC'ом когда делать нечего".
> Сие улучшает скорость записи, т.к. контроллеру ssd приходится не решать проблемы
> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу
> расчистить, чтобы потом по ней "с ветерком" шпарить.Гм, матчасть...
Вообще-то посылать TRIM - не дело слоя FS с бородатого года. В коде FS это вообще командо для контролеро как бы не обязано фигурировать.
Дело FS - файло по блокам абстрактного массива распихивать. Вот другой вопрос - как, учитывая пару л-тройке логических слоев до реального физического массива.Насчет реализации TRIM ункутри FBSD. Да есть оно.
Насчет как работает - сам не тестировал, все как-то накопители без этого попадаются.К примеру, кусочек кода, где меняется поведение очереди в зависимости от трям/не-трям контролера.
http://svnweb.FreeBSD.org/base/release/9.0.0/sys/cam/ata/ata.../*
* Actually translate the requested transfer into one the physical driver
* can understand. The transfer is described by a buf and will include
* only one physical transfer.
*/
static void
adastrategy(struct bio *bp)
{
.......
/*
* Place it in the queue of disk activities for this disk
*/
if (bp->bio_cmd == BIO_DELETE &&(softc->flags & ADA_FLAG_CAN_TRIM))
bioq_disksort(&softc->trim_queue, bp);
else
bioq_disksort(&softc->bio_queue, bp);
........
}
>> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу
>> расчистить, чтобы потом по ней "с ветерком" шпарить.
> Гм, матчасть...Что - матчасть?
> Вообще-то посылать TRIM - не дело слоя FS с бородатого года.
ФС лучше всех остальных знает когда вон те данные на ФС уже никому не нужны. Стало быть, ей и инициировать это дело.
> В коде FS это вообще командо для контролеро как бы не обязано фигурировать.
Если честно - я не смотрел сорцы как это организовано. Я знаю что как минимум ext4 и btrfs это умеют, как и мое оборудование, и это работает. Если мне попадет шлея под хвост - ну ок, я сунусь и посмотрю как это сделано.
> Дело FS - файло по блокам абстрактного массива распихивать.
Ну так в этом процессе как раз и обнаружится что блоки по адресу от X до Y нам и не требуются уже. Логично захинтить накопитель о том фактк что их можно почистить. Как именно сделана отсылка trim я честно говоря не смотрел. Я только поигрался с этой механикой и заметил что это работает (есть вполне доступные методы проверки).
> Вот другой вопрос - как, учитывая пару л-тройке логических слоев
> до реального физического массива.Если через эти слои можно адресно записывать блоки то почему нельзя их же и чистить?
> Насчет реализации TRIM ункутри FBSD. Да есть оно.
А я то думал что у ней внутри неонка :)
> Насчет как работает - сам не тестировал, все как-то накопители без этого
> попадаются.Практически любой современный ssd например просто обязан trim уметь - фича уже довольно баянистая. А на механическом диске оно как-то и не надо - нет физического смысла. Это всего лишь хинт контроллеру накопителя что он может если хочет заранее стереть эти блоки. Чтобы не пришлось это делать в те моменты когда приперло по причине отсутствия чистых блоков, внепланово просрав скорость записи (erase блока флеша - довольно медленная операция).
>>> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу
>>> расчистить, чтобы потом по ней "с ветерком" шпарить.
>> Гм, матчасть...
> Что - матчасть?
>> Вообще-то посылать TRIM - не дело слоя FS с бородатого года.
> ФС лучше всех остальных знает когда вон те данные на ФС уже
> никому не нужны. Стало быть, ей и инициировать это дело.Иницировать - это да. Может быть.
>> В коде FS это вообще командо для контролеро как бы не обязано фигурировать.
> Если честно - я не смотрел сорцы как это организовано.
> Если через эти слои можно адресно записывать блоки то почему нельзя их
> же и чистить?Блин :) Матчасть. Никто не "чистит блоки". В них есть функ запись, из них есть функ чтения.
Как бэ все.
В метаблоках он может быть помечен как занятый, может как свободный.
Прочитал метаблоки в память, пометил как свободные, синхронизировал метаблоки из памяти на диск - все.Командой TRIM дополнительно информируется SSD при обновлении метаблоков, что, мол, воооон в те блоки с фуфлом в них - можно писать, ну и SSD весело в них пишет, если считает необходимым.
Говорят, это SSD облегчает его нелегкую кремниевую жизнь.Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала с слоем драйверов. То есть пипл старался так делать.
Ну вот теперь традиции меняются :)> Насчет реализации TRIM ункутри FBSD. Да есть оно.
> А я то думал что у ней внутри неонка :)Некоторые так и думают, в своем мире. Судя по комментариям.
>> Насчет как работает - сам не тестировал, все как-то накопители без этого
>> попадаются.
> Практически любой современный ssd например просто обязан trim уметь - фича уже
> довольно баянистая.Да хрен там. Может я такой невезучий. Или может прогресивное человечество ушло вперед, и унесло триманутое SSD с собой.
> Иницировать - это да. Может быть.Ну я при случае залезу в сорц и посмотрю как они это делают. Все-таки любопытно. Что-то не думаю что они там прямо из драйвера ФС напрямую накопителю команды кидают. Это было бы как-то совсем уж по хакерски. Они конечно любят что-то такое отмочить, но не настолько же? :)
>> Если через эти слои можно адресно записывать блоки то почему нельзя их
>> же и чистить?
> Блин :) Матчасть. Никто не "чистит блоки". В них есть функ запись,
> из них есть функ чтения.Неправильно. У флеша есть три различных процедуры. Чтение - ну там все просто и понятно. А вот запись на самом деле является сочетанием 2 взаимодополняющих операций, гоняющих биты ячеек в разные стороны, как то program, когда желаемые данные пишутся в 1 чистую страницу, и erase, когда все страницы erase-блока очищаются одним чихом. CoW логика и уровень трансляции соответственно утрясают такие вот странные свойства своего физического уровня с желанием представить это как якобы диск с какими-то там якобы секторами, которых на самом деле нифига нет. Trim позволяет сборщику мусора контроллера флеша понять что блоки уже не используются и почистить их заранее. В противном случае у сборщика мусора в контроллере есть одна довольно тупая проблема: а он не знает, нужны вам еще вон те данные или уже нет. На них не написано! Как я понимаю, он может сделать выводы лишь на основе логики "если они вот это переписали, оно уже точно было не нужно". Что как-то не слишком оптимально. Trim позволяет реализовывать более удачную упреждащую логику сбора мусора заранее, до того как реально припрет что-то записать и обнаружить что надо оказывается чего-то там перелопатить.
> Как бэ все.
Как бэ щаззз.
> В метаблоках он может быть помечен как занятый, может как свободный.
> Прочитал метаблоки в память, пометил как свободные, синхронизировал метаблоки из памяти
> на диск - все.Я не знаю кто такие метаблоки, но флеш оперирует двумя понятиями - относительно мелкие страницы на 1..4 кило и относительно большие erase block на 64...512 кило.
> Командой TRIM дополнительно информируется SSD при обновлении метаблоков,
> что, мол, воооон в те блоки с фуфлом в них - можно писать,Еще один неандерталец, который явно не в курсе что у флеша нет понятия записи как таковой, а есть расщепление этой операции на две взаимодополняющие - erase и program.
> ну и SSD весело в них пишет, если считает необходимым.
> Говорят, это SSD облегчает его нелегкую кремниевую жизнь.Говорят, что это позволяет контроллеру на ssd понять что вон те блоки уже никому нафиг не нужны и можно заранее их erase'ануть. Это бы все-равно пришлось сделать потом для их использования, но если это делать когда приперло записать туда что-то - так сперва придется дождаться конца erase а только потом делать program. А это медленее чем немедленно вфигачить желаемое (program) в заранее очищенные страницы. С соответствующим результатом для скорости операции "записи" (которая по факту сочетание erase и program).
> Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала
> с слоем драйверов. То есть пипл старался так делать.
> Ну вот теперь традиции меняются :)SSD вообще на диски не похожи. Какой козел придумал что он должен выглядеть как диск я не знаю но он заслуживает прогулки на эшафот. За создание геморроя остальным в "благих" целях обратной совместимости.
>> Насчет реализации TRIM ункутри FBSD. Да есть оно.
>> А я то думал что у ней внутри неонка :)
> Некоторые так и думают, в своем мире. Судя по комментариям.Ну просто мало меня интересуют кишки этой вашей FBSD, просто потому что я не собираюсь ей пользоваться в обозримом будущем. Кишки флешатины или там пингвина - а почему бы и нет, собственно? Я и тем и другим пользуюсь и буду пользоваться в обозримом будущем. Такой я вот редиска.
>> Практически любой современный ssd например просто обязан trim уметь - фича уже
>> довольно баянистая.
> Да хрен там. Может я такой невезучий. Или может прогресивное человечество ушло
> вперед, и унесло триманутое SSD с собой.У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim через смотрение в каком секторе лежит файл, его стирание и смотрение с тем что стало с этим сектором после sync. Правда у них разумеется применительно к линуксу и ext4, насколько их инструкции прокатят для bsd и тамошних ФС я не знаю.
> Еще один неандерталец, который явно не в курсе что у флеша нет
> понятия записи как таковой, а есть расщепление этой операции на две
> взаимодополняющие - erase и program.Ну спасибо. Теперь буду жить по другому. Стану бриться и перестану ругаться матом.
Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI.
Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже стану носить галстук.
> Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI.
> Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже
> стану носить галстук.Подляна состоит в том что нативную механику флеша вывешивать как некий интерфейс зассали и вместо этого сделали какие-то кривые костыли для представления этого как якобы какой-то там диск, похожий на то с чем привыкли работать ОСы. Осознав что в результате этих потуг получилась очень субоптимальная бнопня, сделали еще костылик в виде trim, позволяющий хоть как-то захинтить то что там на самом деле через тот интерфейс что есть. Теперь гланды через зад автогеном стало удалять в два раза забористее, приколитесь? :))
>> Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI.
>> Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже
>> стану носить галстук.
> Подляна состоит в том что нативную механику флеша вывешивать как некий интерфейс
> зассали и вместо этого сделали какие-то кривые костыли для представления этого
> как якобы какой-то там диск, похожий на то с чем привыкли
> работать ОСы.Ну так. Мир несовершенен.
И я бы так сделал. Или вы хотите лет пяток подождать до внедрения SSD c жутко корректным интерфейсом? Писать системный код и отлаживать - проектные затраты, поэтому внедрение идет по пути наименьших стеднепрогнозных потерь на изменения.Для многих встраиваемых систем смена HDD на SSD - уже благое дело, ибо резко повышает надежность по механике.
И значит, благое дело для всех нас, их пользователей.
> Ну так. Мир несовершенен.Ну так. А наша цель - этой механике подыграть. Тому что по факту есть, а не тому маразму через который это вывешено. Ну вот SCSI всего лишь средство, не более.
> И я бы так сделал. Или вы хотите лет пяток подождать до
> внедрения SSD c жутко корректным интерфейсом?Да на самом деле у MS был бы чудный повод продать новую винду лохам с кульной новой фичой, а остальные могли бы быстро и эффективно работать с дисками, удачно раскладывая файловую систему по флешовым сущностям без большого онанизма. Просто тормозные корпорасты как обычно не понимают своего счастья и изобретают вместо этого костыли и подпорки.
> Писать системный код и отлаживать - проектные затраты, поэтому внедрение идет
> по пути наименьших стеднепрогнозных потерь на изменения.Это делается так: берется 2 компа, ставится на один старая винда, на второй новая, на супермодный SSD. Показывается разница во времени загрузки в рекламе. Хомяки фигеют и строятся в очередь. Ну а остальные и сами разберутся. И уж наверное всякие линуксы бы без проблем бы подхватили. Ну во всяком случае поддержку флех прицепленных к процам напрямую они что-то делают вполне оперативно. Хотя если уж на то пошло, редизайнить надо и интерфейс передачи данных - для ssd его может быть мало. Вон некоторые делают ssd на pci-e шину. Потому что sata им не хватает.
> Для многих встраиваемых систем смена HDD на SSD - уже благое дело,
> ибо резко повышает надежность по механике.Зато вносит препротивный лимит на объем записи на носитель. Если на винч можно писать хоть круглосуточно, то вот флехи от этого довольно быстро протираются и вскоре придется заменять флешку, хоть она и угроблена не механически а электрически. А еще они дорогие. Мало того что ssd объема сравнимого с топовыми винчами просто не делают, так еще и что-то хоть издали похожее на таковые стоит как половина самолета.
> И значит, благое дело для всех нас, их пользователей.
Да просто глупо тут то что сначала создали себе проблем а теперь вот героически их решают всякими неочевидными и кривыми костылями типа TRIM. Хотя могли бы и сделать некий набор команд типа ATAPI, но для флех, например. Ну подумаешь, в хучшем случае потребовался бы еще 1 драйвер под +1 тип накопителей. В лучшем таковой драйвер стал бы стандартной частью систем.
> Да просто глупо тут то что сначала создали себе проблем а теперь
> вот героически их решают всякими неочевидными и кривыми костылями типа TRIM.
> Хотя могли бы и сделать некий набор команд типа ATAPI, ноТебя ждали.
> Тебя ждали.Круто!
> Говорят, что это позволяет контроллеру на ssd понять что вон те блоки
> уже никому нафиг не нужны и можно заранее их erase'ануть. Это ...Да неужто? А зачем? Наверное, для того что бы в них можно было что-то записать?
Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают.
Что диск жужжал, и человек мог понять, что он работает.> SSD вообще на диски не похожи. Какой козел придумал что он должен
> выглядеть как диск я не знаю но он заслуживает прогулки на
> эшафот. За создание геморроя остальным в "благих" целях обратной совместимости.Не, товарищи производители должны были подождать, пока все разработчики напишут новый код под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года.
> Ну просто мало меня интересуют кишки этой вашей FBSD
Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние.
Во вторых, ваше право чем-то не интересоваться. Чего писать об этом так уж?
В третьих, какая нахрен разница, код есть код.
> У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim"Ну просто мало меня интересуют кишки этоих ваших арчеводов" :)
> через смотрение в каком секторе лежит файл, его стирание и смотрение
> с тем что стало с этим сектором после sync.Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM. В каком секторе лежит файл. Сильная методика. Жажду ссылки.
>> Говорят, что это позволяет контроллеру на ssd понять что вон те блоки
>> уже никому нафиг не нужны и можно заранее их erase'ануть. Это ...
> Да неужто? А зачем? Наверное, для того что бы в них можно было что-то записать?Да. Потому что в отличие от магнитного диска на флеше нельзя просто взять и перезаписать уже занятый данными произвольно выбранный сектор. У хардов все просто. Сказали перезаписать сектор? Ну он пошел, переместил головы в это место, нашел и перезаписал его. Правила игры флеша совсем иные. И если seek time у флеша близко к нулю и его можно вообще почти проигнорировать, то вот время erase обычно лежит в пределах скольких-то там миллисекунд и попасть на эту операцию в процессе записи данных - довольно нехорошо и ведет к сильной просадке скорости записи. Потому что сколько-то там миллисекунд вместо записи курили бамбук, ожидая пока блок сотрется и станет можно в него что-то записать. У арчеводов с их весьма дельной викой кстати на вике есть весьма доходчивые графики как все это выглядит не только в теории но и на практике - сравнение того что получается с trim и без оного ;)
> Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают.
Некорректная аналогия. В магнитном накопителе сектор можно записывать сразу, без какой-то выделенной процедуры предварительной подготовки оного, выполняемой как некая отдельная сущность в отдельный момент времени. И к тому же винчу не проблема перезаписать только вот эти 512 (или накрайняк 4096) байтов не трогая соседние. А вот ssd в силу своего устройства так не может чисто физически и эмулирует такое поведение крайне извращенскими и неоптимальными действиями. Провокации оного на эти действия следует максимально избегать, если волнует эффективность процесса. А поскольку истинной геометрии нам неизвестно - это избегание превращается в некую черную магию.
> Что диск жужжал, и человек мог понять, что он работает.Какая чудная логика неандертальца ффтыкающего на микроволновку :)
[...]
> Не, товарищи производители должны были подождать, пока все разработчики напишут новый код
> под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года.А что, MS как раз с удовольствием бы пошел барыжить новой системой с суперфичой :). Вообще, ATAPI же как-то внедрили, да? Ну потаскали некоторые системы некоторое время с собой кастомные драйвера cd-rom. А потом драйвера внедрили в все основные ОС и нужда в этом отпала. Не вижу никакой трагедии.
>> Ну просто мало меня интересуют кишки этой вашей FBSD
> Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние.Сами как-нибудь это ваше достояние юзайте. А для меня - поскольку я не собираюсь это использовать, то и детали его внутренней механики волнуют крайне слабо. Разве что как какое-то обобщенное знание, не более.
> Во вторых, ваше право чем-то не интересоваться. Чего писать об этом так уж?
Скорее, не совсем понятно на кой перец лезть с вашей bsd к линухоидам с их планировщиком. Хотя тут скорее больше в огород изена, этот вообще абстрактный теоретик. Флехи он судя по всему только на картинках в книжках видел :)
> В третьих, какая нахрен разница, код есть код.
Да просто не понятно какую самоценность он несет и что это по вашему мнению должно проиллюстрировать.
>> У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim
> "Ну просто мало меня интересуют кишки этоих ваших арчеводов" :)Я это подозреваю, поэтому специально уточняю этот факт, предупреждая о том что эксперимент был опробован под вполне конкретную конфигурацию и работать в других так же не обязан а действия могут отличаться. Вам скорее всего придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу набор действий для FBSD, если вдруг захочется повторить такой эксперимент.
>> через смотрение в каком секторе лежит файл, его стирание и смотрение
>> с тем что стало с этим сектором после sync.
> Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM.Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. EEPROM где-то на совсем базовом уровне похож на "соседний" NOR-флеш, но в отличие от - может писаться хоть отдельными байтами в людском виде. Почему не юзают? Потому что плотность хранения данных никакая. Не надо никому носитель на несколько метров и по цене самолета.
Во вторых, набор команд у SSD вроде как ATA, а не ATAPI.
В третьих, нет, к сожалению напрямую обратиться в чип нельзя. Поэтому методика довольно хакерская и косвенная, продирающаяся через все эти костыли и слои абстракций к реальной физике.> В каком секторе лежит файл. Сильная методика. Жажду ссылки.
Ага, сильная. Я тоже аж удивился. Правда извиняюсь, немного прогнал: ссылка на это у арчеводов, но сам эксперимент все-таки описан на другом сайте.
Арчеводовская вика по теме - https://wiki.archlinux.org/index.php/Solid_State_Drives и я бы сказал что это довольно дельный ресурс, независимо от используемой системы. В том плане что из него понятно в какую сторону и что можно крутить, а как это сделать в вашей системе - сами уже как-нибудь допирайте.
Статья на проверку поддержки TRIM в пингвине - http://techgage.com/article/enabling_and_testing_ssd_trim_su.../
(самое интересное, а именно проверка - на второй странице)
В меру моего понимания, эта проверка довольно сильно закладывается на механику работы файловых систем типа ext4 (как минимум, такой метод проверки имхо не прокатит для CoW файловых систем, а для остальных - в зависимости от того как они стирают файлы и требуют ли почистить при этом область занятую файлом через trim так или иначе) и допускает довольно характерную логику поведения контроллера в ssd, чего разумеется для произвольно взятого ssd никто не гарантирует. Тем не менее, упомянутая там механика и тест вполне работает на конфигурации отдаленно напоминающей авторскую. Ну то-есть, если все отработало как описано у авторов - TRIM определенно есть и работает "по факту", реально расчищая блоки когда об этом попросили.
>> Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают.
>> Что диск жужжал, и человек мог понять, что он работает.
> Некорректная аналогия. В магнитном накопителе сектор можно записывать сразу, без какой-то ...Батенька, вы еще не поняли что это издевка над вашим поучительством?
>> Не, товарищи производители должны были подождать, пока все разработчики напишут новый код
>> под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года.
> А что, MS как раз с удовольствием бы пошел барыжить новой системой
> с суперфичой :). Вообще, ATAPI же как-то внедрили, да? Ну потаскали
> некоторые системы некоторое время с собой кастомные драйвера cd-rom.Стандарт CDROM IEC-19* хрен уже не помню, который потом ISO 9669 - 1986 года.
Стандарт ATAPI, АTA-4/ATAPI, включающий интерфейc к мультимедия CDROM - 1998 год.12 лет. А таки потом сделали их интерфейс АТА и SCSI.
>А потом драйвера внедрили в все основные ОС и нужда в этом отпала.
Гениально!
> Не вижу никакой трагедии.
Точно. Тебе контакт генерального директора Тошибы али Самсунга подсказать, или сам найдешь?
Там такие как ты гении нужны. Не, вдруг на самом все в производстве-индустрии гораздо проще?>>> Ну просто мало меня интересуют кишки этой вашей FBSD
>> Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние.
> Сами как-нибудь это ваше достояние юзайте. А для меняМеня мало волнуют и твои кишки. :)
> придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу
> набор действий для FBSD, если вдруг захочется повторить такой эксперимент.Не, теперь очередь этих, как его арчеводов.
>> через смотрение в каком секторе лежит файл, его стирание и смотрение
>>> с тем что стало с этим сектором после sync.
>> Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM.
> Во первых в флешовых носителях чипы не EEPROM а NAND-флеша.Он знал! Он знал! О великий магистр Йода! :)
Парень, тебя так самодовольно прет от твоих открытый после программирования флеш-чипов, что остальному человечесту просто остается грется в лучах твоего сияния.
[...]
> Батенька, вы еще не поняли что это издевка над вашим поучительством?Да ладно вам, не стесняйтесь, я тоже покушать люблю и вы оказались вполне пригодны, извините уж за честность :)
> Стандарт CDROM IEC-19* хрен уже не помню, который потом ISO 9669 -
> 1986 года.Стандарт ATAPI, АTA-4/ATAPI, включающий интерфейc к мультимедия CDROM - 1998 год.Ага. Правда до этого сидиромы цепляли к звуковухам и было несколько несовместимых интерфейсов. До такого маразма как эмулировать из сидюка винч тогда к счастью не додумались и в результате оно доэволюционировало до чего-то вменяемого.
> 12 лет. А таки потом сделали их интерфейс АТА и SCSI.
Так флеш тоже появился в 80-х годах, если не в конце 70-х.
>>А потом драйвера внедрили в все основные ОС и нужда в этом отпала.
> Гениально!Конечно!
[...]
> Там такие как ты гении нужны. Не, вдруг на самом все в
> производстве-индустрии гораздо проще?Разумеется. Хотя честно говоря я не понимаю чего ои упустили возможность слупить бабла на ровном месте. Мелкомякоть могли бы продавать винду с поддержкой нового интрфейса лузерам за суперцену, производители флещатины тоже в минусе бы не остались, ну и так далее :). Видимо влом им что-то разрабатывать уже. Проще купоны стричь на патентной грызне.
> Меня мало волнуют и твои кишки. :)
Так я и не предлагаю их изучать :P.
>> придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу
>> набор действий для FBSD, если вдруг захочется повторить такой эксперимент.
> Не, теперь очередь этих, как его арчеводов.Угу, арчеводы в отличие от некоторых как ни странно оказались парнями ориентирующимися на фактический результат, а не теоретические бсдения о скази-интерфейсах. Поэтому они будучи дотошными парнями нашли и статейку с описальником как проверить что trim реально работает в некоей конфигурации.
> Он знал! Он знал! О великий магистр Йода! :)
> Парень, тебя так самодовольно прет от твоих открытый после программирования флеш-чипов,
> что остальному человечесту просто остается грется в лучах твоего сияния.Кто ж виноват что такие как вы видели флеш только на картинке, зато потеоретизировать насчет скази и книжек 1999 года - горазды.
>> Стандарт CDROM IEC-19* хрен уже не помню, который потом ISO 9669 -
>> 1986 года.Стандарт ATAPI, АTA-4/ATAPI, включающий интерфейc к мультимедия CDROM - 1998 год.
> Ага. Правда до этого сидиромы цепляли к звуковухам и было несколько несовместимых
> интерфейсов. До такого маразма как эмулировать из сидюка винч тогда к
> счастью не додумались и в результате оно доэволюционировало до чего-то вменяемого.А пока, вы, батенька, предлагагате прицепить флешь-накопители на soundblaster.
Ок. Хорошее предложение, у меня для этого и sb16 остался, вполне еще рабочий.Боюсь только, разработчики и покупатели встраиваемого оборудования ваших мысленных флаек не поймут.
>> 12 лет. А таки потом сделали их интерфейс АТА и SCSI.
> Так флеш тоже появился в 80-х годах, если не в конце 70-х.А спустя 20 лет появился анонимус в форуме на опеннете.
Процесс разработки расширений на стандарты интефейсов идет постоянно.
Открой для себя комитет T13
http://www.t13.orgФперед, с предложениями туда. Там отпушут, куда тебе идти дальше.
>>>А потом драйвера внедрили в все основные ОС и нужда в этом отпала.
>> Гениально!
> Конечно!Вам осталось убедить всего пару-тройку корпораций в вашей гениальности.
Ну хотя бы свою кошку.> Кто ж виноват что такие как вы видели флеш только на картинке,
> зато потеоретизировать насчет скази и книжек 1999 года - горазды.Вы сам-то поняли, батенька анонимус, что написали?
>> Ага. Правда до этого сидиромы цепляли к звуковухам и было несколько несовместимых
>> интерфейсов. До такого маразма как эмулировать из сидюка винч тогда к
>> счастью не додумались и в результате оно доэволюционировало до чего-то вменяемого.
> А пока, вы, батенька, предлагагате прицепить флешь-накопители на soundblaster.Прикольный вывод! Дерзайте! :)
> Ок. Хорошее предложение, у меня для этого и sb16 остался, вполне еще рабочий.
А, круто. Теперь дизайньте контроллер под этот интерфейс, чтоли :)
> не поймут.
А их вообще никто не будет спрашивать, независимо ни от чего.
> Фперед, с предложениями туда. Там отпушут, куда тебе идти дальше.
А что, есть опыт взаимодействия с оными?
> Вам осталось убедить всего пару-тройку корпораций в вашей гениальности.
> Ну хотя бы свою кошку.Прикольно наверное когда у вас кошка - корпорация :)
> Вы сам-то поняли, батенька анонимус, что написали?
Что-то написал. Правда среди этого не было книжек.
>Что-то написал. Правда среди этого не было книжек.Так вы обратились к кому-либо со своими перспективными идеями создать новый интерфейс для флеш-накопителей, или только на опеннет анонимусом горазды?
Результат когда будет?
>>> через смотрение в каком секторе лежит файл, его стирание и смотрение
>>> с тем что стало с этим сектором после sync.
>> Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM.
> Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. EEPROM где-то
> на совсем базовом уровне похож на "соседний" NOR-флеш, но в отличие
> от - может писаться хоть отдельными байтами в людском виде.Вообще-то про NOR все пишут, что оно тоже может байтами писаться. Та же википедия пишет.
Врут?> Почему
> не юзают? Потому что плотность хранения данных никакая. Не надо никому
> носитель на несколько метров и по цене самолета.
> Во вторых, набор команд у SSD вроде как ATA, а не ATAPI.Ну имелось в виду, как я понял, с кастомным обращением не с блочными операциями, а значит - ATAPI.
> (самое интересное, а именно проверка - на второй странице)Проверили, что нули... ничего интересного. Кстати, в случае SCSI спецификации не требуют нули, хотя и рекомендуют.
> Вообще-то про NOR все пишут, что оно тоже может байтами писаться. Та
> же википедия пишет.
> Врут?Зависит от чипа. Зачастую - натурально может (под записью я имею в виду PROGRAM). А иногда только страницами, зависит от конкретиики реализации. Исторически, страничные режимы (для ускорения чтения-записи) появились позже побайтовых (а точнее, пословных, поскольку байт на, допустим, 16-битной шине - нечто довольно странное и не существующее физически). Но даже если запись и можно делать индивидуально, это будет с противной оговоркой: в NOR можно индивидуально спустить битики из 1 в 0 но вот обратно в 1 их загнать можно только ERASE'ом всего огромного блока. Кстати этот фокус позволял штукам типа JFFS писать в NOR 1 байт без стирания несколько раз: если нужное значение делается из того что уже записано только спуском битов - стирать не требуется. В современном мире однако ж чипы чаще всего NAND, а обмен чаще всего только страницами (по поводу чего указанный хак в jffs работать перестал и им пришлось немного переделать эту логику).
У "настоящего" EEPROM наиболее заметное отличие от флеша - отсутствие блоков. Оно адресуется влоб по ячейкам. Стирание и запись ячеек индивидуальны, в отличие от. Туда всегда можно записать любой байт в любую ячейку и это будет сделано без стирания больших блоков. Так намного удобнее для программ, но за это воздается очень низкой емкостью чипа т.к. на кристалле получается намного больше проводников к ячейкам, etc. Поэтому емкость чипов EEPROM не может конкурировать с NOR и тем более NAND, так что они используются там где не надо большой емкости а индивидуальная запись ячеек - удобна.
>> (самое интересное, а именно проверка - на второй странице)
> Проверили, что нули... ничего интересного.Контроллер SSD отпедалил даденый ему хинт и потер блок. Вот так вот через такой хакЪ это и проверили :)
> Кстати, в случае SCSI спецификации не требуют нули, хотя и рекомендуют.
А это вытекает из физики работы флеша, а вовсе не. Это просто стертый блок. Контроллер SSD получив хинт через TRIM, выдал чипу флеша где ранее лежал тот сектор команду на ERASE блока, оттуда и нули (в случае NOR блок стирается наоборот во все единицы, а в NAND вот так вот). На запрос чтения сектора контроллер честно слазил в сектор и доложил что там нули, что и доказывает что упомянутая механика по цепочке отработала :)
>> ну и SSD весело в них пишет, если считает необходимым.
>> Говорят, это SSD облегчает его нелегкую кремниевую жизнь.
> Говорят, что это позволяет контроллеру на ssd понять что вон те блоки
> уже никому нафиг не нужны и можно заранее их erase'ануть. Это
> бы все-равно пришлось сделать потом для их использования, но если это
> делать когда приперло записать туда что-то - так сперва придется дождаться
> конца erase а только потом делать program.Кроме того, это показывает, что если пересобирается новый комплект блоков, то можно указанные блоки не спасать из очищаемого диапазона.
>> Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала
>> с слоем драйверов. То есть пипл старался так делать.
>> Ну вот теперь традиции меняются :)
> SSD вообще на диски не похожи. Какой козел придумал что он должен
> выглядеть как диск я не знаю но он заслуживает прогулки на
> эшафот. За создание геморроя остальным в "благих" целях обратной совместимости.А какая альтернатива? Опишите, пожалуйста, как выглядели бы они при другом подходе.
>[оверквотинг удален]
> Ага, только проблема в том что для ssd и hdd удобны довольно
> разные "стили" обмена данными. Например, у SSD нет особого penalty за
> seek через полдевайса в отличие от винча. Зато ему очень удобно
> если данные валятся большими блоками, по размеру erase-block флеша и смещение
> этих данных - по началу блока накопителя. Еще файловая система может
> подыгрывать SSD высылая ему команду trim, указывающую что "мы больше вон
> те блоки не юзаем, можешь их подгрести GC'ом когда делать нечего".
> Сие улучшает скорость записи, т.к. контроллеру ssd приходится не решать проблемы
> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу
> расчистить, чтобы потом по ней "с ветерком" шпарить.PS
Собственно, поскольку как-то указывать что за ху из ху ниже файловой системы к железяке, приходят к таким решениям. Ну и сотвественно маленько меняется логика FS в отношении нижнего слоя.
# man newfs
....
-t Turn on the TRIM enable flag. If enabled, and if the underlying
device supports the BIO_DELETE command, the file system will send
a delete request to the underlying device for each freed block.
The trim enable flag is typically set when the underlying device
uses flash-memory as the device can use the delete command to
pre-zero or at least avoid copying blocks that have been deleted.
...# less /usr/src/sys/ufs/ufs/ufsmount.h
/* This structure describes the UFS specific mount structure data. */
struct ufsmount {
...
int um_candelete; /* devvp supports TRIM */
...
}# less /usr/src/sys/ufs/ffs/ffs_alloc.c
/*
* Nothing to delay if TRIM is disabled, or the operation is
* performed on the snapshot.
*/
if (!ump->um_candelete || devvp->v_type == VREG) {
ffs_blkfree_cg(ump, fs, devvp, bno, size, inum, dephd);
return;
}И так далее.
# svn log /usr/src/sys/ufs/ffs/ffs_alloc.c
------------------------------------------------------------------------
r216796 | kib | 2010-12-29 15:25:28 +0300 (Wed, 29 Dec 2010) | 16 linesAdd kernel side support for BIO_DELETE/TRIM on UFS.
The FS_TRIM fs flag indicates that administrator requested issuing of
TRIM commands for the volume. UFS will only send the command to disk
if the disk reports GEOM::candelete attribute.Since disk queue is reordered, data block is marked as free in the bitmap
only after TRIM command completed. Due to need to sleep waiting for
i/o to finish, TRIM bio_done routine schedules taskqueue to set the
bitmap bit.Based on the patch by: mckusick
Reviewed by: mckusick, pjd
Tested by: pho
MFC after: 1 monthВ данном примере, если правильно понял, если стоит флаг трим и трям, то битовые операции проводить в снимке системы.
Там еще всякое.
> Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций
> от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке
> "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров
> винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный
> планировщик I/O, которому в общем-то по барабану, с каким накопилем он
> работает — с HDD или SSD.Ему вообще-то не совсем по барабану. Потому что если, например, для диска лифтовый шедулер знает, что сейчас мы пишем блок 1000, в очереди стоит блок 990 от низкоприоритетного процесса, текущее направление лифта - вниз, а поступил заказ на блок 2000 от высокоприоритетного процесса - то шедулер должен решить, достаточно ли новый заказ важен, чтобы сбить логику лифта и погнать его срочно вверх (на 2000), или можно продолжить проход вниз (где ждёт 990) и заставить высокоприоритетный процесс таки подождать. В целом мы будем иметь суммарный вес заказов на текущее направление движения и суммарный вес заказов на перебой направления. TQ и NCQ слегка устраняют эти проблемы, при условии, что текущая очередь не превышает их предельной глубины очереди (до 255 у SCSI TQ и до 31 у NCQ), но если заявок больше, то всё равно приходится начинать думать. А для SSD это всё не имеет никакого значения, всё равно не угадаешь, что там внутри в текущую минуту как разложено. Особый цимес конструированию шедулеров придают задачи обеспечения одновременно скорости важного потока и периодических мотаний туда-обратно головками для других важных операций... в общем тут можно полировать и вылизывать годами.
Когда Вы говорили про время перемещения головки, вспоминали особенности старых дисков (грубо говоря, до времён PC, а вместо этого на PDP-11 или аналогах), которые были особо медленными, зато можно было угадать, что вот прямо сейчас мееедленно подползает блок 2 на дорожке. Да, с введением внутренних трансляций геометрии, мультизонных дисков с разной плотностью (это где-то от рубежа 400MB) это всё потеряло смысл окончательно, сейчас по LBA невозможно установить, в какой момент надо подавать какой блок на запись. Можно только предсказать положение головок, и это работает надёжно, по крайней мере пока нет ремапов. А при TQ и NCQ - весь текущий пул запросов будет отработан диском. Но, как я описал выше, это далеко не все проблемы.
Упрощение в FreeBSD по текущему моменту вызвано фактически тем, что у операций I/O нет приоритета, который бы каким-то образом вычислялся из приоритета их заказчика. Если их введут, то придётся снова серьёзно думать о выборе шедулера.
> Упрощение в FreeBSD по текущему моменту вызвано фактически тем, что у операций I/O
> нет приоритета, который бы каким-то образом вычислялся из приоритета их заказчика.
"FIOPS во многом подобен используемому ныне планировщику CFQ, также имеющему несколько оптимизаций для твердотельных дисков..."
Сколько можно говорить, что SSD это не диски, а накопители, ну нету там дисков нет!
> "FIOPS во многом подобен используемому ныне планировщику CFQ, также имеющему несколько
> оптимизаций для твердотельных дисков..."
> Сколько можно говорить, что SSD это не диски, а накопители, ну нету там дисков нет!... планировщику CFQ, также имеющему несколько оптимизаций для твердотельных квадратиков..." :)
Сорри, не удержался :)
... твёрдотельных параллелепипедов. ;)
> ну нету там дисков нет!А винчестер - это вообще винтовка!
Винчестер - это многовариантное слово: от фамилии/названия компании до предмета.
карабин.
И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые максимально фрагментируют данные, в противном случае будет чтение из одного модуля и привет 20MB/s ;)
> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
> максимально фрагментируют данные, в противном случае будет чтение из одного модуляВообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов. Плюс буфера и у ос и у накопителя, скорость трансфера в которые порядка скорости sata линка.
> и привет 20MB/s ;)
Теоретик хренов. А с фрагментами все не так просто. Чтобы было оптимально, блоки должны попадать точно в erase-блоки и размер фрагмента должен быть кратен erase-блоку. Иначе для записи придется стирать 2 блока вместо одного. И дольше, и wearing в 2 раза увеличивается - ssd подохнет быстрее.
В каком-нить ext4 есть даже средства позволяющие захинтить файловой системе желаемый размер одного обмена с накопителем в не менее чем вон столько. Хоть это формально и для рэйдов, для которых удобнее чтобы блоки по очереди валили на разные диски, никто ж не запрещает и для ssd фичу юзать, избавив ssd от кучи мелких записей, неоптимальных для оного.
А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый на педалинг огромных битовых карт и прочих бестолковостей на ssd будет роялить еще больше. Поэтому древность и костыльность структур ФС и тут вам будет икаться от души.
> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов.Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать?
Они оптимизируют разные вещи. Напр. блок управления карбюратором машины управляет впрыском топлива, и ему безразлично куда едет машина. Можно ли сказать что т.к. карбюратор оптимизирует работу двигателя, то не требуется оптимизировать маршрут поездки? Нет.
> Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда
> контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать?В идеале можно попробовать подогнать смещение файловой системы под erase block и стараться оперировать блоками размером с оный. На практике сие больше смахивает на черную магию, поскольку внешне все карточки, флешки и ssd пытаются выглядеть как якобы простые диски с якобы 512 байтными секторами, а свою истинную геометрию не сообщают. А на самом деле 512 байтных секторов вообще там ни разу нет и запись 512 байтов выльется в как минимум read-modify-write какой-то страницы, а это обычно 1...4Кб, что явно более 512 байтов и вообще целая свистопляска для контроллера вместо атомарной операции. А в хучшем случае будет вообще стирание большого erase block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)
> запись 512 байтов выльется в как минимум read-modify-write какой-то страницы, а это обычно 1...4Кбстраница 2kb. Запись идёт блоком из 64 страниц, а чтение действительно постранично.
> А в хучшем случае будет вообще стирание большого erase
> block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно
> масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)Выкиньте свой jmicron в помойку. В современных накопителях давным давно cow с gc и что там творится в реальности знает только контроллер. Любая запись там выглядит как read-modify-write, если пользовать trim есно. Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи будет все лишь один read с пачкой modify и одним write в заранее чистый блок. А чтобы чистых блоков вообще не было - так это имхо нужно забить весь накопитель к чертям и банально писать поверху. А так, любая передышка, и gc собирает мусор очищая блоки.
> страница 2kb.Разная у разных флех. У мелких бывает и 1 кб. У очень больших бывает 4. Или ты посмотрел даташт на конкретную флеху и возомнил что только так - вообще везде? Прут меня виндузятники своей непосредственностью. Дикарь с копьем который увидел микроволновку и судорожно пытается втиснуть в свою примитивную модель мира такую неведомую фигню как магнетрон.
> Запись идёт блоком из 64 страниц, а чтение действительно постранично.
У разных чипов флешек число страниц на erase block бывает разным. В мире нет какой-то универсальной константы, описывающей размер страницы или erase block как единственно верные константы мирового масштаба. В лучшем случае у флешек одного поколения они примерно одинаковы. Но это не гарантированно. Лично я в курсе и иных сочетаний. Вон у упомянутых арчеводов например где-то в вике упоминается страница в 4К, 128 страниц на блок. Т.е. 512 К на блок. Подумаешь, в 4 раза присвистнул и указал неоптимальный размер блока. Кстати запись постранично тоже возможна, но с одной большой оговоркой: записываемая страница должна быть чистой. А вот с этим засада. Из-за физических особенностей флеша, стирать его можно только большими блоками. Если в страницу уже что-то записано, ее нельзя стереть отдельно от остальных в этом erase block. Можно закатить erase для всего erase block целиком, тогда все страницы блока очистятся. Отсюда следует что erase для записи страницы требуется не всегда, но в хучшем случае действительно нужен.
Кстати да, питекантроп пытающийся осознать как работают наши магнетроны соверщенно забыл про то что у флеша erase - это отдельная логически осмысленная процедура, являющаяся отдельной сущностью. Trim имеет непосредственное отношение к оной процедуре. Erase это не чтение и не запись в их привычном понимании. Это приведение всех страниц erase-block'а в чистое состояние.
>> А в хучшем случае будет вообще стирание большого erase
>> block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно
>> масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)
> Выкиньте свой jmicron в помойку.Какой еще jmicron? Упомянутый спич является обобщением логики работы всей этой механики вообще. В том плане что по другому это как-то не особо то и сделаешь, даже самый хитрый контроллер будет реализовывать похожую логику и ничего не сможет поделать с тем фактом что флешу удобно работать целыми erase-block'ами или хотя-бы страницами. Выравнивание на erase-block лучше тем что ведет к избеганию ситуации когда контроллеру для всего блока надо будет сделать read-erase-modify-write, чтобы оформить частичную модификацию erase блока во что-то физически существующее.
> В современных накопителях давным давно cow с gc и что там творится в реальности
> знает только контроллер.Это не отменяет того факта что ему тоже удобнее всего фигачить блоками размером с erase block с правильным выравниванием. Просто потому что даже самый умный контроллер ничего такого сделать с физической природой флеша не может. Он может заныкать от вас служебное действо когда запись менее чем удобная величина ведет к read-modify-(иногда erase)-write, но отменить его и сделать чудо он не может. Trim позволяет реже нарываться на нужду erase при записи, давая контроллеру хинт что если он хочет то может в фоне вон те блоки и почистить, т.к. они не нужны. А erase довольно тормозная операция.
> Любая запись там выглядит как read-modify-write, если пользовать trim есно.
Wrong. Самый удачный вариант ака достаточно большая запись и только в чистые страницы будет просто программированием этих страниц. Быстро и без проблем. Trim нужен как раз для того чтобы дать шанс контроллеру заранее подчистить неиспользуемые блоки и по возможности создать именно эту, самую удачную для записи ситуацию.
> Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи
> будет все лишь один read с пачкой modify и одним writeУважаемый дикарь в попытках осознания процесса работы магнетрона напрочь забывает о том что у флеша есть read, program и отдельная операция известная как erase. Program и erase - две логически дополняющие друг друга сущности, грубо говоря, тягающие биты ячеек в разные стороны (одна в одно состояние, вторая в другое). По разным правилам игры, вытекающим из физического устройства флеша. Program вгоняет биты страницы в те значения которые хочется получить. А вот обратно их вернуть можно только erase'ом всего здорового блока. Если интересно - см. в английской вике, тем вполне дельно разжевано откуда такая странная брейнфакерская логика берется - она вытекает из того как биты хранятся в ячейках флеша.
> в заранее чистый блок. А чтобы чистых блоков вообще не было
> - так это имхо нужно забить весь накопитель к чертям и
> банально писать поверху.Достаточно чтобы gc вовремя не подсуетился. Тогда ему придется делать erase прямо на ходу и скорость записи просядет, что логично. Trim нужен чтобы этого максимально избегать, выдавая хинты контроллеру что он может уже стирать вон те блоки. Не дожидаясь того момента когда припрет, так что надо бы записать, а чистых страниц что-то нету, так что давайте судорожно расчищать прямо сейчас (а запись соответственно подождет до лучших времен).
> А так, любая передышка, и gc собирает мусор очищая блоки.
Вот только проблема в том что сам по себе gc как-то не очень то и знает - нужен вон тот кусок данных файловой системе, или уже можно его в расход. Вот trim как раз и позволяет gc приобрести это знание и действовать именно так, заранее расчищая блоки. Упреждая ситуацию когда приперло и надо чистить блоки прямо в процессе записи, тормознув запись.
> В идеале можно попробовать подогнать смещение файловой системы под erase blockНе "в идеале", а "для начала". Иначе и SSD, и 4k-HDD, и RAID5/6/50/60 будут тормозить, цепляя лишние erase block'и/секторы/шпиндели.
> Не "в идеале", а "для начала". Иначе и SSD, и 4k-HDD,
> и RAID5/6/50/60 будут тормозить, цепляя лишние erase block'и/секторы/шпиндели.Грабль состоит в том что для флеша это довольно сложно, поскольку истинную геометрию нам не показывают и есть минимум 2 сущности разного размера да еще CoW логика. Поэтому достоверно определить как наши действия состыкуются с внутренней механикой можно только серией хитровыгнутых экспериментов, которые к тому же в зависимости от логики контроллера совершенно не обязаны давать одинаковые или даже просто осмысленные или воспроизводимые результаты.
Кстати если какое-нибудь там начало раздела и партишн тейбл еще можно осмыленно разложить, выбрав выравнивание так чтобы сие было явно кратно erase block (просто считая его кратным достаточно большому 2^N, например 512Кб выравнивание устроит как тех у кого он 512Кб, так и тех у кого блок в 256 или 128Кб) то вот например осознать как там будут блоки с данными ФС расположены - уже не так легко. А вы это в состоянии для ну хотя-бы ext4? В том плане что граница 4k блока EXTа должна бы совпасть с границей страниц флеша. Но вот проверять это... хм... а существует какой-то удобный и автоматизированный метод? И кроме того - а известен ли метод смещать блоки с данными относительно начала раздела?
>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
>> максимально фрагментируют данные, в противном случае будет чтение из одного модуля
> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок
> в группу чипов, размазав записи и чтения на кучу чипов.Минимальный блок для записи - 128K вроде как. Сколько там размер сектора? 512b. Вот и получаем что для изменения одного битика нужно переписать целый блок. В современных ssd конечно cow, но писать всё-равно будет одним блоком, правда на другой чип.
>> и привет 20MB/s ;)
> Теоретик хренов.Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.png
> А с фрагментами все не так просто. Чтобы было оптимально,
> блоки должны попадать точно в erase-блоки и размер фрагмента должен быть
> кратен erase-блоку. Иначе для записи придется стирать 2 блока вместо одного.
> И дольше, и wearing в 2 раза увеличивается - ssd подохнет
> быстрее.Это пусть у контроллера голова болит, они шибко умные нынче пошли.
> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
> вам будет икаться от души.Только почему-то на этой самой ntfs всё работает хер знает когда, показывает пиковую производительность, а в линупсе только сейчас осознали что что-то не так в консерватории. Неужели так долго копили на ssd для тестов? :)
>>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
>>> максимально фрагментируют данные, в противном случае будет чтение из одного модуля
>> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок
>> в группу чипов, размазав записи и чтения на кучу чипов.
> Минимальный блок для записи - 128K вроде как. Сколько там размер сектора?
> 512b. Вот и получаем что для изменения одного битика нужно переписать
> целый блок. В современных ssd конечно cow, но писать всё-равно будет
> одним блоком, правда на другой чип.В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).В zfs под рейды точили походу, а на ufs2 + gstripe я тоже делал 64k, страйп быстрее работал.
>> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
> В zfs под рейды точили походу,Не только. ZFS разрабатывали в том числе для использования с SSD. ;) Все эти кширующие техники для ZIL и L2ARC описаны в применении к SSD (с быстрыми SLC и медленными MLC, соответственно).
Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD хорошо и эффективно.
> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
> хорошо и эффективно.А ссылочку можно? Мне конечно ssd во фряхе пока не грозит, но мало ли что случится в ближайшем будущем ;)
>> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
>> хорошо и эффективно.
> А ссылочку можно? Мне конечно ssd во фряхе пока не грозит, но
> мало ли что случится в ближайшем будущем ;)О перспективах ZFS и флэш-памяти: http://blogs.oracle.com/jonathan_ru/entry/о_перспективах_zfs_и_флэш
Ещё может пригодиться:
A look at MySQL on ZFS: http://habrahabr.ru/blogs/mysql/78473/
Объяснение ARC и L2ARC: http://blog.tigranav.ru/2010/11/obyasnenie-arc-i-l2arc/
> Не только. ZFS разрабатывали в том числе для использования с SSD. ;)Ага, правда SSD в природе не было в момент дизайна ZFS, но изена такие мелочи не волнуют, как обычно. Он лучше будет маркетинговый булшит от санок повторять как мантру, ведь верить в это намного приятнее, правда? :)
>> Не только. ZFS разрабатывали в том числе для использования с SSD. ;)
> Ага, правда SSD в природе не было в момент дизайна ZFS, но
> изена такие мелочи не волнуют, как обычно. Он лучше будет маркетинговый
> булшит от санок повторять как мантру, ведь верить в это намного
> приятнее, правда? :)Там другое. Например, группировка сбросов на диск по их рейтингк.
ttp://constantin.glez.de/blog/2011/02/frequently-asked-questions-about-flash-memory-ssds-and-zfs
ZFS also has a sophisticated cache called the "Adaptive Replacement Cache" (ARC) where it stores both most frequently used blocks of data and most recently used ones. The ARC is stored in RAM, so each block of data that is found in the RAM can be delivered quickly to the application, instead of having to fetch it again from disk. When RAM is full, data needs to be thrown out of the cache and is not available any more to accelerate reads.
SSDs can be used as a second level cache: Blocks that can't be stored in the RAM-based ARC can then be stored on SSDs and in case they're needed, they can still be delivered quicker to the application than by fetching them again from disk. An SSD that is used as a second level ARC is therefore called an L2ARC, or a "cache device".Поэтому жретъ памяти, зараза :)
> therefore called an L2ARC, or a "cache device".
> Поэтому жретъ памяти, зараза :)Если честно, я в этом спиче не вижу ни 1 звука про собственно саму оптимизацию записи на SSD. То-есть рассказали про то что они умеют юзать как кеш. Ну круто. Но ни звука про то как запросы к ФС оптимизируются на предмет минимального протирания SSD и максимальной скорости работы оного. И ниоткуда не следует что кеш обязан по дефолту сливаться на диск в виде оптимальном для SSD.
>> therefore called an L2ARC, or a "cache device".
>> Поэтому жретъ памяти, зараза :)
> Если честно, я в этом спиче не вижу ни 1 звука проНе видите звуков? Оригинально. Попробуйте пощупать код на слух.
> Не видите звуков? Оригинально. Попробуйте пощупать код на слух.Тоже не слышно ничего. Поэтому процитируйте плиз где там про оптимизацию процесса записи на SSD хоть слово вообще. То что ssd в роли кеша работает лучше механики - так это не только парни из сана заметили, прикиньте? Кстати мне вот интересно - а быстро ssd там до дыр затирается?
>> Не только. ZFS разрабатывали в том числе для использования с SSD. ;)
> Ага, правда SSD в природе не было в момент дизайна ZFS, но
> изена такие мелочи не волнуют, как обычно.Вообще-то у ZFS сейчас идёт уже где-то 15-я минимум версия пула - это раз.
Флэшовые накопители были уже много лет - это два. Да, у них не было умного контроллера, ремапа по обстоятельствам и так далее, но часть проблем была уже известна.> Он лучше будет маркетинговый
> булшит от санок повторять как мантру, ведь верить в это намного
> приятнее, правда? :)Урежьте осетра.
> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
> хорошо и эффективно.А майкрософт на своем сайте так и вообще рассказывал что виндус сервер обгоняет линукс. Верить бложику чувака из коммерческой компании? Спасибочки, а ничего что у пиарщиков всегда их продукт самый лучший? Что ж ты будешь делать если услышишь пиар конкурирующих компаний? Неужели разорвешься на 2 части? :)
> Минимальный блок для записи - 128K вроде как.Минимальный блок для записи у флеша - страница. Обычно 1...4Кб у nand-флешек из которых делается все и вся, от карт памяти до могучих ssd.
> Сколько там размер сектора? 512b.
Да хрен тебе, теоретик. У флеша нет 512-байтовых секторов. Совсем. Они эмулируются совершенно адскими высерами контроллера с read-modify-write. Кстати это же объясняет почему у некоторых господ иногда странно теряются данные. Вплоть до того что на картах памяти и юсб флехах с FATом изредка у некоторых господ очень неудачно слетает все что угодно, вплоть до таблицы разделов. Если таблица разделов попала в тот же erase-block что и например кусок FAT и питальник неудачно слетел, так что read-modify-write срубился в самом начале, кусок с MBR и таблицей разделов может и не успеть записаться. И если то что FAT должен был пострадать за то что перезаписывался в этотм момент - логично, то вот то что MBR пострадает лишь за то что его угораздило жить в том же erase block - куда менее очевидный и намного менее приятный факт :). По этой причине кстати фабричный формат на флешках и картах довольно характерно выравнивает ФС на характернуые величины, кратные 2^N, по размеру erase-block разумеется.
> Вот и получаем что для изменения одного битика нужно переписать
> целый блок. В современных ssd конечно cow, но писать всё-равно будет
> одним блоком, правда на другой чип.А тут ты как ни странно не прогнал. Проблема только в том что один хрен загаженный блок стирать придется. Не сейчас, так потом. Единственное чего можно выиграть в стирании его не сей момент а в фоне - скорость записи. Это как езда по дороге со снегом. Если перед тобой медленно тащится снегоуборщик - понятно какая скорость езды получится. А если он заранее проехал, скорость будет другой :)
> Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте
> даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.pngГражданин, не наглей, да? Я не только читал гору даташитов на всевозможный флеш, я еще и программировать эти самые чипы флеша умею. Вплоть до того что я лично реализовал процедуру зашивки нескольких чипов, покурив даташиты, когда приспичило. Приколись, а? Если ты такой умный и даже даташитами козыряешь - ну покажи, в каком месте ты 512 байтные сектора у флеша углядел, для начала.
[...]
>> И дольше, и wearing в 2 раза увеличивается - ssd подохнет
>> быстрее.
> Это пусть у контроллера голова болит, они шибко умные нынче пошли.Умнота контроллера не отменяет вполне характерного устройства чипов флеша на уровне весьма базовой физики лежащей в процессе их работы. Этой физике можно подыграть даже через призму контроллера флеша.
>> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
>> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
>> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
>> вам будет икаться от души.
> Только почему-то на этой самой ntfs всё работает хер знает когда, показывает
> пиковую производительность,Меня интересует в основном средняя производительность и worst case, а не пиковая. Пиковая скорость записи в моей системе - несколько Гб в секунду (ram cache hit). Да, кстати линь намного умнее делает. В лине буфером ФС является почти вся свободная память прямо сразу (линь при необходимости просто урезает этот буфер на ходу), тогда как винда отращивает дисковый буфер крайне неохотно. Поэтому в лине dvd-iso sized чушка у меня просто улетает в буфер. Мгновенно. В винде ... хаха, ну ты понял. Половина в буфер влазит а дальше все, жопа. Полфайла быстро пишется, а потом... потом там уже половина исохи ждет своей записи на винч, а буфер уже кончился. И хотя оперативы еще свободно как грязи, винда не спешит отращивать буфера. Пусть лучше юзер 30 секунд ффтыкает на то как это сливается на диск, а прога будет заблочена пока в буфере еще места под данные не появится ;)
> а в лину псе только сейчас осознали что что-то не так в консерватории.
> Неужели так долго копили на ssd для тестов? :)Линукс мало того что умнее с дисковыми буферами работает, так еще и можно например своп на ссдшник засунуть, без риска в момент его протереть. Поставить минимальную агрессию свопинга, чтобы своп юзался как нечто на крайний случай, когда совсем прижало. И большую часть времени такой своп не будет протирать флеху с ее лимитами на число перезаписей. А вот виндовозный своп флешатину до дыр протрет довольно быстро и я как-то не в курсе - а в винде можно рулить агрессивностью свопа как в лине? А то дефолтная логика там вообще как во времена вин95, видимо с тех пор не менялось. Хотя для машин с 4гб памяти логичны совсем иные настройки чем для машин с 16Мб. В итоге винды позорно тормозят при переключении между увесистыми задачами на машине с совершенно любым количеством оперативки. Хоть 16 гиг воткни, а все-равно несколько гб фуфла в своп сольется при активном использовании. Даже если еще с десяток гигов памяти свободно и вообще нет повода гадить в своп.
> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
> вам будет икаться от души.User294, почему ты не логинишься под своим ником? Тебе же сто раз объясняли, что битовые карты никакой существенной роли в производительности записи на ФС не несут. Чтобы они что-то значали в скорости поиска свободных блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
> User294, почему ты не логинишься под своим ником? Тебе же сто раз
> объясняли, что битовые карты никакой существенной роли в производительности записи на
> ФС не несут.Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень характерный эффект на большинстве бенчмарков ;)
> Чтобы они что-то значали в скорости поиска свободных
> блоков, нужно иметь ФС размером порядка 16 ТБ и больше.А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто пи...т как дышит. А тебе не приходило в бошку что компактную стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши засираются и прочее, а? Или ты думаешь что все новые дизайнф ФС экстенты стали чисто для красоты использовать? ;)
>> User294, почему ты не логинишься под своим ником? Тебе же сто раз
>> объясняли, что битовые карты никакой существенной роли в производительности записи на
>> ФС не несут.
> Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень
> характерный эффект на большинстве бенчмарков ;)Карта свободных блоков — битмапы — кэшируются в ОЗУ. Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см. "FreeBSD. Архитектура и реализация").
>> Чтобы они что-то значали в скорости поиска свободных
>> блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
> А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто
> пи...т как дышит. А тебе не приходило в бошку что компактную
> стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши
> засираются и прочее, а? Или ты думаешь что все новые дизайнф
> ФС экстенты стали чисто для красоты использовать? ;)Экстенты из другой оперы.
> Карта свободных блоков — битмапы — кэшируются в ОЗУ.И что? Это не отменяет нужды читать/писать их на диск (озу знаешь ли не энергонезависимое) и модифиицровать довольно крупные битмапы.
> Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см.
> "FreeBSD. Архитектура и реализация").Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий бсдун. Остальные это называют окаменелым пометом мамонта.
>> засираются и прочее, а? Или ты думаешь что все новые дизайнф
>> ФС экстенты стали чисто для красоты использовать? ;)
> Экстенты из другой оперы.Обычно из той же самой. Или уж занятость блоков описывается битмапой, или уж какой-то компактной структурой, например упакованой в дерево.
>> Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см.
>> "FreeBSD. Архитектура и реализация").
> Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий
> бсдун. Остальные это называют окаменелым пометом мамонта.Ваш генный код старее окаменелого говна мамонта. И судя по вашему тексту, назвать это удачной реализацией архитектуры можно только с натягом.
Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не вставать.
http://www.usenix.org/publications/library/proceedings/useni...
> Ваш генный код старее окаменелого го вна мамонта. И судя по вашему тексту,
> назвать это удачной реализацией архитектуры можно только с натягом.Мы существа одного вида, поэтому вам наверное недостатки видны не хуже меня, на своем примере :)
> Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не
> вставать.Ага, только к SSD это все не относится практически никак.
>> Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не
>> вставать.
> Ага, только к SSD это все не относится практически никак.Точно, реализация FS не относиться к SSD никак. Кстати, о чем новость?
Перечитайте предложение выше, для начала, и постарарайтесь поразмыслить на предмет реализации стратегии записи через интерфейс, и как реализация стратегии записи вообще относится к записи байтиками и вышивке крестиками.
> Точно, реализация FS не относиться к SSD никак.Не согласен. Есть более удобные и менее удобные для ssd файловые системы, более того - с учетом иных физических свойств накопителя оверхед от операций ФС вылезет совсем в ином виде. И кому как не файловой системе видно что и где (не)используется?
> Кстати, о чем новость?
О планиовщике I/O.
> стратегии записи через интерфейс, и как реализация стратегии записи вообще относится
> к записи байтиками и вышивке крестиками.Например, самое очевидное: логично подгонять стратегию таким образом чтобы накопителю было удобно записывать то что ему в результате этой стратегии свалилось. Дебильно выбрав стратегию можно основательно просадить скорость записи у SSD.
А мне вот интересно: вроде как во всех мануалах по оптимизации под SSD рекомендуют использовать noop. А тут выясняется, что еще и CFQ не дурак. Я не спец. Подскажите, какой планировщик все же использовать? Обзавелся недавно SSD, так что для меня актуально.
> А мне вот интересно: вроде как во всех мануалах по оптимизации под
> SSD рекомендуют использовать noop. А тут выясняется, что еще и CFQ
> не дурак. Я не спец. Подскажите, какой планировщик все же использовать?
> Обзавелся недавно SSD, так что для меня актуально.Да собственно работать будет с любым. Вопрос в том насколько честно будет попилена доступная пропускная способность ssd. Что такое доступная пропускная способность ssd - очень хитрый вопрос. Она не ограничена фрагментацией и временем seek, но зато зависит от предыстории (garbage collector и насколько чистая область в накопителе перед записью), имеет лимит сверху по числу iops которое осиливает контроллер и прочая. На самом деле - исследований и теории там на пару докторских хватит, учитывая что ssd, их контроллеры и фирмвары делают разные производители, которые совсем не обязаны реализовывать логику поведения ssd одинаково.
Итого, лично я бы попытался смоделировать желаемую нагрузку и пощелкать планировщиками, изучая под каким из них результат больше всего похож на то что хочется увидеть.
Понятно, спасибо. Вообще, я под это дело аж 8 гигов памяти купил на ноут. В итоге в tmpfs переехали не только /tmp, /run, /var, но и сборка всех пакетов ABSом автоматом выполняется в /tmp, все кэши пакетного менеджера там же и кэш браузера (синхрится на винт автоматом, когда нужно).Так вот я к чему. После всех этих оптимизаций подумываю вернуть журналирование (у меня ext4), а то как-то боязно, да и до настройки бекапов автоматических руки пока не дошли. По различным тестам и замерам (на арчвики, например), количество записываемых данных возрастет лишь на 3%. Плохо будет только если компилять на SSD, но этот вопрос я уже решил.
а почему не YAFFS или другие специализированные флешечковые файлухи?
> а почему не YAFFS или другие специализированные флешечковые файлухи?Потому что для флешки с собственным контроллером все это нахрен не нужно. YAFFS нужен в случае когда чип флеша напрямую прицеплен к системному процессору, как в эмбеддовке. При этом между флехой и процом нет умного контроллера который на себя возьмет размазывание записей, очистку блоков и прочая. Поэтому все это должен делать сам системный проц, лично программируя флеш. Вот на этот случай и есть такие файловые системы. В SSD/картах/флешках на самом деле тамошний контроллер реализует некий слой трансляции, весьма похожий по устройству и смыслу на файловые системы типа yaffs. Просто наружу он этот факт не светится, но механика реализуемая там остается та же самая (обычно это некий вид copy-on-write). Просто эти действия выполняет другой чип. Собственно чип контроллера в SD карте, юсб-флешке, SSD и прочая - всего лишь еще 1 микропроцессор с собственной фирмварой ну и какими-то аппаратными приблудами для ускорения тяжелых операций, типа аппаратной считалки ECC. То же самое, только проц засунут в саму девайсину и является ее служебной сущностью, а наружу вывешивает некий общепринятый интерфейс по которому притворяется шлангом в виде якобы HDD с якобы 512 байтными секторами, которых у него ни разу нет на уровне физики.
Скажем так, не то что бы совсем не бывает по 512, но от модели к модели этот параметр может разниться, да.А ext4 выбрал по двум причинам: перечитал кучу материала на этот счет, в т.ч. рекомендации OCZ на их форуме, и у меня есть хоть какой-то опыт работы и восстановления данных на ext4, что может пригодиться при отсутствии журнала.
> Скажем так, не то что бы совсем не бывает по 512, но
> от модели к модели этот параметр может разниться, да.Найти NAND-флешку у которой именно 512-байтные страницы - на данном этапе эволюции человечества довольно сложно, имхо. Я таковых не видел. Там кроме основной области данных есть еще зарезервированное место под ECC (error correction code) в каждой странице. ECC лучше работает на более крупных блоках. В плане соотношения возможностей по исправлению битовых ошибок к затратам на место под ECC в сравнении с местом под данными. На больших блоках ECC оптимальнее, вот и делают страницы крупнее чем сектора HDD. Кстати этот факт в принципе дошел и до производителей HDD, внезапно осознавших что у 4К секторов КПД получше будет и можно пыжиться поменьше, получая побольше емкости за счет улучшения соотношения данных к ECC и уменьшения числа служебных заголовков. Накопитель конечно врет наружу что у него 512-байтные сектора, но на самом деле при записи 512 байтов делается крайне извращенский read-modify-write. Как абсолютный минимум будет записана страница на 1..4 Кб, а если не повезет то и весь огромный erase-block перетряхнут.
> А ext4 выбрал по двум причинам: перечитал кучу материала на этот счет,
> в т.ч. рекомендации OCZ на их форуме, и у меня есть
> хоть какой-то опыт работы и восстановления данных на ext4, что может
> пригодиться при отсутствии журнала.На лично мое имхо можно включить журнал в ext4 и не канифолить себе мозг. В обычном "крейсерском" случае оверхед от журнала считанные проценты и я как-то не вижу нужды камикадзить чтобы сэкономить ресурс ssd в столь незначительном объеме. Соотношение риска и выигрыша имхо невкусное. Может при специфичных workloads типа пересборки всего и вся 24 часа и 7 дней в неделю это и повлияет. При типичном для меня крейсерском режиме использования десктопа лично я проблем не вижу.
> (на арчвики, например), количество записываемых данных возрастет лишь на 3%.Ну да, все так. У арчеводов кстати вообще довольно много дельных статей на вике. Молодцы парни, приятно почитать прямо. Кстати там же изложен довольно нахальный по своей изобретательности метод как проверить что trim работает и советы как его включить (его включение позволит ssd работать несколько быстрее при записи больших кусков данных).
> Плохо будет только если компилять на SSD, но этот вопрос я уже решил.
Плохо будет если много писать. От чего именно произойдет эта запись - ssd как-то не сильно важно. По этой причине кстати своп на ssd если и стоит класть то разве что с swapiness = 1, чтобы только на самый крайний случай был. Хотя с 8 гб оный можно просто не юзать совсем, имхо.
> Кстати там же изложен
> довольно нахальный по своей изобретательности метод как проверить что trim работает
> и советы как его включить (его включение позволит ssd работать несколько
> быстрее при записи больших кусков данных).Видел, сделал сразу.
> Плохо будет если много писать. От чего именно произойдет эта запись -
> ssd как-то не сильно важно. По этой причине кстати своп на
> ssd если и стоит класть то разве что с swapiness =
> 1, чтобы только на самый крайний случай был. Хотя с 8
> гб оный можно просто не юзать совсем, имхо.Про "много писать" -- понимаю. Просто привел пример с компеляцией как частный случай подтвержденный статистикой с того же арчвики.
По поводу свапа. Когда создавал swap-раздел, памяти было всего 2 гига (swapinness включил). Создавал я его с одной целью: tuxonice. А потом понял, что памяти явно мало и поставил 8 гигов. Теперь вот и думаю: как же быть с suspend to disk: SSD всего 60 гигов и места тупо жалко. А ноут с хардварным багом и на suspend 2 ram батарею высасывает полностью часов за 10 (Lenovo, ПРИВЕТ :)).
> Видел, сделал сразу.Кстати прогнал немного, у арчеводов только ссылка на статью, сама статья на другом сайте. А ext4 - умеет trim, как и btrfs.
> Про "много писать" -- понимаю. Просто привел пример с компеляцией как частный
> случай подтвержденный статистикой с того же арчвики.Ну лично я компилирую не сильно много, у меня много оперативки и нарваться на то что оно упрется в диск даже на простом механическом диске мне как-то не удавалось. Поэтому я просто компилячу на механическом диске. Здоровенный дисковый кэш спасает :). Ну правда это на десктопе. Извините, не вижу причин ограничивать себя мелким экранчиком, урезанной клавиатурой и количеством дисков в ситуации когда хочется пользоваться с комфортом.
> По поводу свапа. Когда создавал swap-раздел, памяти было всего 2 гига (swapinness
> включил). Создавал я его с одной целью: tuxonice. А потом понял,
> что памяти явно мало и поставил 8 гигов. Теперь вот и
> думаю: как же быть с suspend to disk: SSD всего 60 гигов и места тупо жалко.Лично я никак с ним не делаю - suspend to RAM явно лучше. И на десктопе, и на ноуте. На десктопах кстати биосы и чипсеты в этом плане крайне глючные и suspend to disk там вообще работает крайне ненадежно и не на всех мамках. И вообще, я не вижу смысла в суспенде на диск 8 гигов оперативы. Проще тупо загрузиться с нуля. При загрузке читается явно менее 8Гб. Поэтому есть шансы что это будет еще и быстрее (как минимум с параллельной системой инициализации как в убунте оно взлетает за считанные секунды)
> А ноут с хардварным багом и на suspend 2 ram батарею высасывает полностью часов
> за 10 (Lenovo, ПРИВЕТ :)).Жесть. У меня его где-то на неделю хватает. И из него ноут просыпается быстрее всего. Открыл крышку и вот тебе уже операционка. Логинься и вот тебе уже твой десктоп.
> Ну лично я компилирую не сильно много, у меня много оперативки и нарваться на то что
> оно упрется в диск даже на простом механическом диске мне как-то не удавалось. Поэтому
> я просто компилячу на механическом диске. Здоровенный дисковый кэш спасает :). Ну
> правда это на десктопе. Извините, не вижу причин ограничивать себя мелким экранчиком,
> урезанной клавиатурой и количеством дисков в ситуации когда хочется пользоваться с
> комфортом.Я часто пересобираю одну большую штуку из git, за разработкой которой внимательно слежу, и ядро под себя. Про ноут полностью согласен: у меня мощный десктоп с 24" монитором. Ноут -- мобильное решение для работы вне дома. Ну, и на диване, конечно :)
> Лично я никак с ним не делаю - suspend to RAM явно лучше. И на десктопе, и на ноуте.
> Проще тупо загрузиться с нуля. При загрузке читается явно менее 8Гб. Поэтому есть шансы
> что это будет еще и быстрее (как минимум с параллельной системой инициализации как в
> убунте оно взлетает за считанные секунды)Для ускорения суспенда на диск можно выкинуть кэш из оперативы. После этого у меня обыно занято не более 500МБ памяти.
А по поводу параллельной загрузки... На SSD не вижу причин заморачиваться: загрузка около 3-5 секунд до XDM.>> А ноут с хардварным багом и на suspend 2 ram батарею высасывает полностью часов
>> за 10 (Lenovo, ПРИВЕТ :)).
> Жесть. У меня его где-то на неделю хватает. И из него ноут просыпается быстрее всего.
> Открыл крышку и вот тебе уже операционка. Логинься и вот тебе уже твой десктоп.Работает то оно у меня так же. Но пользоватся нельзя по указанным причинам.
История такая. Ноут X201i. При покупке обнаружил баг: первый s2r проходит нормально, из второго уже не выходит (зависон). Пинял на линукс. Потом выходит новый биос с заметкой в changelog: так мол и так, пофиксили баг с suspend to ram на non windows OS. Ура, думаю, молодцы. На новом биосе система действительно стала нормально засыпать и просыпаться хоть миллион раз, но батарею при этом жрет безбожно. До установки этой версии биоса такой проблемы не было. Так что вот так. Думаю они режим сна изменили, но какие они бывают я не особо в курсе. Кстати, только сейчас понял: не проверял что будет если заснуть в винде. Надо проверить. Я ее гружу только чтоб биос обновить...
> Я часто пересобираю одну большую штуку из git, за разработкой которой внимательно
> слежу, и ядро под себя.Я тоже перекомпиливаю некоторые штуки, но не очень большие и на механическом диске. С большим дисковым буфером - вполне нормально получается.
> Про ноут полностью согласен: у меня мощный десктоп с 24" монитором.
> Ноут -- мобильное решение для работы вне дома. Ну, и на диване, конечно :)Честно говоря мне сочетание "программист по выезду" кажется каким-то довольно искусственным, чтоли. Конечно бывают редкие исключения которым реально так надо, типа всяких железячников выезжающих для отладки на реальный объект за тридевять земель, баги вылавливать в реальных условиях.
[..]
>> что это будет еще и быстрее (как минимум с параллельной системой инициализации как в
>> убунте оно взлетает за считанные секунды)
> Для ускорения суспенда на диск можно выкинуть кэш из оперативы. После этого
> у меня обыно занято не более 500МБ памяти.И перезапускать все программы потом самолично? Я ленивый и люблю когда нудную работу удается сбагрить на машины. Они железные :). Ребут имхо опять же проще будет - даже скромный XFCE умеет сессию сохранять.
> А по поводу параллельной загрузки... На SSD не вижу причин заморачиваться: загрузка
> около 3-5 секунд до XDM.А по-моему смысл есть. Обидно же если загрузка надолго залипнет из-за какой-то сколь-нибудь длительной операции, которую последовательно фигарят, а накопитель в это время радостно занимается ничегонеделанием (хотя по этому поводу есть утилитки для readahead, несколько скрашивающие это дело).
>> Жесть. У меня его где-то на неделю хватает. И из него ноут просыпается быстрее всего.
>> Открыл крышку и вот тебе уже операционка. Логинься и вот тебе уже твой десктоп.
> Работает то оно у меня так же. Но пользоватся нельзя по указанным причинам.На лично мое имхо это серьезный брак.
> История такая. Ноут X201i. При покупке обнаружил баг: первый s2r проходит нормально,
> из второго уже не выходит (зависон). Пинял на линукс. Потом выходит
> новый биос с заметкой в changelog: так мол и так, пофиксили
> баг с suspend to ram на non windows OS. Ура, думаю,
> молодцы. На новом биосе система действительно стала нормально засыпать и просыпаться
> хоть миллион раз, но батарею при этом жрет безбожно. До установки
> этой версии биоса такой проблемы не было. Так что вот так.Может забывают что-то из вспомогательной электроники в спячку загнать?
> Думаю они режим сна изменили, но какие они бывают я не особо в курсе.
По идее при настоящем STR снимается питание со всей электроники кроме чипов памяти и менеджера питания. Потому и живет неделю. Проц и прочее - выключены совсем. Потому и спит неделю.
> Кстати, только сейчас понял: не проверял что будет
> если заснуть в винде. Надо проверить. Я ее гружу только чтоб биос обновить...А у меня на ноуте ее вообще не было - нахрен надо 50 баксов некоторым дарить за то что мне не требуется.
CFQ совсем не дурак, он различает винчестеры и SSD (/sys/block/sdX/queue/rotational = 0) и меняет алгоритм. Но настоятельно рекомендуется для SSD в шедулере CFQ включать slice_idle = 0 для перехода в режим IOPS - алгоритм меняется, чтобы он будет сравнивал IOPS'ы, а не время выполнения запроса. (http://www.mjmwired.net/kernel/Documentation/cgroups/blkio-c...)
Это убирает отставание от deadline в линейных скоростях, из-за которого некоторые руководства рекомендуют deadline на SSD, но оставляет все остальные фичи CFQ, вроде шедулинга по группам, вычисление приоритетов шедулинга и т.д.
> А мне вот интересно: вроде как во всех мануалах по оптимизации под
> SSD рекомендуют использовать noop. А тут выясняется, что еще и CFQ
> не дурак. Я не спец. Подскажите, какой планировщик все же использовать?IMO noop или deadline.
