Hello,
I attached to the ffmpeg-mux process for a little while and pasted the
result here:
https://pastebin.com/XHaMLX8z
Can you help me with interpreting this result? If you'd like me to run
strace with specific options, please let me know. This is a level of
debugging I'm not dealing with on a daily basis. :)
Best regards
Sebastian
On 22.01.2018 20:08, Chris Mason wrote:
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
