zfs defrag?

Граждане читатели!

А для дефрагментации ZFS придумали что-то лучше чем:

zfs snapshot pool/fs@1

zfs send pool/fs@1 | zfs recv pool/fsnew

zfs destroy -r pool/fs

zfs destroy pool/fsnew@1

zfs rename pool/fsnew pool/fs

писал по памяти от фонаря, но смысл, надеюсь, передал

Comments

Нет, так как block pointer rewriting так и не взлетел (это базовая фича, нужная для дефрага, решейпа vdev'а и прочих таких дел).

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

А чего ждать?

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

Ну вот у меня на 22-Tb пуле, которому примерно два года (с переезда на текущие 4Tb-диски) - фрагментация 0%.

Заполнен он примерно на 60%. Говорят, фрагментация становится проблемой при заполнении больше 80.

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

Винда, ДЛЯ БЫСТРОЙ ДЕФРАГМЕНТАЦИИ, требует 30% свободного места на каждом диске. Иначе тормоза!!!
С другими файловыми системами +/-, но когда инструмента СОВСЕМ нет...
Я догадываюсь, что это именно из-за снэпшотов, но.....

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

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

>фрагментация 0%.
А как, кстати, это можно посмотреть?

$ 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 - это оно

Да, а я собственно взвился и задал исходный вопрос потому что принял посла Румынии за посла Болгарии колонку CAP(acity) за колонку FRAG (криво перенеслось в окошке) и принялся В УЖАСЕ читать, что же делать с ТАКОЙ фрагментацией

У меня похуже будет
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
Но апгрейдился постепенной заменой дисков, с ресильвером пула.

У меня ровно эта история "печально известные 3Tb -> 4Tb" была в 2014м, я правда на HGST менял, но не суть.

Попробуйте send|recv, должно ж помочь.

К сожалению, способа узнать какой именно dataset наиболее фрагментирован - я не нашел. Особо и не искал, но на поверхности не лежит.

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

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

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

http://blog.delphix.com/uday/2013/02/19/zfs-write-performance/

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

Ну как нету. Укладывая файл в один метаслаб - экономим на длинных seek.

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

Хм, ну вот recordsize 128k->1M дало +~10% на записи из dev/zero в файл (50Gb), компрессия выключена.

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

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

С метаслабами же такая история
- если данные локальные, то махание идет на зону, размером порядка 1/200 от диска.
- а если размазаны по всему диску - то и махание шире.
track-to-track всяко *сильно* быстрее, чем average или там full-stroke.

Поэтому локальность - особенно в малопоточном случае (в многоюзерном - не избежать) - важна.

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

Ну все так, да.
Но даже с мегабайтным размером записи - разница между локальными редкими (дорожку записали полностью) и частыми (каждый блок на новой дорожке) full-stroke - будет в разы, ели просто вот на пальцах прикинуть.

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

Когда я сортировал слиянием большие файлы (поисковый индекс) на большом количестве шпинделей - это было как-то нихрена не так.
То есть два потока, даже с большими блоками - убивали перформанс насмерть.

в данном случае много неизвестных нюансов.. большие блоки попрошенные у fs - это не обязательно большие блоки попрошенные у девайсов.

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

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

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

Есть 2 pool
3 диска SAS по 300 Гб 15K - rpool
4 диска SATA по 2 Тб
1 SSD ( Samsung 850 Pro)

Переносил туда/ сюда - не помогло.
Переносил на другие компы - не помогло.
Фрагментация уменьшается только при удалении ...

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
pve4-sata 7.25T 3.42T 3.83T - 15% 47% 1.00x ONLINE -
rpool 832G 497G 335G - 37% 59% 1.00x ONLINE -

zpool status
pool: pve4-sata
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
pve4-sata ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
sdh ONLINE 0 0 0
cache
sdi2 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scan: scrub repaired 0 in 2h16m with 0 errors on Sun Nov 20 17:15:24 2016
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
sdd2 ONLINE 0 0 0
logs
sdi5 ONLINE 0 0 0
cache
sdi1 ONLINE 0 0 0

errors: No known data errors

Add new comment