Свежие комментарии

моя практика (из top500 ;) показывает, что с хорошим размером блока влияние почти нивелируется. скажем, дают raw linear writes 100MB/s, а мы получаем 95MB независимо от кол-ва тредов (которые пишут в разные места). уверен, Вы сами можете в этом убедиться, запуская dd of=direct с разным bs=

и снова на помощь приходят большие блоки ;) двигать головку чтобы получить 8K - это совсем не то же самое, что получить 1MB ;)
фрагментация сама по себе не проблема. проблема - если она приводит к медленному IO. то есть надо сначала глядеть на IO: размер и задержка. еще лучше - в динамике, сначала пособирать статистику на пустом пуле, потом поглядывать как она меняется..

Не, у меня у одного ящика (на котором правда пока тупо RAID6 имени адаптека, буду на ZFS переделывать) - строго сингл-юзер. Потоков - ну два, бэкап и я что-то ковыряю с фоточками.

А у второго - почти строго, туда маки домашние тайм-машинятся (но это слезы, линки медленные, гигабит и wifi), а основной потребитель по 10G - опять я один и "несколько потоков чтения" вообще не бывает.

ну было бы странно иное, когда : 1) запись кэшируется (т.е. агрегируется) 2) достаточно свободного места.
delphix жалуется на дефрагментацию и указывает, что их workload - случайная запись с recordsize=8k.
очевидно в этом случае приходится много головками махать.

мать-и-матика простая: скажем есть 8 дисков/головок, каждый может "махнуть" 150 раз в секунду.
для recordsize=8k: 8*8*150=9,6MB/s
для recordsize=128k: 8*128*150=150MB/s

ну так, из практики ;) я делал нынешний аллокатор на ext4, окно преаллокации можно выбирать.. так вот после 8MB производительность почти не меняется, даже на чтениях последовательных.
если файлы большие, то я бы однозначно не заморачивался с дефрагментацией, а увеличивал recordsize.

если куски достаточно большие (несколько мегабайт), то никакого смысла дефрагментировать нет.

определите "фрагментацию" на zfs для начала?

если файлы в основном большие, то имеет смысл пользовать large blocks (вроде в последних релизах уже есть)

У меня похуже будет
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
ZP01 21.8T 14.3T 7.41T - 21% 65% 1.61x ONLINE -

Пул апгрейдился в январе с печально известных 3тб Сигейтов на 4тб WD
Но апгрейдился постепенной заменой дисков, с ресильвером пула.

$ zpool list

NAME SIZE  ALLOC  FREE  EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT

zdata 21,8T 11,8T 9,96T    -      0%  54% 1.00x ONLINE -

Вот колонка FRAG - это оно

Инструмент нарисован в исходном посте, выше.

Но, понятно, самый большой из datasets должен быть (значительно) меньше свободного места.

1. Фрагментация - всегда проблема.
2. За МКАДом другая жизнь: докупать лишнее дисковое пространство - дорого. Пока не упрусь, докупать ничего не буду.
3. Никогда с чужих SDишек фотки не восстанавливали?!

Без дефрагментации нынче совсем грустно. :-(

Я серьёзно думал о переезде на ZFS...
Но если там и с этой, простейшей по сути, фишкой проблемы.... ... я лучше подожду!

Они, поди, в процессе доставки примагнитятся....