Save level.dat asynchronously on the I/O thread to avoid blocking the server thread

Is your feature request related to a problem?

I currently have 27 worlds loaded on my Paper instance, but aside from the three main worlds, the rest are archive worlds in past 10 years. The three main worlds run on local high-speed NVMe SSD storage, while the archive worlds are mounted to the world path via Samba/CIFS from a slow HDD NAS on the local network since my players only visit these worlds during nostalgia events, there is no player activity on them at other times.

Due to the NAS's heavy workload (continuous backups, deduplication, compression, and checksumming) and the fact that it runs on HDDs, its I/O performance is poor. Although Paper's chunk system handles these slow read operations effectively, preventing them from affecting the game server itself, the operation to save level.dat still runs on the server thread. This causes the server to experience a spike in lag every so often (when you have a lots worlds, it will keep and continuously). Although these spikes last only a few seconds, they are still long enough to trigger the watchdog.

Stacktrace: https://mclo.gs/Np1vX9r

Describe the solution you'd like.

The saving of level.dat should be performed asynchronously on an I/O thread and should not block the server thread anyway.

Performing I/O operations on a server thread is definitely a bad idea.

Describe alternatives you've considered.

Maybe I should mount level.dat on a local high-speed HDD, but that's a hassle.
Or unload those worlds from instance.

Other

No response

Read the linked stacktrace first, then trace the level.dat save path described in the issue and identify where its I/O currently runs on the server thread. Review the save scheduling and synchronization around that path before selecting an I/O-thread boundary. Done means level.dat writes no longer block the server thread while world saves remain correct.