On Tue, Nov 22, 2016 at 09:02:10PM -0500, Zygo Blaxell wrote: > On Thu, Nov 17, 2016 at 04:07:48PM -0800, Omar Sandoval wrote: > > 3. Both XFS and Btrfs cap each dedupe operation to 16MB, but the > > implicit EOF gets around this in the existing XFS implementation. I > > copied this for the Btrfs implementation. > > Somewhat tangential to this patch, but on the dedup topic: Can we raise > or drop that 16MB limit? > > The maximum btrfs extent length is 128MB. Currently the btrfs dedup > behavior for a 128MB extent is to generate 8x16MB shared extent references > with different extent offsets to a single 128MB physical extent. > These references no longer look like the original 128MB extent to a > userspace dedup tool. That raises the difficulty level substantially > for a userspace dedup tool when it tries to figure out which extents to > keep and which to discard or rewrite. That, IMO, is a btrfs design/implementation problem, not a problem with the API. Applications are always going to end up doing things that aren't perfectly aligned to extent boundaries or sizes regardless of the size limit that is placed on the dedupe ranges. > XFS may not have this problem--I haven't checked. It doesn't - it tracks shared blocks exactly and merges adjacent extent records whenever possible. > Even if we want to keep the 16MB limit, there's also no way to query the > kernel from userspace to find out what the limit is, other than by trial > and error. It's not even in a header file, userspace just has to *know*. So add a define to the API to make it visible to applications and document it in the man page. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
