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 08:29:48 -0700
Cc: david@xxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <147216835350.867.14512964799631563964.stgit@xxxxxxxxxxxxxxxx>
References: <147216791538.867.12413509832420924168.stgit@xxxxxxxxxxxxxxxx> <147216835350.867.14512964799631563964.stgit@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.6.1 (2016-04-27)
On Thu, Aug 25, 2016 at 04:39:13PM -0700, Darrick J. Wong wrote:
> From: Christoph Hellwig <hch@xxxxxx>
> 
> Have xfs_vm_bmap return zero for reflinked files.  This hack prevents
> using a file with shared blocks as a swap file, because we don't want
> to deal with CoW when we're (probably) low on memory.
> 
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> [darrick.wong@xxxxxxxxxx: add a more descriptive changelog]

Which happens to be incorrect :)  The swap code uses ->bmap to build
a logical to physical block map at swapon time (to avoid allocations
or even just block mappings under memory pressure I suspect).  This
means we'd get reliable data corruption when COWing a swap file.

> +      * The swap code (ab-)uses ->bmap to get a block mapping and then
> +      * bypasse?? the file system for actual I/O.  We really can't allow

Also it seems like I introduced some weird character instead of an
"s" here..

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