[Top] [All Lists]

Re: question re: xfs inode to inode copy implementation

To: xfs@xxxxxxxxxxx, vito.caputo@xxxxxxxxxx
Subject: Re: question re: xfs inode to inode copy implementation
From: "Darrick J. Wong" <darrick.wong@xxxxxxxxxx>
Date: Mon, 20 Apr 2015 21:28:20 -0700
Cc: xfs <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150421010646.GX8110@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20150421010646.GX8110@xxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Apr 20, 2015 at 08:06:46PM -0500, xfs@xxxxxxxxxxx wrote:
> Hello list,
> I'm prototyping something like reflinks in xfs and was wondering if
> anyone could give me some pointers on the best way to duplicate the

Heh, funny, I'm working on that too...

> blocks of the shared inode at the reflink inode, the copy which must
> occur when breaking the link.

...though I'm not sure what "the shared inode at the reflink inode" means.
Are there somehow three inodes involved with reflinking one file to another?

> It would be nice to do the transfer via the page cache after allocating
> the space at the desintation inode, but it doesn't seem like I can use
> any of the kernel helpers for copying the data via the address_space
> structs since I don't have a struct file on hand for the copy source.
> I'm doing this in xfs_file_open() so the only struct file I have is the
> file being opened for writing - the destination of the copy.

So you're cloning the entire file's contents (i.e. breaking the reflink) as
soon as the file is opened rw?

> What I do have on hand is the shared inode and the destination inode
> opened and ready to go, and the struct file for the destination.

The design I'm pursuing is different from yours, I think -- two files can use
the regular bmbt to point to the same physical blocks, and there's a per-ag
btree that tracks reference counts for physical extents.  What I'd like to do
for the CoW operation is to clone the page (somehow), change the bmbt mapping
to "delayed allocation", and let the dirty pages flush out like normal.

I haven't figured out /how/ to do this, mind you.  The rest of the bookkeeping
parts are already written, though.

With reflink enabled, xfsrepair theoretically can solve multiply claimed blocks
by simply adding the appropriate agblock:refcount entry to the refcount btree
and it's done.

> My prototype already mostly works just using xfs_alloc_file_space() to
> allocate the appropriate space in the destination inode, but I need to
> get that allocated space populated from the shared inode's extents.

I think you're asking how to copy extent map entries from one file to another?


> Any pointers appreciated, thanks!
> Regards,
> Vito Caputo
> P.S. I've seen Dave Chinner's mention of reflink prototypes in XFS on
> lwn but haven't been able to find any code, what's the status of that?
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

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