https://217.65.3.21/openforum/vsluhforumID3/82337.html Shaohua Li представил (https://lkml.org/lkml/2012/1/4/18) в списке рассылки ядра Linux начальную версию планировщика ввода-вывода FIOPS (от аббревиатуры IOPS - Input/Output Operations Per Second, количество операций ввода/вывода в секунду), предназначенного для работы с твердотельными накопителями и Flash-памятью. В настоящее время патчи носят экспериментальный характер.<br><br><br><br>FIOPS во многом подобен используемому ныне планировщику CFQ, также имеющему несколько оптимизаций для твердотельных дисков, но спроектирован с оглядкой на работу исключительно с Flash-памятью. Например, FIOPS полностью игнорирует такие параметры накопителя как время перемещения головок, зависимость времени записи от расположения данных на диске, учитывает более высокие скорости записи и чтения, зависимость скорость выполнения запроса от его размера и т.д.<br><br><br><br>В настоящее время реализация имеет ряд проблем и недоработок, таких как отсутствие поддержки ioprio, механизма cgroups, поддержки трассировки, а также автом...<br><br>URL: https://lkml.o https://217.65.3.21/openforum/vsluhforumID3/82337.html#190 Wed, 01 Feb 2012 14:05:06 GMT &gt;&gt; - Почему?<br>&gt;&gt; - Ваш код гaвно, а кто так не считает, те казлы!<br>&gt; А в этом что-то есть. Например, осознать что UFS всего лишь древний <br>&gt; помет мамонта с угребищной архитектурой можно просто окинув взглядом общую архитектуру <br>&gt; ФС. Читать целиком код этого ископаемого барахла - лишняя работа. Пусть <br>&gt; он хоть трижды замечательный на вкус, архитектурной угребищности ФС в целом <br>&gt; это не отменяет.<br><br>Судя по тексту, вы в этом вопросе разобрались. В каком месте код устарел и не отвечает техническим требованиям?<br><br>$ ls -l /usr/src/sys/ufs/ufs/<br>total 708<br>-rw-r--r-- 1 root wheel 3342 21 Jan 2010 README.acls<br>-rw-r--r-- 1 root wheel 4549 21 Jan 2010 README.extattr<br>-rw-r--r-- 1 root wheel 2105 23 Jul 2010 acl.h<br>-rw-r--r-- 1 root wheel 8526 2 Jan 23:41 dinode.h<br>-rw-r--r-- 1 root wheel 5848 21 Jan 2010 dir.h<br>-rw-r--r-- 1 root wheel 5259 17 Oct 18:13 dirhash.h<br>-rw-r--r-- 1 root wheel 6068 21 Jan 2010 extattr.h<br>-rw-r--r-- 1 root wheel 1629 21 Jan 2010 gjournal. https://217.65.3.21/openforum/vsluhforumID3/82337.html#189 Wed, 01 Feb 2012 13:17:41 GMT &gt; Точно, реализация FS не относиться к SSD никак. <br><br>Не согласен. Есть более удобные и менее удобные для ssd файловые системы, более того - с учетом иных физических свойств накопителя оверхед от операций ФС вылезет совсем в ином виде. И кому как не файловой системе видно что и где (не)используется?<br><br>&gt; Кстати, о чем новость? <br><br>О планиовщике I/O. <br><br>&gt; стратегии записи через интерфейс, и как реализация стратегии записи вообще относится <br>&gt; к записи байтиками и вышивке крестиками.<br><br>Например, самое очевидное: логично подгонять стратегию таким образом чтобы накопителю было удобно записывать то что ему в результате этой стратегии свалилось. Дебильно выбрав стратегию можно основательно просадить скорость записи у SSD.<br> https://217.65.3.21/openforum/vsluhforumID3/82337.html#188 Wed, 01 Feb 2012 13:07:01 GMT &gt; Вообще-то про NOR все пишут, что оно тоже может байтами писаться. Та <br>&gt; же википедия пишет.<br>&gt; Врут?<br><br>Зависит от чипа. Зачастую - натурально может (под записью я имею в виду PROGRAM). А иногда только страницами, зависит от конкретиики реализации. Исторически, страничные режимы (для ускорения чтения-записи) появились позже побайтовых (а точнее, пословных, поскольку байт на, допустим, 16-битной шине - нечто довольно странное и не существующее физически). Но даже если запись и можно делать индивидуально, это будет с противной оговоркой: в NOR можно индивидуально спустить битики из 1 в 0 но вот обратно в 1 их загнать можно только ERASE'ом всего огромного блока. Кстати этот фокус позволял штукам типа JFFS писать в NOR 1 байт без стирания несколько раз: если нужное значение делается из того что уже записано только спуском битов - стирать не требуется. В современном мире однако ж чипы чаще всего NAND, а обмен чаще всего только страницами (по поводу чего указанный хак в jffs работать перестал и им пришлось немног https://217.65.3.21/openforum/vsluhforumID3/82337.html#187 Wed, 01 Feb 2012 12:43:50 GMT &gt; - Почему?<br>&gt; - Ваш код гaвно, а кто так не считает, те казлы!<br><br>А в этом что-то есть. Например, осознать что UFS всего лишь древний помет мамонта с угребищной архитектурой можно просто окинув взглядом общую архитектуру ФС. Читать целиком код этого ископаемого барахла - лишняя работа. Пусть он хоть трижды замечательный на вкус, архитектурной угребищности ФС в целом это не отменяет.<br> https://217.65.3.21/openforum/vsluhforumID3/82337.html#186 Tue, 24 Jan 2012 21:00:52 GMT &gt; Упрощение в FreeBSD по текущему моменту вызвано фактически тем, что у операций I/O<br>&gt; нет приоритета, который бы каким-то образом вычислялся из приоритета их заказчика.<br><br>BTW http://lkml.org/lkml/2011/3/25/44<br> https://217.65.3.21/openforum/vsluhforumID3/82337.html#185 Mon, 23 Jan 2012 18:04:47 GMT &gt;&gt; Не только. ZFS разрабатывали в том числе для использования с SSD. ;) <br>&gt; Ага, правда SSD в природе не было в момент дизайна ZFS, но <br>&gt; изена такие мелочи не волнуют, как обычно.<br><br>Вообще-то у ZFS сейчас идёт уже где-то 15-я минимум версия пула - это раз.<br>Флэшовые накопители были уже много лет - это два. Да, у них не было умного контроллера, ремапа по обстоятельствам и так далее, но часть проблем была уже известна.<br><br>&gt; Он лучше будет маркетинговый <br>&gt; булшит от санок повторять как мантру, ведь верить в это намного <br>&gt; приятнее, правда? :) <br><br>Урежьте осетра.<br> https://217.65.3.21/openforum/vsluhforumID3/82337.html#184 Mon, 23 Jan 2012 17:56:04 GMT &gt;&gt;&gt; через смотрение в каком секторе лежит файл, его стирание и смотрение <br>&gt;&gt;&gt; с тем что стало с этим сектором после sync.<br>&gt;&gt; Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM.<br>&gt; Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. EEPROM где-то <br>&gt; на совсем базовом уровне похож на "соседний" NOR-флеш, но в отличие <br>&gt; от - может писаться хоть отдельными байтами в людском виде.<br><br>Вообще-то про NOR все пишут, что оно тоже может байтами писаться. Та же википедия пишет.<br>Врут?<br><br>&gt; Почему <br>&gt; не юзают? Потому что плотность хранения данных никакая. Не надо никому <br>&gt; носитель на несколько метров и по цене самолета.<br>&gt; Во вторых, набор команд у SSD вроде как ATA, а не ATAPI. <br><br>Ну имелось в виду, как я понял, с кастомным обращением не с блочными операциями, а значит - ATAPI.<br> <br>&gt; (самое интересное, а именно проверка - на второй странице) <br><br>Проверили, что нули... ничего интересного. Кстати, в случае SCSI спецификации не требуют нули, хотя и рекомендуют.<br><br><br> https://217.65.3.21/openforum/vsluhforumID3/82337.html#183 Mon, 23 Jan 2012 17:48:10 GMT &gt;&gt; ну и SSD весело в них пишет, если считает необходимым.<br>&gt;&gt; Говорят, это SSD облегчает его нелегкую кремниевую жизнь.<br>&gt; Говорят, что это позволяет контроллеру на ssd понять что вон те блоки <br>&gt; уже никому нафиг не нужны и можно заранее их erase'ануть. Это <br>&gt; бы все-равно пришлось сделать потом для их использования, но если это <br>&gt; делать когда приперло записать туда что-то - так сперва придется дождаться <br>&gt; конца erase а только потом делать program.<br><br>Кроме того, это показывает, что если пересобирается новый комплект блоков, то можно указанные блоки не спасать из очищаемого диапазона.<br><br>&gt;&gt; Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала <br>&gt;&gt; с слоем драйверов. То есть пипл старался так делать.<br>&gt;&gt; Ну вот теперь традиции меняются :) <br>&gt; SSD вообще на диски не похожи. Какой козел придумал что он должен <br>&gt; выглядеть как диск я не знаю но он заслуживает прогулки на <br>&gt; эшафот. За создание геморроя остальным в "благих" целях обратной совместимости.<br><br>А какая альтернатива? Опиш https://217.65.3.21/openforum/vsluhforumID3/82337.html#182 Mon, 23 Jan 2012 17:42:14 GMT &gt; Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций <br>&gt; от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке <br>&gt; "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров <br>&gt; винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный <br>&gt; планировщик I/O, которому в общем-то по барабану, с каким накопилем он <br>&gt; работает &#8212; с HDD или SSD.<br><br>Ему вообще-то не совсем по барабану. Потому что если, например, для диска лифтовый шедулер знает, что сейчас мы пишем блок 1000, в очереди стоит блок 990 от низкоприоритетного процесса, текущее направление лифта - вниз, а поступил заказ на блок 2000 от высокоприоритетного процесса - то шедулер должен решить, достаточно ли новый заказ важен, чтобы сбить логику лифта и погнать его срочно вверх (на 2000), или можно продолжить проход вниз (где ждёт 990) и заставить высокоприоритетный процесс таки подождать. В целом мы будем иметь суммарный вес з