xfs
[Top] [All Lists]

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

To: "Darrick J. Wong" <darrick.wong@xxxxxxxxxx>
Subject: Re: [RFC v2 00/24] xfs: add reflink and dedupe support
From: Josef 'Jeff' Sipek <jeffpc@xxxxxxxxxxxxxx>
Date: Sat, 1 Aug 2015 09:01:31 -0400
Cc: david@xxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150729223258.17414.91354.stgit@xxxxxxxxxxxxxxxx>
References: <20150729223258.17414.91354.stgit@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
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.

Jeff.

-- 
mainframe, n.:
  An obsolete device still used by thousands of obsolete companies serving
  billions of obsolete customers and making huge obsolete profits for their
  obsolete shareholders. And this year's run twice as fast as last year's.

<Prev in Thread] Current Thread [Next in Thread>