История изменений
Исправление
zgen,
(текущая версия)
:
Ты написал херню, твой расчет из размера блока 1mb, тогда как блок динамический, и ты сам пишешь о том, что усреднение в 256k более близко к реальности.
Твои рассуждения можно было бы закончить в месте, где для диска требуется 3.7GB только для хранения таблицы совпадений. При имеющихся у автора 4GB. Тогда как есть еще кэш самой zfs без которой оно будет нещадно тормозить и нужды системы и приложений.
Сам же говоришь «зависит от данных» и сам же приводишь расчет основываясь на сферических данных в вакууме. Тем временем автор утверждения «5GB/TB» проделал ровно то же самое и объяснил что-куда отнюдь не в короткой статье -
constant@walkuere:~$ zdb -b oracle
Traversing all blocks to verify nothing leaked ...
No leaks (block sum matches space maps exactly)
bp count: 306575
SPA allocated: 17891765760 used: 52.48%
The number to look for here is bp count which is the number of block pointers, hence the number of blocks in the pool.
In this example, the dedup table would take up 306575 blocks * 320 bytes, which yields around 100 MB. This file system has a size of 32GB, so we can assume that the dedup table can only grow to about 200 MB, since it's about 50% full now.
И если ты теоретик - то я практик, и результат включения дедупликации 3TB массива raidz с 16GB озу знаю на себе
Исходная версия
zgen,
:
Ты написал херню, твой расчет из размера блока 1mb, тогда как блок динамический, и ты сам пишешь о том, что 256k.
Твои рассуждения можно было бы закончить в месте, где для диска требуется 3.7GB только для хранения таблицы совпадений. При имеющихся у автора 4GB. Тогда как есть еще кэш самой zfs без которой оно будет нещадно тормозить и нужны системы и приложений.
Сам же говоришь «зависит от данных» и сам же приводишь расчет основываясь на сферических данных в вакууме. Тем временем автор утверждения «5GB/TB» проделал ровно то же самое и объяснил что-куда отнюдь не в короткой статье -
constant@walkuere:~$ zdb -b oracle
Traversing all blocks to verify nothing leaked ...
No leaks (block sum matches space maps exactly)
bp count: 306575
SPA allocated: 17891765760 used: 52.48%
The number to look for here is bp count which is the number of block pointers, hence the number of blocks in the pool.
In this example, the dedup table would take up 306575 blocks * 320 bytes, which yields around 100 MB. This file system has a size of 32GB, so we can assume that the dedup table can only grow to about 200 MB, since it's about 50% full now.
И если ты теоретик - то я практик, и результат включения дедупликации 3TB массива raidz с 16GB озу знаю на себе