It seems in https://github.com/openzfs/zfs/pull/4276, design decisions are made such that ZIL is not used for hard linking O_TMPFILE. However, given the impact on real-world applications, should the decision be revised?
Describe how to reproduce the problem
Launch kde apps such as konsole on a non-ssd pool with SLOG, observe the delay in konsole window showing up.
Include any warning/errors/backtraces from the system logs
Example strace (similar operations happen multiple times on a single launch):
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.
System information
Describe the problem you're observing
Discussed in https://github.com/openzfs/zfs/discussions/13441
Based on: https://github.com/openzfs/zfs/blob/52bad4f23daaa5f827f802c8d05785a27b80275d/module/os/linux/zfs/zfs_vnops_os.c#L3427 It seems hard linking a o_tmpfile waits for txg completion even when SLOG exists. Therefore, this operation is slow on a non-ssd pool even when SLOG exists. This causes performance problems for many kde apps (e.g. konsole), since they will perform and wait for this operation several times during launch (for updating config/session file).
It seems in https://github.com/openzfs/zfs/pull/4276, design decisions are made such that ZIL is not used for hard linking O_TMPFILE. However, given the impact on real-world applications, should the decision be revised?
Describe how to reproduce the problem
Launch kde apps such as konsole on a non-ssd pool with SLOG, observe the delay in konsole window showing up.
Include any warning/errors/backtraces from the system logs
Example strace (similar operations happen multiple times on a single launch):