Happy to see my post is still inspires to new thoughts!
By man ext4:
barrier=0 / barrier=1
This disables / enables the use of write barriers in the jbd code. barrier=0 disables, barrier=1 enables (default). This also requires an IO stack which can support barriers, and if jbd gets an error on a barrier write, it will disable barriers again with a warning. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.
The barrier option only covers writes of journal entries, which is only one part of the I/O necessary to securely store a file. fsync is much stronger, it guarantees that file metadata (like, inode and directory entries) and file data (actual contents written into the file) have been stored.
Storj Inc. needs to carefully set the parameters for the network-wide redundancy techniques (like the Reed-Solomon parameters) to balance between safety and costs. If node software can guarantee even slightly higher level of safety, then the costs of network-wide redundancy may go down. My personal belief is that the change suggested in this thread should have negligible effect on this trade-off specifically on ext4, but I don’t know about other setups. Besides, it is Storj Inc. that has to make this decision, likely based also on facts that I have no access to.
The amount of audited data is negligible, see e.g. BrightSilence’s post. Though, I don’t know what’s the exact answer to your question, sorry, nor to the next one.