On 7:35 20/03, Christoph Hellwig wrote: > On Fri, Mar 20, 2020 at 10:23:43AM -0400, Josef Bacik wrote: > > I'm not sure what you're looking at specifically wrt error handling, but I > > can explain __endio_write_update_ordered. > > > > Btrfs has ordered extents to keep track of an extent that currently has IO > > being done on it. Generally that IO takes multiple bio's, so we keep track > > of the outstanding size of the IO being done, and each bio completes and > > thus removes its size from the pending size. If any one of those bios has > > an error we need to make sure we discard the whole ordered extent, as part > > of it won't be valid. Just a cursory look at the current code I assume > > that's what's confusing you, we call this when we have an error in the > > O_DIRECT code. This is just so we get the proper cleanup for the ordered > > extent. People will wait on the ordered extent to be completed, so if we've > > started an ordered extent and aren't able to complete the range we need to > > do __endio_write_update_ordered() so that the ordered extent is finished and > > we wakeup any waiters. > > > > Does this help? If I need to I can context switch into whatever you're > > looking at, but I'm going to avoid looking and hope I can just shout useful > > information in your direction ;). Thanks, > > Yes, this helps a lot. This is about the patches from Goldwyn to > convert btrfs to use the iomap direct I/O code. And in that series > he currently calls __endio_write_update_ordered from the ->iomap_end > method, which for direct I/O is called after all bios are submitted > to complete ordered extents for a range after an I/O error, that > is one that no I/O has been submitted to, and the accounting for that > is a little complicated.. I think you meant "some" instead of "no". Yes, keeping the information in iomap->private and setting in btrfs_submit_direct() would be better. I will modify the code and re-test. Thanks! -- Goldwyn
