Once the compression type is changed, all new writes will use the new compression type and any data already written will be lazily converted to the new compression type during cleaning.
The lazy conversion means that not all containers will be recompressed during first round of cleaning.
It will take several rounds of cleaning to fully recompress all the data existing on the DDRs prior to the change of compression policy.
Cleaning policy determines which containers are selected in a particular round of cleaning and only those containers will be recompressed.
The cleaning policy is mainly based on the amount of garbage data a given container holds. Garbage data means deleted data which is no longer referenced by the namespace.
The more garbage a container has, more likely it is to be selected for cleaning.
...
As a result, the first clean after changing the compression type and disabling the lazy conversion may take a much longer time to run.
Whenever changing the compression type, you should carefully monitor the system for a week or two to make sure it is behaving well.
パって削除されるわけではなさそうですね。
少しずつ、怠けながらやっていくなら、いきなり
いきなり使用量が大きくなるわけでもないようですね。
ナマケモノ(lazy conversion)を使わないとかなり遅くなるらしい…かなり違和感が…
ちなみに、逆パターンもありました。gzからｌｚの場合…(一体なぜいい圧縮率を悪くするでしょう？)
System and Cleaning Performance Impact of Converting to LZ Compression
Keep in mind that converting to a weaker compression algorithm (e.g., LZ) from a stronger one (e.g., GZ) will very likely get the system to an out-of-space condition if the system does not have at least 30-35% of free plus freeable space. Cleaning will abort itself even by only using the cleaning policy to select a container when that is not the case and the out-of-space condition is detected.
ToT2
1 Rookie
1 Rookie
•
19 メッセージ
0
2015年11月30日 00:00
どんな風と言われると現代風ではなさそうですね。自問自答の自由
調べたところ、下のKBは回答になりそうだけど、、、
System and Cleaning Performance Impact of Converting to GZ Compression
https://support.emc.com/kb/180972
抜粋:
Once the compression type is changed, all new writes will use the new compression type and any data already written will be lazily converted to the new compression type during cleaning.
The lazy conversion means that not all containers will be recompressed during first round of cleaning.
It will take several rounds of cleaning to fully recompress all the data existing on the DDRs prior to the change of compression policy.
Cleaning policy determines which containers are selected in a particular round of cleaning and only those containers will be recompressed.
The cleaning policy is mainly based on the amount of garbage data a given container holds. Garbage data means deleted data which is no longer referenced by the namespace.
The more garbage a container has, more likely it is to be selected for cleaning.
...
As a result, the first clean after changing the compression type and disabling the lazy conversion may take a much longer time to run.
Whenever changing the compression type, you should carefully monitor the system for a week or two to make sure it is behaving well.
パって削除されるわけではなさそうですね。
少しずつ、怠けながらやっていくなら、いきなり
いきなり使用量が大きくなるわけでもないようですね。
ナマケモノ(lazy conversion)を使わないとかなり遅くなるらしい…
かなり違和感が…
ちなみに、逆パターンもありました。gzからｌｚの場合…(一体なぜいい圧縮率を悪くするでしょう？)
System and Cleaning Performance Impact of Converting to LZ Compression
https://support.emc.com/kb/180977
抜粋:
Keep in mind that converting to a weaker compression algorithm (e.g., LZ) from a stronger one (e.g., GZ) will very likely get the system to an out-of-space condition if the system does not have at least 30-35% of free plus freeable space. Cleaning will abort itself even by only using the cleaning policy to select a container when that is not the case and the out-of-space condition is detected.
他の部分はKB 180972とほぼ同じですけど、30-35%の余裕を確保してから行う方が安全と言っているようですね。
推理すれば、高い圧縮率のタイプ(gz)から低い圧縮率タイプ(lz)に変更する時、フリースペース35%ぐらい確保すれば行えるなら、
低い圧縮率タイプ(lz)から高い圧縮率のタイプ(gz)に変更する時にも35%のフリースペースあれば十分でしょう（証拠がありません。察してください。）
m(_ _)m実際に行った方がいれば、教えていただけますでしょうか？
よろしくお願いいたします。