xfs
[Top] [All Lists]

Re: [PATCH 67/71] xfs: fail ->bmap for reflink inodes

To: "Darrick J. Wong" <darrick.wong@xxxxxxxxxx>
Subject: Re: [PATCH 67/71] xfs: fail ->bmap for reflink inodes
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 6 Sep 2016 10:02:22 -0700
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, david@xxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160906162651.GB16696@xxxxxxxxxxxxxxxx>
References: <147216791538.867.12413509832420924168.stgit@xxxxxxxxxxxxxxxx> <147216835350.867.14512964799631563964.stgit@xxxxxxxxxxxxxxxx> <20160906152948.GB9760@xxxxxxxxxxxxx> <20160906162651.GB16696@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.6.1 (2016-04-27)
On Tue, Sep 06, 2016 at 09:26:51AM -0700, Darrick J. Wong wrote:
> Yeah, at the time I thought I was going to write out a clever resolution to 
> the
> conflict between swap and CoW by using swap_activate to punch and fallocate 
> all
> the shared extents and turn off the inode reflink flag which would then enable
> me to drop this patch altogether, but then got busy and forgot all about it.
> Clearly I didn't fix the changelog here either. :(

I looked at that, but that code is such a mess, doing reads through
->readpage and writes using direct_IO and requiring all kinds of ropes
to jump through..

> "Have xfs_vm_bmap return zero for reflinked files because the bmap-based
> swap code requires static block mappings, which is incompatible with
> copy on write."

Sounds fine.  Might be worth addings something like: "And existing
userspace bmap users such as lilo will have the same problems".

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