On Wed, Nov 23, 2016 at 03:26:32PM +1100, Dave Chinner wrote: > 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. Given that XFS doesn't have all the problems btrfs does, why does XFS have the same aribitrary size limit? Especially since XFS demonstrably doesn't need it? > > 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. To answer some of my own questions on the btrfs side: It looks like the btrfs implementation does have a reason for it (fixed-size arrays). > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
Attachment:
signature.asc
Description: Digital signature
