pool and or dataset must be upgraded

[Mike83]

Hi

I'm trying to change my compression in a dataset(?) its currently set to lzjb and I noticed in 9.2.1.2 its saying its legacy and not recommended, so I try changing to the recommended lz4 but it says it must be upgraded. I can't see where or how I upgrade?

Thanks

 

[cyberjock]

yeah.. lz4 requires your zpool to be v5000 and I believe it may also require a feature flag. Do "zpool upgrade <poolname>" to upgrade. Be warned, this is a 1 way street. Once you upgrade you will NEVER be able to downgrade the pool or use it on an OS that doesn't have support for v5000 and the exact flags that FreeNAS 9.2.1.2 uses. Please, do your homework and be absolutely sure that you will never ever try to downgrade FreeNAS 9.2.1.x to any older version as the only option after that will be to destroy the pool.

 

[Mike83]

OK thanks, I will think about it. I don't think I will ever downgrade FreeNas and probably won't change from FreeNas. Is lz4 compression worth it then? Is any compression worth it? Most things I store are compressed some way.

 

[Mike83]

I decided to upgrade the dataset, changed to lz4 and I'm sure its a lot faster now, used to get around 66MB/s now around 90MB/s

 

[cyberjock]

Not the least bit surprising since LZMA is very CPU intensive. ;)

If you look closely you'll see you get more speed, but your compression ratio will be lower with lz4. :(

 

[Mike83]

I assumed it would be higher :( Ah well, I'm having a look at the config page, it now says compression : lz4, compression ratio : 1.02x
Before I upgraded I'm sure it was lzjb and 1.01x ? Does that mean its lower compression? It seems a small amount of difference.

Also does it compress everything with lz4 as soon as you change to it? Because I thought it would be better compressed (before I read your post) I have been putting some content off my NAS onto a local disk, then deleting it off the NAS and then copying it back to NAS again!

 

[cyberjock]

Heck no, lz4 is not going to be higher. lz4 is based around providing an ultra fast compression scheme. It's not meant to have a high ratio(that's what the CPU intensive schemes like lzma do).

1.02 is better than 1.01, but you are talking a fraction of a percent. Not exactly statistically valid at all. That's literally nothing more than a possible rounding error.

It only compresses new data with the chosen scheme.

 

[Mike83]

OK thanks for the info.