On 01/22/2018 01:33 PM, Sebastian Ochmann wrote: [ skipping to the traces ;) ]
2866 ffmpeg-mux D [<ffffffffc06251b1>] btrfs_start_ordered_extent+0x101/0x130 [btrfs] [<ffffffffc061b0b0>] lock_and_cleanup_extent_if_need+0x340/0x380 [btrfs] [<ffffffffc061c3c1>] __btrfs_buffered_write+0x261/0x740 [btrfs] [<ffffffffc06202bf>] btrfs_file_write_iter+0x20f/0x650 [btrfs] [<ffffffff9b235309>] __vfs_write+0xf9/0x170 [<ffffffff9b23551d>] vfs_write+0xad/0x1a0 [<ffffffff9b235762>] SyS_write+0x52/0xc0 [<ffffffff9b800083>] entry_SYSCALL_64_fastpath+0x1a/0x7d [<ffffffffffffffff>] 0xffffffffffffffff
This is where we wait for writes that are already in flight before we're allowed to redirty those pages in the file. It'll happen when we either overwrite a page in the file that we've already written, or when we're trickling down writes slowly in non-4K aligned writes.
You can probably figure out pretty quickly which is the case by stracing ffmpeg-mux. Since lower dirty ratios made it happen more often for you, my guess is the app is sending down unaligned writes.
-chris -- 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
