Basically, the space available is calculated based on the original raidz width and 128k block size.
This means that it is always going to be an underestimate once you add additionally disks.
Oops.
And that’s bascally all there is to it.
I’m not sure of the consequences, but this seems problematic… and perhaps should be taken care of in the UI at least… if it can’t be fixed in ZFS proper
So, 33GB / (3/5s) = 55GB.
That is not something the user should have to do in their head.
You need to have a fairly accurate idea of how much capacity you’re working with. Nearly 18 TiB of “discrepancy” after completing two RAIDZ expansions (after parity is taken into account) is beyond a reasonable range of measure.
it seems to be reported as smaller than it actually is. this is a video file that I just ripped today, it also is reporting a massive size discrepancy on the disk. It’s also important to note that video media such as this can’t easily be compressed losslessly (which shouldn’t account for the size discrep.)
It would be nice if there was a warning somewhere that usable capacity (used + unused) wouldn’t match expectations, but a better idea is to tell the user what they reasonably should expect.
admin@truenas[~]$ cd /mnt/gen-pop/userspace/disk\ rip\ work/'Babylon 5 - Season 1 disk 1'
admin@truenas[... rip work/Babylon 5 - Season 1 disk 1]$ du -h 'Babylon 5 - Season 1_t03 midnight on the firing line.mkv'
6.1G Babylon 5 - Season 1_t03 midnight on the firing line.mkv
admin@truenas[... rip work/Babylon 5 - Season 1 disk 1]$ du -h --apparent-size 'Babylon 5 - Season 1_t03 midnight on the firing line.mkv'
8.6G Babylon 5 - Season 1_t03 midnight on the firing line.mkv
admin@truenas[... rip work/Babylon 5 - Season 1 disk 1]$ ls -l 'Babylon 5 - Season 1_t03 midnight on the firing line.mkv'
-rwxrwxr-x+ 1 Hittsy Hittsy 9139538849 Oct 16 22:28 'Babylon 5 - Season 1_t03 midnight on the firing line.mkv'
admin@truenas[... rip work/Babylon 5 - Season 1 disk 1]$
Exactly, I have had a similar experience so far as well. Went from a 4 wide RaidZ2 to 8 wide with 7.28 TiB drives. I was expecting at least something close to 43.7 TiB total, ended up with 28 TiB reported by the ui, or just over two entire drives less than expected. Doing a rebalance has reclaimed some of the available space, but the total usable space hasn’t changed.
In what world is a video file actually 8.6 GiB in size… but only consumes 6.1 GiB of storage space?
Really, ZFS? You’re going to play us like that?
I’m being serious, even though this seems like a joke.
How are people who use ZFS with RAIDZ + (RAIDZ expansion) supposed to plan for and gauge their storage capacity, let alone understand how much space is being used up, when there are multiple discrepancies of information?
I’m not talking about the technical grit that “explains” this. I’m looking at this from the end-user’s perspective.
Let’s use the above example. How large is the video file? How much storage does it consume on the ZFS pool? Are we really to believe it is 8.6 GiB, yet only impacts 6.1 GiB of pool storage?
EDIT: @Hittsy, are you using deduplication? (Not that I would expect it would have much of an impact on video files.)
If anyone can share with me how to losslessly shrink my video files by 30%, I will pay you a hefty sum of money.
For the record, every single video file on my TrueNAS server, shows an identical[1] value with du between “usage on disk” and “apparent file size”, which is also corroborated with ls -l and when viewing the file’s properties with an application over SMB.
It doesn’t matter if it was saved with LZ4 or ZSTD-9.
Don’t get pedantic with me. You know what I mean when I casually say “identical”. ↩︎
@winnielinnie
deduplication is disabled on this pool. @awalkerix
Since then and now, I did move and rename the file, as I was ripping it for plex purposes (and needed to put it in the correct directory), but other attributes should and do remain the same.
as we can see, the size and allocation size vary wildly
edit: I would like to mention that zfs get all [pool/dataset] | grep compressratio reports my entire content dataset as having a 1.01 compression ratio
no, all of my content has such a discrepancy
these are all remuxes, from either blu-ray disks or 4k UHD blu-ray disks.
(yes, lawrence of arabia UHD does come on 2 disks, and I did stitch them together with mkvtoolnix, but that was well before I did any zfs expansion - I chose it because it was the largest file I had.)
