Re: [RFC v2 00/24] xfs: add reflink and dedupe support

Dave Chinner
2015-08-01T22:58:49Z

On Sat, Aug 01, 2015 at 09:01:31AM -0400, Josef 'Jeff' Sipek wrote:
> On Wed, Jul 29, 2015 at 03:32:59PM -0700, Darrick J. Wong wrote:
> > Hi all,
> >
> > This is the second revision of an RFC for adding to XFS kernel support
> > for mapping multiple file logical blocks to the same physical block,
> > more commonly known as reflinking. The implementation a single [block
> > range, refcount] tree to track the reference counts of extents of
> > physical blocks. There's also support code to provide the desired
> > copy-on-write behavior and the userland interfaces to reflink, query
> > the status of, and un-reflink files.
>
> This is cool work. I have a random thought to share... IIRC, you keep a
> per-inode flag to avoid expensive ops on files that have no refcounted
> blocks. ZFS keeps a bit in each block pointer to indicate that the target
> is dedup'd. I'd have to check if xfs has a spare bit in its block pointer,
> but if it does that's one way to minimize the refcount btree overhead.

No, we don't. We'd have to steal a bit from the extent length field,
similar to the way unwritten extents were implemented.

As it is, we still need a separate tree to track the shared extent
refcounts, so making this more fine grained to optimise freeing of
extents can be looked at further down the track once we have an idea
where the bottlenecks in the shared extent system are....

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com