Using recordsize=1M as a default for non-specialized data storage (that don't have specific recordsize recommendations)?

I have once more overthought things long enough to start secondguessing my choices, and decided to come get some advice.

My understanding of the recordsize attribute is that it sets a maximum value, and ZFS will use smaller actual record sizes where possible, up to the recordsize max, when writing data.

Since I’m not trying to squeeze every last drop of performance out of a commercial production system, for ease of use it was recommended to me by someone who admins ZFS as part of their job to go with recordsize=1M whenever I didn’t have a specific workload that needed a different value (e.g., databases and virtual machines, mostly), and ZFS would happily chug along just fine and slice and dice data writes accordingly.

Is that still good practice with the latest version of ZFS. Aside from databases and virtual machines, are there other caveats I should be aware of?

Anything that does small block random access inside larger files will punish you for an overly large recordsize. But that does mostly just mean “databases and VMs”–as long as you realize that daemon-less databases (eg sqlite, sleepycat, etc) are still databases, and if they are large enough with individual pages small enough, they’ll punish you just like a mysql or postgres DB would.

I’ve been using 1M recordsize on my non-OS/VM datasets for several years with no issue.

I’m the past, I tried this with the OS dataset out of curiosity, and found out Brave (chrome) uses a SQLite database. I didn’t just get punished on performance, but it was causing a kernel panic with the ZFS module. (It’s probably pointless to change the default recordsize on the OS for performance reasons anyway as it’s all getting cached in RAM)