Slow clone creation: per-clone recursive chown dominates provisioning time

Summary

Clone creation runs chown -R over the entire data directory on every clone. The thin (ZFS) clone itself is instant and Postgres startup is fast, so on large databases this recursive ownership walk becomes the dominant cost of provisioning a clone.

Impact

"Instant" clone creation takes noticeably longer than expected on large datasets. Ownership is re-applied recursively across the whole PGDATA for each clone instead of being established once, so the cost scales with the number of files and is paid on every clone. It is further amplified when the pool is near capacity (ZFS allocation slows past ~80% used) and under concurrent clone create/destroy load.

Proposed fix

Establish data ownership once when preparing a snapshot, so clones inherit correct ownership and skip the per-clone recursive walk. Keep a conditional per-clone chown as a safety net so that:

• clones from snapshots created before the change remain correct (no flag day during rollout);
• the internal pre-clone (built from an un-normalized source) is still handled before promotion.

Notes

• The speedup applies to clones from snapshots created after the change; clones from existing snapshots fast-path once those snapshots are refreshed.
• LVM mode is unaffected (volume ownership is managed at the volume level).