From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: hch@lst.de, viro@zeniv.linux.org.uk, brauner@kernel.org,
dchinner@redhat.com, jack@suse.cz, chandan.babu@oracle.com,
martin.petersen@oracle.com, linux-kernel@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, jbongio@google.com, ojaswin@linux.ibm.com
Subject: Re: [PATCH 4/6] fs: xfs: Support atomic write for statx
Date: Tue, 13 Feb 2024 09:37:04 -0800 [thread overview]
Message-ID: <20240213173704.GB6184@frogsfrogsfrogs> (raw)
In-Reply-To: <9b966c59-3b9f-4093-9913-c9b8a3469a8b@oracle.com>
On Mon, Feb 05, 2024 at 01:10:54PM +0000, John Garry wrote:
> On 02/02/2024 18:05, Darrick J. Wong wrote:
> > On Wed, Jan 24, 2024 at 02:26:43PM +0000, John Garry wrote:
> > > Support providing info on atomic write unit min and max for an inode.
> > >
> > > For simplicity, currently we limit the min at the FS block size, but a
> > > lower limit could be supported in future.
> > >
> > > The atomic write unit min and max is limited by the guaranteed extent
> > > alignment for the inode.
> > >
> > > Signed-off-by: John Garry <john.g.garry@oracle.com>
> > > ---
> > > fs/xfs/xfs_iops.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> > > fs/xfs/xfs_iops.h | 4 ++++
> > > 2 files changed, 49 insertions(+)
> > >
> > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> > > index a0d77f5f512e..0890d2f70f4d 100644
> > > --- a/fs/xfs/xfs_iops.c
> > > +++ b/fs/xfs/xfs_iops.c
> > > @@ -546,6 +546,44 @@ xfs_stat_blksize(
> > > return PAGE_SIZE;
> > > }
> > > +void xfs_get_atomic_write_attr(
> >
> > static void?
>
> We use this in the iomap and statx code
>
> >
> > > + struct xfs_inode *ip,
> > > + unsigned int *unit_min,
> > > + unsigned int *unit_max)
> >
> > Weird indenting here.
>
> hmmm... I thought that this was the XFS style
>
> Can you show how it should look?
The parameter declarations should line up with the local variables:
void
xfs_get_atomic_write_attr(
struct xfs_inode *ip,
unsigned int *unit_min,
unsigned int *unit_max)
{
struct xfs_buftarg *target = xfs_inode_buftarg(ip);
struct block_device *bdev = target->bt_bdev;
struct request_queue *q = bdev->bd_queue;
struct xfs_mount *mp = ip->i_mount;
unsigned int awu_min, awu_max, align;
xfs_extlen_t extsz = xfs_get_extsz(ip);
> >
> > > +{
> > > + xfs_extlen_t extsz = xfs_get_extsz(ip);
> > > + struct xfs_buftarg *target = xfs_inode_buftarg(ip);
> > > + struct block_device *bdev = target->bt_bdev;
> > > + unsigned int awu_min, awu_max, align;
> > > + struct request_queue *q = bdev->bd_queue;
> > > + struct xfs_mount *mp = ip->i_mount;
> > > +
> > > + /*
> > > + * Convert to multiples of the BLOCKSIZE (as we support a minimum
> > > + * atomic write unit of BLOCKSIZE).
> > > + */
> > > + awu_min = queue_atomic_write_unit_min_bytes(q);
> > > + awu_max = queue_atomic_write_unit_max_bytes(q);
> > > +
> > > + awu_min &= ~mp->m_blockmask;
> >
> > Why do you round /down/ the awu_min value here?
>
> This is just to ensure that we returning *unit_min >= BLOCKSIZE
>
> For example, if awu_min, max 1K, 64K from the bdev, we now have 0 and 64K.
> And below this gives us awu_min, max of 4k, 64k.
>
> Maybe there is a more logical way of doing this.
awu_min = roundup(queue_atomic_write_unit_min_bytes(q),
mp->m_sb.sb_blocksize);
?
>
> >
> > > + awu_max &= ~mp->m_blockmask;
> >
> > Actually -- since the atomic write units have to be powers of 2, why is
> > rounding needed here at all?
>
> Sure, but the bdev can report a awu_min < BLOCKSIZE
>
> >
> > > +
> > > + align = XFS_FSB_TO_B(mp, extsz);
> > > +
> > > + if (!awu_max || !xfs_inode_atomicwrites(ip) || !align ||
> > > + !is_power_of_2(align)) {
> >
> > ...and if you take my suggestion to make a common helper to validate the
> > atomic write unit parameters, this can collapse into:
> >
> > alloc_unit_bytes = xfs_inode_alloc_unitsize(ip);
> > if (!xfs_inode_has_atomicwrites(ip) ||
> > !bdev_validate_atomic_write(bdev, alloc_unit_bytes)) > /* not supported, return zeroes */
> > *unit_min = 0;
> > *unit_max = 0;
> > return;
> > }
> >
> > *unit_min = max(alloc_unit_bytes, awu_min);
> > *unit_max = min(alloc_unit_bytes, awu_max);
>
> Again, we need to ensure that *unit_min >= BLOCKSIZE
The file allocation unit and hence the return value of
xfs_inode_alloc_unitsize is always a multiple of sb_blocksize.
--D
> Thanks,
> John
>
>
next prev parent reply other threads:[~2024-02-13 17:37 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 14:26 [PATCH 0/6] block atomic writes for XFS John Garry
2024-01-24 14:26 ` [PATCH 1/6] fs: iomap: Atomic write support John Garry
2024-02-02 17:25 ` Darrick J. Wong
2024-02-05 11:29 ` John Garry
2024-02-13 6:55 ` Christoph Hellwig
2024-02-13 8:20 ` John Garry
2024-02-15 11:08 ` John Garry
2024-02-13 18:08 ` Darrick J. Wong
2024-02-05 15:20 ` Pankaj Raghav (Samsung)
2024-02-05 15:41 ` John Garry
2024-01-24 14:26 ` [PATCH 2/6] fs: Add FS_XFLAG_ATOMICWRITES flag John Garry
2024-02-02 17:57 ` Darrick J. Wong
2024-02-05 12:58 ` John Garry
2024-02-13 6:56 ` Christoph Hellwig
2024-02-13 17:08 ` Darrick J. Wong
2024-01-24 14:26 ` [PATCH 3/6] fs: xfs: Support FS_XFLAG_ATOMICWRITES for rtvol John Garry
2024-02-02 17:52 ` Darrick J. Wong
2024-02-03 7:40 ` Ojaswin Mujoo
2024-02-05 12:51 ` John Garry
2024-02-13 17:22 ` Darrick J. Wong
2024-02-14 12:19 ` John Garry
2024-01-24 14:26 ` [PATCH 4/6] fs: xfs: Support atomic write for statx John Garry
2024-02-02 18:05 ` Darrick J. Wong
2024-02-05 13:10 ` John Garry
2024-02-13 17:37 ` Darrick J. Wong [this message]
2024-02-14 12:26 ` John Garry
2024-02-09 7:00 ` Ojaswin Mujoo
2024-02-09 17:30 ` John Garry
2024-02-12 11:48 ` Ojaswin Mujoo
2024-02-12 12:05 ` Ojaswin Mujoo
2024-01-24 14:26 ` [PATCH RFC 5/6] fs: xfs: iomap atomic write support John Garry
2024-02-02 18:47 ` Darrick J. Wong
2024-02-05 13:36 ` John Garry
2024-02-06 1:15 ` Dave Chinner
2024-02-06 9:53 ` John Garry
2024-02-07 0:06 ` Dave Chinner
2024-02-07 14:13 ` John Garry
2024-02-09 1:40 ` Dave Chinner
2024-02-09 12:47 ` John Garry
2024-02-13 23:41 ` Dave Chinner
2024-02-14 11:06 ` John Garry
2024-02-14 23:03 ` Dave Chinner
2024-02-15 9:53 ` John Garry
2024-02-13 17:50 ` Darrick J. Wong
2024-02-14 12:13 ` John Garry
2024-01-24 14:26 ` [PATCH 6/6] fs: xfs: Set FMODE_CAN_ATOMIC_WRITE for FS_XFLAG_ATOMICWRITES set John Garry
2024-02-02 18:06 ` Darrick J. Wong
2024-02-05 10:26 ` John Garry
2024-02-13 17:59 ` Darrick J. Wong
2024-02-14 12:36 ` John Garry
2024-02-21 17:00 ` Darrick J. Wong
2024-02-21 17:38 ` John Garry
2024-02-24 4:18 ` Darrick J. Wong
2024-02-09 7:14 ` [PATCH 0/6] block atomic writes for XFS Ojaswin Mujoo
2024-02-09 9:22 ` John Garry
2024-02-12 12:06 ` Ojaswin Mujoo
2024-02-13 7:22 ` Christoph Hellwig
2024-02-13 17:55 ` Darrick J. Wong
2024-02-14 7:45 ` Christoph Hellwig
2024-02-21 16:56 ` Darrick J. Wong
2024-02-23 6:57 ` Christoph Hellwig
2024-02-13 23:50 ` Dave Chinner
2024-02-14 7:38 ` Christoph Hellwig
2024-02-13 7:45 ` Ritesh Harjani
2024-02-13 8:41 ` John Garry
2024-02-13 9:10 ` Ritesh Harjani
2024-02-13 22:49 ` Dave Chinner
2024-02-14 10:10 ` John Garry
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=20240213173704.GB6184@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jbongio@google.com \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ojaswin@linux.ibm.com \
--cc=tytso@mit.edu \
--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.