All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: axboe@kernel.dk, brauner@kernel.org, viro@zeniv.linux.org.uk,
	jack@suse.cz, chandan.babu@oracle.com, dchinner@redhat.com,
	hch@lst.de, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, hare@suse.de,
	martin.petersen@oracle.com, catherine.hoang@oracle.com,
	kbusch@kernel.org
Subject: Re: [PATCH v5 4/7] xfs: Support FS_XFLAG_ATOMICWRITES for forcealign
Date: Fri, 23 Aug 2024 09:03:37 -0700	[thread overview]
Message-ID: <20240823160337.GA865349@frogsfrogsfrogs> (raw)
In-Reply-To: <d4e9baa3-d7d2-4e89-bc5d-91c85dbd4b8b@oracle.com>

On Fri, Aug 23, 2024 at 09:39:44AM +0100, John Garry wrote:
> On 22/08/2024 21:38, Darrick J. Wong wrote:
> > > > This (atomicwrites && !forcealign) ought to be checked in the superblock
> > > > verifier.
> > > You mean in xfs_fs_validate_params(), right?
> > xfs_validate_sb_common, where we do all the other ondisk superblock
> > validation.
> 
> I don't see any other xfs_has_XXX checks in xfs_validate_sb_common(), but
> this could be the first...

The superblock verifier runs at a lower level in the filesystem -- it
checks that the ondisk superblock doesn't contain any inconsistent
fields or impossible feature combinations, etc.  Once the ondisk
superblock is verified, the information there is used to set XFS_FEAT_*
bits in m_features, which is what the xfs_has_* predicates access.

Therefore, you have to look at the raw superblock fields, not the
xfs_has_ predicates:

	if ((sbp->sb_features_ro_compat & XFS_SB_FEAT_RO_COMPAT_ATOMICWRITES) &&
	    !(sbp->sb_features_ro_compat & XFS_SB_FEAT_RO_COMPAT_FORCEALIGN)) {
		xfs_warn(mp, "atomic writes feature requires force align feature.");
		return -EINVAL;
	}

The reason for checking this state here is that atomicwrites absolutely
requires forcealign and that dependency will always be true.

> The only other place in which I see a pattern of similar SB feature flag
> checks is in xfs_finish_flags() for checking xfs_has_crc() &&
> xfs_has_noattr2().
> 
> So if we go with xfs_validate_sb_common(), then should the check in
> xfs_fs_fill_super() for xfs_has_forcealign() && xfs_has_realtime()/reflink()
> be relocated to xfs_validate_sb_common() also:

No.  Contrast the above with (forcealign && !realtime), which at least
in theory is temporary, so that should live in xfs_fs_fill_super.  Or
put another way, xfs_fs_fill_super is where we screen out the kernel
being too stupid to support something it found on disk.

--D

> 
> https://lore.kernel.org/linux-xfs/20240813163638.3751939-8-john.g.garry@oracle.com/
> 
> Cheers,
> John
> 

  reply	other threads:[~2024-08-23 16:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-17  9:47 [PATCH v5 0/7] block atomic writes for xfs John Garry
2024-08-17  9:47 ` [PATCH v5 1/7] block/fs: Pass an iocb to generic_atomic_write_valid() John Garry
2024-08-20 17:28   ` Darrick J. Wong
2024-08-17  9:47 ` [PATCH v5 2/7] fs: Export generic_atomic_write_valid() John Garry
2024-08-20 17:28   ` Darrick J. Wong
2024-08-17  9:47 ` [PATCH v5 3/7] fs: iomap: Atomic write support John Garry
2024-08-21 16:58   ` Darrick J. Wong
2024-08-22 15:29     ` John Garry
2024-08-22 20:30       ` Darrick J. Wong
2024-08-30 15:48         ` John Garry
2024-08-30 23:56           ` Darrick J. Wong
2024-09-03 12:43             ` John Garry
2024-08-17  9:47 ` [PATCH v5 4/7] xfs: Support FS_XFLAG_ATOMICWRITES for forcealign John Garry
2024-08-21 17:07   ` Darrick J. Wong
2024-08-22 17:45     ` John Garry
2024-08-22 20:38       ` Darrick J. Wong
2024-08-23  8:39         ` John Garry
2024-08-23 16:03           ` Darrick J. Wong [this message]
2024-08-17  9:47 ` [PATCH v5 5/7] xfs: Support atomic write for statx John Garry
2024-08-21 17:09   ` Darrick J. Wong
2024-08-17  9:47 ` [PATCH v5 6/7] xfs: Validate atomic writes John Garry
2024-08-21 17:10   ` Darrick J. Wong
2024-08-17  9:48 ` [PATCH v5 7/7] xfs: Support setting FMODE_CAN_ATOMIC_WRITE John Garry
2024-08-21 17:11   ` Darrick J. Wong
2024-08-22 18:04     ` John Garry
2024-08-22 20:44       ` Darrick J. Wong
2024-08-23 10:41         ` John Garry
2024-08-23 15:52           ` 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=20240823160337.GA865349@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=catherine.hoang@oracle.com \
    --cc=chandan.babu@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.