linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Sandeen <sandeen@redhat.com>
Cc: xfs <linux-xfs@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH V2] xfs: do not allow reflinking inodes with the dax flag set
Date: Thu, 7 Jan 2021 20:54:29 -0600	[thread overview]
Message-ID: <ec51e55e-648e-ad8b-a8dc-76b5c234637e@sandeen.net> (raw)
In-Reply-To: <20210108012952.GO6918@magnolia>

On 1/7/21 7:29 PM, Darrick J. Wong wrote:
> On Thu, Jan 07, 2021 at 03:36:34PM -0600, Eric Sandeen wrote:
>> Today, xfs_reflink_remap_prep() will reject inodes which are in the CPU
>> direct access state, i.e. IS_DAX() is true.  However, it is possible to
>> have inodes with the XFS_DIFLAG2_DAX set, but which are not activated as
>> dax, due to the flag being set after the inode was loaded.
>>
>> To avoid confusion and make the lack of dax+reflink crystal clear for the
>> user, reject reflink requests for both IS_DAX and XFS_DIFLAG2_DAX inodes
>> unless DAX mode is impossible due to mounting with -o dax=never.
> 
> I thought we were allowing arbitrary combinations of DAX & REFLINK inode
> flags now, since we're now officially ok with "you set the inode flag
> but you don't get cpu direct access because $reasons"?

*shrug* I think "haha depending on the order and the state we may or may
not let you reflink files with the dax flag set on disk so good luck" is
pretty confusing, and I figured this made things more obvious.

I thought that should be an absolute, hch thought it should be ignored
for dax=never, and now ... ?

I think the the current behavior is a bad user experience violating=
principle of least surprise, but I guess we don't have agreement on that.

-Eric

> --D
> 
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>> V2: Allow reflinking dax-flagged inodes in "mount -o dax=never" mode
>>
>> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
>> index 6fa05fb78189..e238a5b7b722 100644
>> --- a/fs/xfs/xfs_reflink.c
>> +++ b/fs/xfs/xfs_reflink.c
>> @@ -1308,6 +1308,15 @@ xfs_reflink_remap_prep(
>>  	if (IS_DAX(inode_in) || IS_DAX(inode_out))
>>  		goto out_unlock;
>>  
>> +	/*
>> +	 * Until we have dax+reflink, don't allow reflinking dax-flagged
>> +	 * inodes unless we are in dax=never mode.
>> +	 */
>> +	if (!(mp->m_flags & XFS_MOUNT_DAX_NEVER) &&
>> +	     (src->i_d.di_flags2 & XFS_DIFLAG2_DAX ||
>> +	      dest->i_d.di_flags2 & XFS_DIFLAG2_DAX))
>> +		goto out_unlock;
>> +
>>  	ret = generic_remap_file_range_prep(file_in, pos_in, file_out, pos_out,
>>  			len, remap_flags);
>>  	if (ret || *len == 0)
>>
> 

  reply	other threads:[~2021-01-08  2:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07 21:36 [PATCH V2] xfs: do not allow reflinking inodes with the dax flag set Eric Sandeen
2021-01-08  1:29 ` Darrick J. Wong
2021-01-08  2:54   ` Eric Sandeen [this message]
2021-01-20 19:58     ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec51e55e-648e-ad8b-a8dc-76b5c234637e@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).