54bab59901
There are cases where EXT4 is a bit too conservative sending barriers down to the disk; there are cases where the transaction in progress is not the one that sent the barrier (in other words: the fsync is for a file for which the IO happened more time ago and all data was already sent to the disk). For that case, a more performing tradeoff can be made on SSD devices (which have the ability to flush their dram caches in a hurry on a power fail event) where the barrier gets sent to the disk, but we don't need to wait for the barrier to complete. Any consecutive IO will block on the barrier correctly. Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com> (cherry picked from commit 74aa09a7751e438bd15b5cd73f611021b7239240) (cherry picked from commit fa3bdf1a32cac074ff52403cb9ce18eb18c7f7d1) |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kunit | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| memory | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| scsc | ||
| scsi | ||
| sdp | ||
| soc | ||
| sound | ||
| target | ||
| test | ||
| trace | ||
| uapi | ||
| variant1/linux | ||
| vdso | ||
| video | ||
| xen | ||