Pull to refresh

Comments 9

В Linux на текущий момент существует четыре планировщика ввода-вывода:

ни одного из перечисленных на текущий момент уже не существует. Удалены в ядре, теперь используется более новая blk-mq подсистема. В основном none (это не тот none что был ранее), mq-deadline, bfq или kyber

Ну, 3-4 статьи в день выпускать качественными не получится.

Также блочные устройства можно обнаружить с помощью ls -l и ls -l:

Опечатка

Лучше б про кеш сказали хоть. Что в линуксе нет нормального файлового кеша, как было в OS/2 или в Windows. В итоге, если, например у нас raid-10 на btrfs, и мы хотим SSD-кеш сделать, то будем кешировать отдельно 4 блочных устройства из которых две пары -- имеют абсолютно одинаковое содержимое. В итоге оно всё занимает в два раза больше ОЗУ (или в имеющийся объём вмещается в два раза меньше информации), в два раза больше на SSD, медленей работает (потому, что одно и то же по два раза часто читает). Причём что касается ОЗУ и скорости, справедливо и для варианта без SSD-кеша. Там какой-то алгоритм, вроде того, что диск из зеркала (один из) определяется по номеру PID читающего процесса. В итоге если два читают одно и то же, то могут читать одно и то же, но с разных дисков. Параллельно. Блеск и нищего опенсоурса...

Очевидно, проблема не устранимая пока кешируются блочные устройства, а не сами файлы. С RAID-5/6 оно не так больно (но там и без того тормозит). Но так в линуксе ещё же write hole забороть никак не могут (без фатального падения перформанса).

Не тестировали? Bcached btrfs file systems:
Bcache (block cache) allows one to use an SSD as a read/write cache (in writeback mode) or read cache (writethrough or writearound) for another blockdevice (generally a rotating HDD or array).
Bcache is in the mainline kernel since 3.10.

Очевидно, проблема не устранимая пока кешируются блочные устройства, а не сами файлы. 

а вот synology считают иначе, они запилили ssd кэш для btrfs пулов а не блочных устройств. оно конечно проприетарное и за пределами synology не существует, но их прошивка это просто линукс, и если они смогли значит проблема решаемая, вопрос только когда кто нибудь уже осилит..

то будем кешировать отдельно 4 блочных устройства из которых две пары

если я правильно понимаю, это проблема специфична именно для btrfs.
у ext4 поверх md и у zfs со своим пулом из кучи дисков в памяти одна копия данных.


Но так в линуксе ещё же write hole забороть никак не могут (без фатального падения перформанса).

ну в zfs write hole нет by design.
для классического raid5 заткнуть write hole без потери производительности сложнее, нужно внешнее энергонезависимое хранилище. и да, md умеет внешний журнал, который как раз затыкает write hole.

Sign up to leave a comment.