Compression despite deactivated compression level

[Skywalker]

Hi guys,
I have a question about compression of files in TrueNAS. I have created different datasets with different compression levels. On one dataset I deliberately disabled compression and still the files were reduced by about 5% by ZFS i.e. compressed. Does ZFS still do an internal minimal file compression despite disabled compression?

many thanks

 

[sretalla]

Are you talking about files that were already there when you turned off compression? (those will remain compressed).

 

[Skywalker]

Are you talking about files that were already there when you turned off compression? (those will remain compressed).

No, in the first step I created the dataset, then deactivated the compression and only then copied the file to the dataset

 

[sretalla]

And how exactly are you determining that the compression is happening?

 

[Skywalker]

And how exactly are you determining that the compression is happening?

I use the command du -sh <Dataset>
the used memory is less than under my Mac operating system (5%)

 

[sretalla]

I don't think that's a good way to compare... are you even sure you're measuring MiB to MiB (not MB)?

In any case, you're talking about 2 different filesystems and how they report filesizes... won't necessarily be the same for the same file(s) due to record/block sizes and other things like file table allocation and padding.

 

[Skywalker]

I don't think that's a good way to compare... are you even sure you're measuring MiB to MiB (not MB)?

In any case, you're talking about 2 different filesystems and how they report filesizes... won't necessarily be the same for the same file(s) due to record/block sizes and other things like file table allocation and padding.

I must admit that I was a bit confused by the information within the system. Are we talking about mebibytes or megabytes in the system information?
On the website: https://www.ixsystems.com/documentation/truenas/11.3-U3.2/tn_intro.html
under point 1.3.7 it says "like M or MiB for megabytes or G or GiB for gigabytes".
also in my book FreeBSD Mastery: ZFS the author always talks about megabyte and never about mebibyte when evaluating with commands (in the display it says e.g. 2M and he says 2 megabyte)

what exactly is correct now?

 

[sretalla]

MiB is mebibytes

MB or M is Megabytes... same for GiB and GB/G

 

[Skywalker]

MiB is mebibytes

MB or M is Megabytes... same for GiB and GB/G

so what exactly is then displayed in the shell if the specification is M or KB? is this then also actually MiB and KiB?

 

[Whattteva]

so what exactly is then displayed in the shell if the specification is M or KB? is this then also actually MiB and KiB?

What does the web UI say under Storage -> Pools? It has a Compression Ratio field for every dataset. Is it a number above 1.0? Alternatively, you could also do zfs list -ro name,ratio <dataset_name>. That will probably be a more authoritative source than the du command, which was never built with ZFS in mind.

 

[sretalla]

You can also see that with zfs list -o name,compressratio

 

[Skywalker]

What does the web UI say under Storage -> Pools? It has a Compression Ratio field for every dataset. Is it a number above 1.0? Alternatively, you could also do zfs list -ro name,ratio <dataset_name>. That will probably be a more authoritative source than the du command, which was never built with ZFS in mind.

The ratio always says 1.0
And the size with du is 770M
but i am still confused if the shell says M for MB or M for MiB

The GUI says 770,77 MiB

It makes a huge difference when I compare those facts on bigger files :-(

 

[Whattteva]

The ratio always says 1.0
And the size with du is 770M
but i am still confused if the shell says M for MB or M for MiB

View attachment 62361

The GUI says 770,77 MiB

View attachment 62362

It makes a huge difference when I compare those facts on bigger files :-(

The general rule is, OS's generally always use MiB, while hardware manufacturers (HDD) use MB. Your ratio says 1.0, which means no compression is currently taking place.