Supondo que os conselhos sobre espaço livre para ZEVO não sejam diferentes dos conselhos para outras implementações modernas do ZFS…
Pergunta
Por favor, o que porcentagens ou quantidades de espaço livre são aconselháveis para unidades de disco rígido dos seguintes tamanhos?
Pensamentos
Uma resposta padrão para implementações modernas do ZFS pode ser "não mais que 96 por cento completo". No entanto, se aplicássemos isso a (digamos) um conjunto de dados de 640 GB de disco único onde alguns dos arquivos mais usados (pelo VirtualBox) são maiores que 15 GB cada , então eu acho que blocos para esses arquivos tornar-se sub optimamente distribuído ao longo dos pratos com cerca de 26 GB livres .
Eu li que na maioria dos casos, fragmentação e desfragmentação não devem ser uma preocupação com o ZFS. Ainda assim, eu gosto da imagem mental da maioria dos fragmentos de um grande .vdi razoavelmente próximos uns dos outros. (Os recursos do ZFS tornam esse desejo de proximidade muito antiquado?)
Nota: pode surgir a questão de como otimizar o desempenho (para arquivos massivos em um conjunto de dados com relativamente pouco espaço livre) após um limite é 'quebrado'. Se isso acontecer, vou mantê-lo separado.
Antecedentes
Em um StoreJet Transcend de 640 GB (ID do produto 0x2329) no passado, eu provavelmente fui além de um limite recomendável. Atualmente, o maior arquivo tem cerca de 17 GB -
-eduvidoquequalquerarquivo.vdiououtronestediscocresçaalémde40GB.(Ignoreasmassasroxas,essessãopacotesde8MBbandarquivos.)
SemoHFSPlus:oslimitesde vinte , dez e cinco por cento que eu associo ao sistema de arquivos do Mobile Time Machine precisam não se aplica.
Atualmente, uso o ZEVO Community Edition 1.1.1 com o Mountain Lion, OS X 10.8.2, mas gostaria que as respostas não fossem muito específicas à versão.
Referências, ordem cronológica
Alocação de blocos do ZFS (Blog de Jeff Bonwick) (2006-11-04)
Mapas espaciais (Blog de Jeff Bonwick) (2007-09-13)
Duplicação do desempenho do câmbio (Bizarre! Vous avez dit Bizarre?) (2010-03-11)
… So to solve this problem, what went in 2010/Q1 software release is
multifold. The most important thing is: we increased the threshold at
which we switched from 'first fit' (go fast) to 'best fit' (pack
tight) from 70% full to 96% full. With TB drives, each slab is at
least 5GB and 4% is still 200MB plenty of space and no need to do
anything radical before that. This gave us the biggest bang. Second,
instead of trying to reuse the same primary slabs until it failed an
allocation we decided to stop giving the primary slab this
preferential threatment as soon as the biggest allocation that could
be satisfied by a slab was down to 128K
(metaslab_df_alloc_threshold). At that point we were ready to switch
to another slab that had more free space. We also decided to reduce
the SMO bonus. Before, a slab that was 50% empty was preferred over
slabs that had never been used. In order to foster more write
aggregation, we reduced the threshold to 33% empty. This means that a
random write workload now spread to more slabs where each one will
have larger amount of free space leading to more write aggregation.
Finally we also saw that slab loading was contributing to lower
performance and implemented a slab prefetch mechanism to reduce down
time associated with that operation.
The conjunction of all these changes lead to 50% improved OLTP and 70%
reduced variability from run to run …
Melhorias de OLTP no Sun Storage 7000 2010.Q1 (Perfis de desempenho) (2010-03-11)
O Alasdair em Tudo »O ZFS é executado realmente lentamente quando o uso do disco livre ultrapassa 80% (2010-07-18), onde os comentários incluem:
… OpenSolaris has changed this in onnv revision 11146 …
[CFT] Melhor código de metaslab do ZFS (velocidade de gravação mais rápida) ( 2010-08-22)