Benefits or drawbacks to `truncate` vs `fallocate` for file-based pool

[feinedsquirrel]

Follow up from my question here:

Using a truncated file for not just practice, but production?

I’ve used truncated files plenty of times, playing with different zfs configurations, commands, etc. to practice and learn. It is a powerful playground. Eventually, my laptop will have a proper partition for zfs, but I am not able to configure that at the moment. I’m stuck with a single ext4 partition across the whole drive. I have a “server” at home with a pool of dedicated drives, and I also backup pool for that production pool. I often take care of family administration tasks (paying bills…

Evidence says it is possible, and stable, to use a file for a production pool under restricted available options. That question was fully answered and solved, so I’m opening this new, related question.

Doing some research, I found:

Difference between writing file from /dev/zero and truncate

If I am going to use a file for a prod pool, it seems I have two options:

• truncate - creates a sparse file (at least on ext4?) and any data written to it will result in fragments being written to disk
• fallocate - sparse file, actual addresses reserved, so no fragmenting (at least until possibly an expansion, though looks like an expansion could be made without fragmenting it)

This file in which the zpool would be created is on an ssd. So I’m inclined just to use truncate, so that the controller can wear-level more freely, and, fragmentation doesn’t matter for speed.

Any other consideration I should make?

edit: add link, minor formatting