[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqrIlVtI85zF9qyO@infradead.org>
Date: Wed, 15 Jun 2022 23:07:17 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Dave Chinner <david@...morbit.com>,
"Darrick J. Wong" <djwong@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, linux-xfs@...r.kernel.org,
linux-api@...r.kernel.org, linux-fscrypt@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
Keith Busch <kbusch@...nel.org>
Subject: Re: [RFC PATCH v2 1/7] statx: add I/O alignment information
On Wed, Jun 15, 2022 at 05:04:57PM -0700, Eric Biggers wrote:
> One more thing. I'm trying to add support for STATX_DIOALIGN on block devices.
> Unfortunately I don't think it is going to work, at all, since the inode is for
> the device node and not the block device itself. This is true even after the
> file is opened (I previously thought that at least that case would work).
For an open file the block device inode is pointed to by
file->f_mapping->host.
> Were you expecting that this would work on block devices? It seems they will
> need a different API -- a new BLK* ioctl, or files in /sys/block/$dev/queue.
blkdev_get_no_open on inode->i_rdev gets you the block device, which
then has bdev->bd_inode point to the underlying block device, although
for a block device those limit probably would be retrieved not from
the inode but the gendisk / request_queue anyway.
Powered by blists - more mailing lists