Home / server / Questions / 1014770
In Process
Simon Richter
Asked: 2020-04-30 02:55:01 +0800 CST

Can I sacrifice persistence for performance?

  • 772

I'm trying to optimize my setup for automatic compilation. If the build fails, it will be restarted from scratch anyway, so it would be acceptable to lose an entire subtree of files (the working directory) on a power outage, but the file system should in any case come back into a consistent state, so the journal should be sufficient to delete files, but not much more.

Is there a file system that allows me to specify "losing this data is acceptable" to improve performance?

The closest I've got so far would be a tmpfs and lots of swap space, but that seems like a crude hack, and doesn't allow me to keep data that is consistent.

linux filesystems

1 Answers

  1. This being Linux, almost certainly there is a novelty file system or tuning parameter you could be tweaking. Start by not doing that.

    Operationally, simpler to standardize on a file system type, give scratch directories sufficiently fast but possibly non-redundant storage, and revisit performance if it does not meet requirements.

    First, define measurable user visible performance requirements. For example, builds complete in under 15 minutes. Exceeding these metrics make this an exercise in premature optimization.

    Consistent data is on crash is a significant constraint.

    tmpfs on not-persistent DRAM can't survive a power loss. Consistency of being entirely lost does not sound like what you wanted.

    Not trivial on persistent file systems either. File systems might improve performance with compromises: preserve file system consistency first, and data contents second. Also, not every write at the application level is flushed to permanent storage immediately. Good database systems spend considerable extra effort improving their chances of recovery, fsync() their own journals and the like.

    But this crash recovery constraint is not necessary, as the build thing can be restarted on failure. One implementation that treats the working directory as scratch space:

    • Get a high IOPS block device. Does not have to be a storage array, replicated, or backed up, single local SSD is fine.
    • Use a file system you are familiar with and you can get support for. xfs or ext4 are common. This contains your working directory.
    • On every run, destroy the contents and replace with fresh inputs.
    • Successful runs copy outputs to permanent storage. Host panics or reboots recover a consistent file system, in case that is interesting before the next run.

    Continue to monitor, and investigate if performance is unsatisfactory. Keep in mind storage is far from the only possible limiting factor in performance issues.

    • 1