4

I'm re-building a server that needs to do awfully lot of I/O to complete the task. Is there a way to tell Linux to temporarily ignore all sync(), syncfs() and fdatasync() from any processes? I think the rebuilding would complete faster if I never wait for storage to flush caches until once when I finally unmount the storage.

I'm hoping something like

mount -o remount,nosync /path/to/mount/point

but obviously nosync does not exist (only sync and async).

I know about some hacks with LD_LIBRARY_PATH to override those syscalls but is there anything system wide that I can activate when processes have already been started?

I understand that using such a feature would force me to restart from the start if power is interrupted or the system crashes. I would happily take my changes during the rebuild process.

1
  • It would be helpful if sync could be limited to a specific filesystem but unfortunately it is commonplace for scripts and tools to simply sync everything. My problem is that I have one particularly large and extremely busy (already SSD-cached & RAID-accelerated) storage volume that no-one actually ever needs to sync (except on shutdown). But all too often package installs, system scripts etc. halt for several minutes to flush this data storage when they really wanted to flush the system disk.
    – Tronic
    Sep 24, 2021 at 1:49

1 Answer 1

1

Breaking the semantics of sync() and friends is dangerous for data integrity, if it were feasible.

Configure your application to sync() less. For a database, disable any journal and read the manual regarding what that means for recovery.

Add lots of IOPS via the fastest SSD you have. Consider adding it as a caching tier if you don't have the capacity to put it all on fast solid state.

You have not described the file system type, directory structure, or I/O patterns. These can change the storage demands considerably. For example, millions of small files is usually results in lots of metadata I/O.

Edit: if this is copying a large number of files, consider doing an image based restore. Send an entire snapshot with LVM and dd, zfs send, btrfs send, or replicate the underlying disk. Avoids all the file system metadata I/O. Which will take a long time on handful of spindles.


but obviously nosync does not exist (only sync and async).

That's not what sync and async mount options mean. They mean synchronous and asynchronous writes. async is the default, and is what you should use to not wait for every I/O.

3
  • 1
    Yeah, skipping all sync operations will cause data loss and file system corruption in case power is lost or system crashes. I mentioned about those cases and I also noted that I'm happy to restart from the start if that happens. The case I have is a storage system with archival content on HDD and this server is one of the redundant servers in the whole system. I'm trying to bring the system up as fast as possible Jul 12, 2019 at 6:36
  • There are other things you can try before doing sketchy things to your POSIX I/O functions. See my edit regarding snapshot volume based restores. Jul 12, 2019 at 13:38
  • 1
    Libeatmydata can disable most sync method on an application basis, and one some VMs it's possible to disable the data flushing on the host. While I fully agree there are risks, it's also immensely useful for installs and data recovery operations, where the risk is minimal and controlled (on a crash you can just restart, with a VM it's even possible to rollback to a good snapshot!). For that reason I wish there was also a tunable on the os itself when it's not possible to control an already running application or modify the VM host. Oct 7, 2021 at 22:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .