On Sat, Jan 20, 2018 at 09:33:49PM -0800, Darrick J. Wong wrote: > Hi all, > > Running generic/232 with quotas and reflink demonstrated that there was > something wrong with the way we did quota accounting -- on an otherwise > idle system, fs-wide du block count numbers didn't match the quota > reports. I started digging into why the quota accounting was wrong, and > the following are the results of my bug hunt. Well, I wasn't expecting 4.15 to be delayed again, but I guess it has. To disambiguate: this series is intended for 4.16, even though I already sent out the AGFL series tagged for 4.17. --D > The first patch teaches the reflink code to break layout leases before > commencing the block remapping work. This time we avoid the "looping > trying to get a lock" that Christoph complained about, in favor of > dropping both locks and retrying if we can't cleanly break the layouts > without waiting. > > The second patch changes the source file locking (if src != dest) during > a reflink operation to take the shared locks when possible. The only > thing changing in the source file is the setting of the reflink iflag, > for which we will still take ILOCK_EXCL. The net result of this is > less lock contention during fsstress and a 30% lower runtime, not that > anyone cares about fsstress benchmarking. :) > > Patch three ensure that we attach dquots to inodes before we start > reflinking their blocks. This could lead to quota undercharging; an > fstest to check this will be sent separately. > > Patch four reorganizes the copy on write quota updating code to reflect > how the CoW fork works now. In short, the CoW fork is entirely in > memory, so we can only use the in-memory quota reservation counters for > all CoW blocks; the accounting only becomes permanent if we remap an > extent into the data fork. > > Patch five creates a separate i_cow_blocks counter to track all the CoW > blocks assigned to a file, which makes changing a file's uid/gid/prjid > easier, makes reporting cow blocks via stat easy, and enables various > cleanups. > > Patch six fixes a serious potential corruption problem with the cow > extent allocation -- when we allocate into the CoW fork with the cow > extent size hint set, the allocator enlarges the allocation request to > try to hit alignment goals. However, if the allocated extent does not > actually fulfill any of the requested range, we send a garbage > zero-length extent back to the iomap code (which also doesn't notice), > and the write lands at the startblock of the garbage extent. The fix is > to detect that we didn't fill the entire requested range and fix up the > returned mapping so that we always fill the first block of the > requested allocation. > > --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
