Hi folks, A couple of optimisations and a bug fix that I don't think we could trigger. The bug fix was that we weren't passing the segment offset into the buffer log item sizing calculation, so we weren't calculating when we spanned discontiguous pages in the buffers correctly. I don't think this ever mattered, because all buffers larger than a single page are vmapped (so a contiguous virtual address range) and the only direct mapped buffers we have are inode cluster buffers and they never span discontiguous extents. Hence while the code is clearly wrong, we never actually trigger the situation where it results in an incorrect calculation. However, changing the way we calculate the size of the dirty regions is difficult if we don't do this calc the same way as the formatting code, so fix it. The first optimisation is simply a mechanism to reduce the amount of allocation and freeing overhead on the buffer item shadow buffer as we increase the amount of the buffer that is dirty as we relog it. The last optimisation is (finally) addressing the overhead of bitmap based dirty tracking of the buffer log item. We walk a bit at a time, calling xfs_buf_offset() at least twice for each bit in both the size and the formatting code to see if the region crosses a discontiguity in the buffer address space. This is expensive. The log recovery code uses contiguous bit range detection to do the same thing, so I've updated the logging code to operate on contiguous bit ranges and only fall back to bit-by-bit checking in the rare case that a contiguous dirty range spans an address space discontiguity and hence has to be split into multiple regions to copy it into the log. This enables big performance improvements when using large directory block sizes. Cheers, Dave.
