zfs defrag?
lexa - 15/Апр/2016 11:36
Граждане читатели!
А для дефрагментации 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
Нет, так как block pointer rewriting так и не взлетел (это базовая фича, нужная для дефрага, решейпа vdev'а и прочих таких дел).
Огромное спасибо!
Я серьёзно думал о переезде на ZFS...
Но если там и с этой, простейшей по сути, фишкой проблемы.... ... я лучше подожду!
А чего ждать?
А чего ждать?
Вдруг сделают...
Без дефрагментации нынче совсем грустно. :-(
Ну вот у меня на 22-Tb пуле,
Ну вот у меня на 22-Tb пуле, которому примерно два года (с переезда на текущие 4Tb-диски) - фрагментация 0%.
Заполнен он примерно на 60%. Говорят, фрагментация становится проблемой при заполнении больше 80.
Есть нюансы.
1. Фрагментация - всегда проблема.
2. За МКАДом другая жизнь: докупать лишнее дисковое пространство - дорого. Пока не упрусь, докупать ничего не буду.
3. Никогда с чужих SDишек фотки не восстанавливали?!
Upd.
Винда, ДЛЯ БЫСТРОЙ ДЕФРАГМЕНТАЦИИ, требует 30% свободного места на каждом диске. Иначе тормоза!!!
С другими файловыми системами +/-, но когда инструмента СОВСЕМ нет...
Я догадываюсь, что это именно из-за снэпшотов, но.....
Инструмент нарисован в
Инструмент нарисован в исходном посте, выше.
Но, понятно, самый большой из datasets должен быть (значительно) меньше свободного места.
>фрагментация 0%.
>фрагментация 0%.
А как, кстати, это можно посмотреть?
$ zpool list
$ 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-
Хм, ну вот 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 ;)
моя практика (из top500 ;) показывает, что с хорошим размером блока влияние почти нивелируется. скажем, дают raw linear writes 100MB/s, а мы получаем 95MB независимо от кол-ва тредов (которые пишут в разные места). уверен, Вы сами можете в этом убедиться, запуская dd of=direct с разным bs=
Когда я сортировал слиянием
Когда я сортировал слиянием большие файлы (поисковый индекс) на большом количестве шпинделей - это было как-то нихрена не так.
То есть два потока, даже с большими блоками - убивали перформанс насмерть.
в данном случае много
в данном случае много неизвестных нюансов.. большие блоки попрошенные у fs - это не обязательно большие блоки попрошенные у девайсов.
забыл добавить.. большие
забыл добавить.. большие блоки хорошо помогают в случаях, когда есть несколько потоков чтения. скажем, несколько приложений/клиентов читают с общего пула.
Не, у меня у одного ящика (на
Не, у меня у одного ящика (на котором правда пока тупо RAID6 имени адаптека, буду на ZFS переделывать) - строго сингл-юзер. Потоков - ну два, бэкап и я что-то ковыряю с фоточками.
А у второго - почти строго, туда маки домашние тайм-машинятся (но это слезы, линки медленные, гигабит и wifi), а основной потребитель по 10G - опять я один и "несколько потоков чтения" вообще не бывает.
Мне не помогло send / recive
Есть 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