linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: don't fail dax mount w/ reflink if dax gets disabled
Date: Wed, 5 Sep 2018 16:58:10 -0500	[thread overview]
Message-ID: <f8da45ae-4e07-55a2-f206-7d9280fcf836@redhat.com> (raw)
In-Reply-To: <20180905215414.GY5631@dastard>

On 9/5/18 4:54 PM, Dave Chinner wrote:
> On Wed, Sep 05, 2018 at 11:24:45AM -0500, Eric Sandeen wrote:
>> Today, we can get an interesting result when mounting a reflink filesystem
>> with -o dax on a device that doesn't support it:
>>
>> XFS (sda1): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
>> XFS (sda1): DAX unsupported by block device. Turning off DAX.
>> XFS (sda1): DAX and reflink cannot be used together!
>>
>> <fail mount>
>>
>> If we're willing to silently turn off DAX due to incompatibility with the
>> block device, it makes no sense to then fail the mount due to
>> incompatibility with the filesystem format.  So, skip this check if we
>> already decided to turn off DAX and proceed.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
>> index 207ee30..c85c432 100644
>> --- a/fs/xfs/xfs_super.c
>> +++ b/fs/xfs/xfs_super.c
>> @@ -1677,8 +1677,7 @@ struct proc_xfs_info {
>>  			xfs_alert(mp,
>>  			"DAX unsupported by block device. Turning off DAX.");
>>  			mp->m_flags &= ~XFS_MOUNT_DAX;
>> -		}
>> -		if (xfs_sb_version_hasreflink(&mp->m_sb)) {
>> +		} else if (xfs_sb_version_hasreflink(&mp->m_sb)) {
> 
> Shouldn't this be:
> 
> 		if ((mp->m_flags & XFS_MOUNT_DAX) &&
> 		    xfs_sb_version_hasreflink(&mp->m_sb)) {
> 
>>  			xfs_alert(mp,
>>  		"DAX and reflink cannot be used together!");
>>  			error = -EINVAL;
> 
> I.e. separate the reflink check form the initial mount option check
> which may turn the mount option off?

Yes, I considered doing it that way too.  (either way works, right?)

> I suspect we need to be more harsh are rejecting mounts with -o dax
> on devices DAX isn't supported on. This mount option is going into
> production systems - it's not just for "testing" as the comments all
> claim. i Things will break in production systems if DAX isn't
> enabled and they are expecting it to be enabled.
> 
> Combine that with block devices that can change their DAX support
> without warning (see recent thread about dm dax behaviour), and
> we've got a landmine that looks like "DAX works, I reboot, now DAX
> doesn't work and I got no errors".
> 
> So perhaps this needs more thought w.r.t to rejection when -o dax is
> used on non-dax devices.

Yeah, I agree.  If we want to go the route of hard fail on -o dax on
unsupported devices, then we should make that change, and my patch
shouldn't be applied.

-Eric

      reply	other threads:[~2018-09-06  2:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 16:24 [PATCH] xfs: don't fail dax mount w/ reflink if dax gets disabled Eric Sandeen
2018-09-05 21:54 ` Dave Chinner
2018-09-05 21:58   ` Eric Sandeen [this message]

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=f8da45ae-4e07-55a2-f206-7d9280fcf836@redhat.com \
    --to=sandeen@redhat.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /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).