Do all records of a file need to be the same size?

[MrRinkana]

Hello! Basically:

If I have an incompressible 1.1MiB file on a dataset with recordsize set to 1MiB, will the file be stored:

• On one 1MiB record and one 129KiB record, or
• On two 1MiB records?

I remember reading that all records of a file needed to be the same size, but can't find that source now and the https://openzfs.github.io/openzfs-docs/man/v2.3/7/zfsprops.7.html#recordsize does not help in that regard (it's also in need of updating, but that's a different matter).

[IvanVolosyuk]

There are a three block sizes stored in block pointer according to https://www.giis.co.in/Zfs_ondiskformat.pdf:

• lsize: Logical size. The size of the data without compression, raidz or gang overhead.
• psize: physical size of the block on disk after compression
• asize: allocated size, total size of all blocks allocated to hold this data including any gang headers or raid-Z parity information

If compression is turned off and ZFS is not on Raid-Z storage, lsize, asize, and psize will all be equal.

I would guess that if compression is enabled the second block will be stored more efficiently as it padded with compressible zeros. It will use as many a-shift sized 'sectors' as needed. It seems that if compression is off - the last block will use full 1MiB on disk, which is kinda strange IMHO.

[MrRinkana]

So basically my example 1.1MiB file would be stored like this:

compression=on
lsize: 2x 1MiB records
psize: 1MiB + 128KiB (or smaller factor of ashift?: whatever fits 102,4KiB data + compressed 921.6KiB zeroes)

compression=off
lsize: 2x 1MiB records
psize: 2x 1MiB records

asize i guess depends on other pool settings, but is it lsize+headers+parity+w/e or psize+headers+parity+w/e?
Ignoring paroty information and such, could a 19MiB dataset store ten such 1,1MiB files (or is a 20MiB+ dataset needed)?

Or am I misunderstanding? Is there someone that can confirm IvanVolosyuks guess?

[amotin]

asize primarily depends on the underlying disk physical sector size, unless overridden during the vdev creation.

If I guess right with 19MiB dataset you mean quota=19M, then with compression -- likely yes, without -- no.

[amotin]

For a note: #15215

[snajpa]

will the file be stored

depends on how fast it's written - if you drip data into it slowly, it can end up stored in way more smaller blocks

when a file is freshly created, it has 0 z_blksz, it's the first modification, which sets it to something in zfs_grow_blocksize (happens in zfs_write or zfs_clone_range), depending on how much data is written on that first pass and also on dataset's recordsize

then when a last block of a file is being modified in zfs_write or zfs_clone_range, it can be grown again, if it's not maxed out already

so, depending on how fast you write the file, I would say it ends up in two 1MB blocks, if the write is fast and the dataset can take 1MB blocks

[amotin]

it can end up stored in way more smaller blocks

It should not. As you described, as long as the block size is smaller than dataset's recordsize, it should grow with writes. IIRC there were oddities in block cloning, but IIRC I've blocked many short blocks production there too.