Hello, This is a revised patch according to Christoph's comments at V4. Changes to V5: -- * Revise xfs_has_unwritten_buffer() to lookup pages match tag. * For unwritten extents, in both xfs_seek_data
Hey Jeff, I got caught up on versions 1-4, and am looking at this now. Thanks for your excellent contribution! I have some inital comments here, and then I'll get into it a little more deeply. You sh
Hi Ben, Thanks for your timely response and pointing this out! I am suffering with a data loss when improving seek copy tester to produce a file with around thousands of extents these days, looks the
Hey Jeff, Here are a few additional minor comments from yesterday. I'm looking forward to seeing your next version, and I'm still working through this one. I would like to suggest that you split this
Good work. I know this is an important addition. The test in the for loop of the xfs_seek_data() and xfs_seek_hole() routines, are independent of each other except in order of them being called. One
xfs_bmapi_read() returns the br_state == XFS_EXT_NORM for a hole. There are a couple places that a hole can trigger a data test. BTW, I could not generate a large enough hole that xfs_bmapi_read() wo
xfs_has_unwritten_buffer() always returns the offset of the first dirty unwritten page. This can cause xfs_seek_data() and xfs_seek_hole() to give the wrong results in certain circumstances. In xfs_s
Hey Jeff, Ok, since I'm the jackass who is asking you to do the extra work I'll try to be of assistance. Understand that at this point I'm trying to make sure that I understand your code fully. I'm n
Hi Ben, Thank you for pointing this out! ok. I will take care the same issues below too. ok. :) Definitely! I have gone through other file systems have SEEK_XXX stuff support, OCFS2 returns -EINVAL i
Hi Ben, Thanks a lot for your so much detailed info! Do you means I only need to post a patch to treat unwritten extents as data next time, and then try to work out another patch for probing unwritte
Hi Mark, Thanks for your comments! Yes, this is key point I have missed before. Ok, I'll add !isnullstartblock() test for normal extents test. looks this issue is caused by missing hole test for exte
Hi Mark, Sorry, am was well understood your opinions in this point for now. IMHO, we can only find and return the data buffer offset at a dirty or unwritten page once the first page was probed. Hmm,
xfs_has_unwritten_buffer() always returns the offset of the first dirty unwritten page. This can cause xfs_seek_data() and xfs_seek_hole() to give the wrong results in certain circumstances. Sorry,
With all the complications that we got compared to the initial version, namely multiple hole extents, dirty unwritten extent detection and so on I think it's time to stop using xfs_bmapi_read against
We've been through this before, you need to overflow the 32-bit extent length counter to get there. Jeff, did you manage to create a test case for that particular scenario?
Are you testing on ia64 with 64k blocks? :) xfs_bmapi_read will find holes down to block granularity, that's how it's implemented. However recent XFS does fairly aggressive preallocation, so you prob
Hey, c) having a cursor here means that Jeff can always get the job done with a single btree search, which could be an important optimisation for heavily preallocated workloads. I agree that this is
Good catch! Looks we need to examine the max value between seekoff and For SEEK_DATA, if the seekoff is less than map->br_startoff, IMHO, we need to pass the map->br_startoff to it. By combining with