i write 9k but space add 20k,it not right

[perrynzhou]

• openzfs version

• I wrote a 9k file, but the space actually grew by 20k. I set ashift=12, recordsize=8k for the defi/test-8k dataset. This is totally not what I expected.

[gmelikov]

Not sure what you try to find with these commands. You may get actual file size with du command or even with zdb (but it's harder). Bear in mind that ashift is a minimal allocatable size, yes, and there are some another differences for raidz.

And - information about file is a data too, so if you allocate a file even with one byte size you'll have FS metadata with some size. And IIRC minimal dir metadata size has same minimal allocatable sizes. It's no different with other FSes. But it looks like niggling for me (I think this word is appropriate), it's better to check size of metadata for many files, because metadata may be aggregated and efficiently compressed, so one alone file in dir is not an optimal example for that.

[dodexahedron]

Adding onto that, dnodesize matters for small files, too, as files that are small enough to fit will be inlined in the dnode and thus only take up half the space that a file that is even one byte too large to fit in the dnode will take up.

OP's files are bigger than that, so that's not relevant here (just as an add-on to the above comment).

In any case, unless they are compressible to 1 block, they will not be compressed since they don't clear the 12.5% threshold for compression with recordsize=8k and ashift=12 (4k). They were written from /dev/random, so they're likely not compressible at all.

And then, since recordsize is 8k and the files are 9k, there are two records. So, I would estimate a minimum of 20K for these files, as was seen. With recordsize=16k, I would expect to see probably 12K-16K total per 9K file, assuming 4k or smaller dnodesize. And that's all without taking pool topology and also any other potential options into account.