> On May 31, 2024, at 10:53 AM, Wengang Wang <wen.gang.wang@xxxxxxxxxx> wrote: > > > >> On May 31, 2024, at 9:00 AM, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: >> >> On Mon, May 20, 2024 at 10:42:02PM +0000, Wengang Wang wrote: >>> Thanks Darrick for review, pls see inlines: >>> >>>> On May 20, 2024, at 11:08 AM, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: >>>> >>>> On Fri, May 17, 2024 at 02:26:21PM -0700, Wengang Wang wrote: >>>>> Unsharing blocks is implemented by doing CoW to those blocks. That has a side >>>>> effect that some new allocatd blocks remain in inode Cow fork. As unsharing blocks >>>> >>>> allocated >>>> >>>>> has no hint that future writes would like come to the blocks that follow the >>>>> unshared ones, the extra blocks in Cow fork is meaningless. >>>>> >>>>> This patch makes that no new blocks caused by unshare remain in Cow fork. >>>>> The change in xfs_get_extsz_hint() makes the new blocks have more change to be >>>>> contigurous in unshare path when there are multiple extents to unshare. >>>> >>>> contiguous >>>> >>> Sorry for typos. >>> >>>> Aha, so you're trying to combat fragmentation by making unshare use >>>> delayed allocation so that we try to allocate one big extent all at once >>>> instead of doing this piece by piece. Or maybe you also don't want >>>> unshare to preallocate cow extents beyond the range requested? >>>> >>> >>> Yes, The main purpose is for the later (avoid preallocating beyond). >> >> But the user set an extent size hint, so presumably they want us to (try >> to) obey that even for unshare operations, right? > > Yeah, user might set extsize for better IO performance. But they don’t really know > much details. Consider this case: > writing to those over/beyond preallocated blocks would cause Cow. Cow includes > extra meta changes: releasing old blocks, inserting new extents to data fork and removing > staging extents from refcount tree. That’s a lot, as I think, a Cow is slower than block over-write. > In above case, the Cow is caused by unshare, rather than by shared blocks. That might be > not what user expected by setting extsize. > > May I know if this is a good reason to skip extsize setting, or we anyways honor extsize? Thanks, Wengang
