On Mon, Jun 16, 2014 at 6:13 PM, cwillu <cwi...@cwillu.com> wrote: > For the case of sequential writes (via write or mmap), padding writes > to page boundaries would help, if the wasted space isn't an issue. > Another approach, again assuming all other writes are appends, would > be to periodically (but frequently enough that the pages are still in > cache) read a chunk of the file and write it back in-place, with or > without an fsync. On the other hand, if you can afford to lose some > logs on a crash, not fsyncing/msyncing after each write will also > eliminate the fragmentation.
I was wondering if something could be done in btrfs to improve performance under this workload... Something like a "defrag on demand" for a case where mostly appends are happening. When there are small appends with fsync/msync, they become new fragments (as expected), but once the writes go past a block boundary, btrfs could defragment the previous block in background, since it's not really expected to change again. That could potentially achieve performance close to chattr +C without the drawbacks of disabling copy-on-write. Cheers, Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
