The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..., opennews (?), 10-Янв-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


30. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +1 +/
Сообщение от Аноним (-), 11-Янв-12, 06:04 
> Во FreeBSD например, судя по книжке "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров винчестеров, таких, как время перемещения головки.

Проще говоря, нормальный планировщик IO там написать так и не осилили.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

36. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от Аноним (-), 11-Янв-12, 07:40 
> Проще говоря, нормальный планировщик IO там написать так и не осилили.

Проще говоря, изен как обычно пытается приподнести голожопость как фичу - мол, это не мы бомжи, это так и задумано. И вообще, это такой дизайнерский изыск! Это сейчас так модно!

Ответить | Правка | Наверх | Cообщить модератору

70. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от uniman (?), 11-Янв-12, 17:04 
>> Проще говоря, нормальный планировщик 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 message

The 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 class

                                                                   Available 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.

Ответить | Правка | Наверх | Cообщить модератору

64. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  –2 +/
Сообщение от uniman (?), 11-Янв-12, 16:04 
> Проще говоря, нормальный планировщик IO там написать так и не осилили.

Да, он не планирует за для походы за продуктами в магазин. Это несомненно недостаток.

Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?


Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

125. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от Аноним (-), 12-Янв-12, 07:01 
> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?

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


Ответить | Правка | Наверх | Cообщить модератору

157. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от uniman (ok), 13-Янв-12, 02:19 
>> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?
> Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их
> вон на выбор есть, а будет еще больше.

То есть критерии стратегирования файловой системы вы сформулировать не компетентны.

1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости применения различных планировщиков дискового ввода-вывода? Ну хотя бы что эти планировщики планируют?

Можно с указанием фрагментов исходных текстов. Я пойму.

2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?) что-то не получается в достижении трубуемого отклика и прочих технических параметров от файловых систем?

Ответить | Правка | Наверх | Cообщить модератору

161. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от Аноним (-), 13-Янв-12, 20:43 
> То есть критерии стратегирования файловой системы вы сформулировать не компетентны.

Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители. Ну вот например запускают в производство MRAM. Ты знаешь какие у него физические свойства и какие из-за этого будут требования по их учету к планировщику? Я вот пока слабо представляю себе свойства всего этого.

> 1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости
> применения различных планировщиков дискового ввода-вывода?

Да пожалуйста. Физические свойства флеша и вращающихся дисков настолько различны что крайне глупо шедулить их одним и тем же алгоритмом без учета их физических особенностей. Алгоритм для дисков - должен учитывать тормозной seek и стараться минимизировать перемещения голов и/или например "наказывать" тех кто много их гоняет, если допустим цель - относительно честно поделить доступ к диску между всеми. Алгоритм для флеша на seek внимание обращать не должен, а вот потенциальную тормознутость записи в некоторых ситуациях - очень даже неплохо бы учесть. Для каких-то еще типов накопителей оптимально учесть что-то еще.

> Ну хотя бы что эти планировщики планируют?
> Можно с указанием фрагментов исходных текстов. Я пойму.

Все исходники есть на kernel.org. Для cfq вроде кто-то даже фрагмент постил - там где проверяется что это rotational media или нет. И алгоритм меняется, соответственно.

> 2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?)
> что-то не получается в достижении трубуемого отклика и прочих технических параметров
> от файловых систем?

Да при чем тут файловые системы? Планировщик ввода-выводы делит ресурсы устройства на всех по некоей политике. В лине этому всему уделяют внимание например потому что стоит где-то хост с виртуалками. На нем орда юзеров, допустим. Будет нехорошо, если один юзер из своей виртуалки узурпирует все ресурсы железа, положив остальных на лопатки. Ну понятно что бсдельники далеки от этого (наверное потому что я как-то не видел бсд в роли host в продакшне крутящем кучи юзерских виртуалок за бабки).

Ответить | Правка | Наверх | Cообщить модератору

167. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от uniman (ok), 13-Янв-12, 22:01 
>> То есть критерии стратегирования файловой системы вы сформулировать не компетентны.
> Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители.

Те, в разработке интефейсов к которым вы примете горячее участие.
Впереди планеты всей.
Не теряйте, батенька, времени.

http://www.t10.org/intro.htm


>> Ну хотя бы что эти планировщики планируют?
>> Можно с указанием фрагментов исходных текстов. Я пойму.
> Все исходники есть на kernel.org. Для cfq вроде кто-то ...

... где-то.

Понятно.

PS

Универсальный алгоритм:
- Ваш код гавно!
- Но ты смотрел его?
- Не смотрел, патамучно ваш код гавно!
- Почему?
- Ваш код гавно, а кто так не считает, те казлы!

Opensource world. Next generation.

Ответить | Правка | Наверх | Cообщить модератору

187. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от Аноним (-), 01-Фев-12, 16:43 
> - Почему?
> - Ваш код гaвно, а кто так не считает, те казлы!

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

Ответить | Правка | Наверх | Cообщить модератору

190. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."  +/
Сообщение от uniman (ok), 01-Фев-12, 18:05 
>> - Почему?
>> - Ваш код г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.h

PS
Насколько понимаю, вы эксперт по файловым системам. Поэтому вам не составит труда указать.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру