From: John Garry <john.g.garry@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: axboe@kernel.dk, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me,
martin.petersen@oracle.com, djwong@kernel.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, dchinner@redhat.com,
jejb@linux.ibm.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, paul@paul-moore.com,
jmorris@namei.org, serge@hallyn.com,
Prasad Singamsetty <prasad.singamsetty@oracle.com>
Subject: Re: [PATCH RFC 02/16] fs/bdev: Add atomic write support info to statx
Date: Thu, 4 May 2023 09:45:50 +0100 [thread overview]
Message-ID: <96a2f875-7f99-cd36-e9c3-abbadeb9833b@oracle.com> (raw)
In-Reply-To: <20230503215846.GE3223426@dread.disaster.area>
On 03/05/2023 22:58, Dave Chinner wrote:
Hi Dave,
>> + /* Handle STATX_WRITE_ATOMIC for block devices */
>> + if (request_mask & STATX_WRITE_ATOMIC) {
>> + struct inode *inode = d_backing_inode(path.dentry);
>> +
>> + if (S_ISBLK(inode->i_mode))
>> + bdev_statx_atomic(inode, stat);
>> + }
> This duplicates STATX_DIOALIGN bdev handling.
>
> Really, the bdev attribute handling should be completely factored
> out of vfs_statx() - blockdevs are not the common fastpath for stat
> operations. Somthing like:
>
> /*
> * If this is a block device inode, override the filesystem
> * attributes with the block device specific parameters
> * that need to be obtained from the bdev backing inode.
> */
> if (S_ISBLK(d_backing_inode(path.dentry)->i_mode))
> bdev_statx(path.dentry, stat);
>
> And then all the overrides can go in the one function that doesn't
> need to repeatedly check S_ISBLK()....
ok, that looks like a reasonable idea. We'll look to make that change.
>
>
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index 6b6f2992338c..19d33b2897b2 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -1527,6 +1527,7 @@ int sync_blockdev_range(struct block_device *bdev, loff_t lstart, loff_t lend);
>> int sync_blockdev_nowait(struct block_device *bdev);
>> void sync_bdevs(bool wait);
>> void bdev_statx_dioalign(struct inode *inode, struct kstat *stat);
>> +void bdev_statx_atomic(struct inode *inode, struct kstat *stat);
>> void printk_all_partitions(void);
>> #else
>> static inline void invalidate_bdev(struct block_device *bdev)
>> @@ -1546,6 +1547,9 @@ static inline void sync_bdevs(bool wait)
>> static inline void bdev_statx_dioalign(struct inode *inode, struct kstat *stat)
>> {
>> }
>> +static inline void bdev_statx_atomic(struct inode *inode, struct kstat *stat)
>> +{
>> +}
>> static inline void printk_all_partitions(void)
>> {
>> }
> That also gets rid of the need for all these fine grained exports
> out of the bdev code for statx....
Sure
>
>> diff --git a/include/linux/stat.h b/include/linux/stat.h
>> index 52150570d37a..dfa69ecfaacf 100644
>> --- a/include/linux/stat.h
>> +++ b/include/linux/stat.h
>> @@ -53,6 +53,8 @@ struct kstat {
>> u32 dio_mem_align;
>> u32 dio_offset_align;
>> u64 change_cookie;
>> + u32 atomic_write_unit_max;
>> + u32 atomic_write_unit_min;
>> };
>>
>> /* These definitions are internal to the kernel for now. Mainly used by nfsd. */
>> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
>> index 7cab2c65d3d7..c99d7cac2aa6 100644
>> --- a/include/uapi/linux/stat.h
>> +++ b/include/uapi/linux/stat.h
>> @@ -127,7 +127,10 @@ struct statx {
>> __u32 stx_dio_mem_align; /* Memory buffer alignment for direct I/O */
>> __u32 stx_dio_offset_align; /* File offset alignment for direct I/O */
>> /* 0xa0 */
>> - __u64 __spare3[12]; /* Spare space for future expansion */
>> + __u32 stx_atomic_write_unit_max;
>> + __u32 stx_atomic_write_unit_min;
>> + /* 0xb0 */
>> + __u64 __spare3[11]; /* Spare space for future expansion */
>> /* 0x100 */
>> };
> No documentation on what units these are in.
It's in bytes, we're really just continuing the pattern of what we do
for dio. I think that it would be reasonable to limit to u32.
> Is there a statx() man
> page update for this addition?
No, not yet. Is it normally expected to provide a proposed man page
update in parallel? Or somewhat later, when the kernel API change has
some appreciable level of agreement?
Thanks,
John
next prev parent reply other threads:[~2023-05-04 8:46 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 18:38 [PATCH RFC 00/16] block atomic writes John Garry
2023-05-03 18:38 ` [PATCH RFC 01/16] block: Add atomic write operations to request_queue limits John Garry
2023-05-03 21:39 ` Dave Chinner
2023-05-04 18:14 ` John Garry
2023-05-04 22:26 ` Dave Chinner
2023-05-05 7:54 ` John Garry
2023-05-05 22:00 ` Darrick J. Wong
2023-05-07 1:59 ` Martin K. Petersen
2023-05-05 23:18 ` Dave Chinner
2023-05-06 9:38 ` John Garry
2023-05-07 2:35 ` Martin K. Petersen
2023-05-05 22:47 ` Eric Biggers
2023-05-05 23:31 ` Dave Chinner
2023-05-06 0:08 ` Eric Biggers
2023-05-09 0:19 ` [dm-devel] " Mike Snitzer
2023-05-09 0:19 ` Mike Snitzer
2023-05-17 17:02 ` [dm-devel] " John Garry
2023-05-17 17:02 ` John Garry
2023-05-03 18:38 ` [PATCH RFC 02/16] fs/bdev: Add atomic write support info to statx John Garry
2023-05-03 21:58 ` Dave Chinner
2023-05-04 8:45 ` John Garry [this message]
2023-05-04 22:40 ` Dave Chinner
2023-05-05 8:01 ` John Garry
2023-05-05 22:04 ` Darrick J. Wong
2023-05-03 18:38 ` [PATCH RFC 03/16] xfs: Support atomic write for statx John Garry
2023-05-03 22:17 ` Dave Chinner
2023-05-05 22:10 ` Darrick J. Wong
2023-05-03 18:38 ` [PATCH RFC 04/16] fs: Add RWF_ATOMIC and IOCB_ATOMIC flags for atomic write support John Garry
2023-05-03 18:38 ` [PATCH RFC 05/16] block: Add REQ_ATOMIC flag John Garry
2023-05-03 18:38 ` [PATCH RFC 06/16] block: Limit atomic writes according to bio and queue limits John Garry
2023-05-03 18:53 ` Keith Busch
2023-05-04 8:24 ` John Garry
2023-05-03 18:38 ` [PATCH RFC 07/16] block: Add bdev_find_max_atomic_write_alignment() John Garry
2023-05-04 1:57 ` kernel test robot
2023-05-03 18:38 ` [PATCH RFC 08/16] block: Add support for atomic_write_unit John Garry
2023-05-04 4:00 ` kernel test robot
2023-05-03 18:38 ` [PATCH RFC 09/16] block: Add blk_validate_atomic_write_op() John Garry
2023-05-03 18:38 ` [PATCH RFC 10/16] block: Add fops atomic write support John Garry
2023-05-03 18:38 ` [PATCH RFC 11/16] fs: iomap: Atomic " John Garry
2023-05-04 5:00 ` Dave Chinner
2023-05-05 21:19 ` Darrick J. Wong
2023-05-05 23:56 ` Dave Chinner
2023-05-03 18:38 ` [PATCH RFC 12/16] xfs: Add support for fallocate2 John Garry
2023-05-03 23:21 ` kernel test robot
2023-05-03 23:21 ` kernel test robot
2023-05-03 23:26 ` Dave Chinner
2023-05-05 22:23 ` Darrick J. Wong
2023-05-05 23:42 ` Dave Chinner
2023-05-04 7:28 ` kernel test robot
2023-05-03 18:38 ` [PATCH RFC 13/16] scsi: sd: Support reading atomic properties from block limits VPD John Garry
2023-05-03 18:38 ` [PATCH RFC 14/16] scsi: sd: Add WRITE_ATOMIC_16 support John Garry
2023-05-03 18:48 ` Bart Van Assche
2023-05-04 8:17 ` John Garry
2023-05-03 18:38 ` [PATCH RFC 15/16] scsi: scsi_debug: Atomic write support John Garry
2023-05-04 2:17 ` kernel test robot
2023-05-03 18:38 ` [PATCH RFC 16/16] nvme: Support atomic writes John Garry
2023-05-03 18:49 ` Bart Van Assche
2023-05-04 8:19 ` 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=96a2f875-7f99-cd36-e9c3-abbadeb9833b@oracle.com \
--to=john.g.garry@oracle.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.com \
--cc=jmorris@namei.org \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=paul@paul-moore.com \
--cc=prasad.singamsetty@oracle.com \
--cc=sagi@grimberg.me \
--cc=serge@hallyn.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.