From: Kanchan Joshi <joshi.k@samsung.com>
To: Bart Van Assche <bvanassche@acm.org>, Christoph Hellwig <hch@lst.de>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Daejun Park <daejun7.park@samsung.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v8 06/19] block, fs: Propagate write hints to the block device inode
Date: Mon, 22 Jan 2024 15:01:48 +0530 [thread overview]
Message-ID: <85be3166-1886-b56a-4910-7aff8a13ea3b@samsung.com> (raw)
In-Reply-To: <9fa04d79-0ba6-a2e0-6af7-d1c85f08923b@samsung.com>
On 1/19/2024 7:26 PM, Kanchan Joshi wrote:
> On 1/19/2024 12:24 AM, Bart Van Assche wrote:
>> On 1/18/24 10:51, Kanchan Joshi wrote:
>>> Are you considering to change this so that hint is set only on one inode
>>> (and not on two)?
>>> IOW, should not this fragment be like below:
>>>
>>> --- a/fs/fcntl.c
>>> +++ b/fs/fcntl.c
>>> @@ -306,7 +306,6 @@ static long fcntl_get_rw_hint(struct file *file,
>>> unsigned int cmd,
>>> static long fcntl_set_rw_hint(struct file *file, unsigned int cmd,
>>> unsigned long arg)
>>> {
>>> - void (*apply_whint)(struct file *, enum rw_hint);
>>> struct inode *inode = file_inode(file);
>>> u64 __user *argp = (u64 __user *)arg;
>>> u64 hint;
>>> @@ -316,11 +315,15 @@ static long fcntl_set_rw_hint(struct file *file,
>>> unsigned int cmd,
>>> if (!rw_hint_valid(hint))
>>> return -EINVAL;
>>>
>>> + /*
>>> + * file->f_mapping->host may differ from inode. As an example
>>> + * blkdev_open() modifies file->f_mapping
>>> + */
>>> + if (file->f_mapping->host != inode)
>>> + inode = file->f_mapping->host;
>>> +
>>> inode_lock(inode);
>>> inode->i_write_hint = hint;
>>> - apply_whint = inode->i_fop->apply_whint;
>>> - if (apply_whint)
>>> - apply_whint(file, hint);
>>> inode_unlock(inode);
>>
>> I think the above proposal would introduce a bug: it would break the
>> F_GET_RW_HINT implementation.
>
> Right. I expected to keep the exact change in GET, too, but that will
> not be free from the side-effect.
> The buffered-write path (block_write_full_page) picks the hint from one
> inode, and the direct-write path (__blkdev_direct_IO_simple) picks the
> hint from a different inode.
> So, updating both seems needed here.
I stand corrected. It's possible to do away with two updates.
The direct-io code (patch 8) should rather be changed to pick the hint
from bdev inode (and not from file inode).
With that change, this patch only need to set the hint into only one
inode (bdev one). What do you think?
next prev parent reply other threads:[~2024-01-22 9:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 0:07 [PATCH v8 00/19] Pass data lifetime information to SCSI disk devices Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 01/19] fs: Fix rw_hint validation Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 02/19] fs: Verify write lifetime constants at compile time Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 03/19] fs: Split fcntl_rw_hint() Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 04/19] fs: Move enum rw_hint into a new header file Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 05/19] block, fs: Restore the per-bio/request data lifetime fields Bart Van Assche
2024-01-22 9:23 ` Kanchan Joshi
2024-01-22 20:05 ` Bart Van Assche
2024-01-23 12:35 ` Kanchan Joshi
2024-01-23 15:59 ` Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 06/19] block, fs: Propagate write hints to the block device inode Bart Van Assche
2023-12-28 7:12 ` Christoph Hellwig
2023-12-28 22:41 ` Bart Van Assche
2024-01-03 9:02 ` Christoph Hellwig
2024-01-03 23:09 ` Bart Van Assche
2024-01-04 6:08 ` Christoph Hellwig
2024-01-18 18:51 ` Kanchan Joshi
2024-01-18 18:54 ` Bart Van Assche
2024-01-19 13:56 ` Kanchan Joshi
2024-01-22 9:31 ` Kanchan Joshi [this message]
2024-01-22 20:09 ` Bart Van Assche
2024-01-23 12:16 ` Kanchan Joshi
2024-01-23 15:29 ` Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 07/19] fs/f2fs: Restore the whint_mode mount option Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 08/19] fs/f2fs: Restore support for tracing data lifetimes Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 09/19] scsi: core: Query the Block Limits Extension VPD page Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 10/19] scsi: scsi_proto: Add structures and constants related to I/O groups and streams Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 11/19] scsi: sd: Translate data lifetime information Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 12/19] scsi: scsi_debug: Reduce code duplication Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 13/19] scsi: scsi_debug: Support the block limits extension VPD page Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 14/19] scsi: scsi_debug: Rework page code error handling Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 15/19] scsi: scsi_debug: Rework subpage " Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 16/19] scsi: scsi_debug: Allocate the MODE SENSE response from the heap Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 17/19] scsi: scsi_debug: Implement the IO Advice Hints Grouping mode page Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 18/19] scsi: scsi_debug: Implement GET STREAM STATUS Bart Van Assche
2023-12-19 0:07 ` [PATCH v8 19/19] scsi: scsi_debug: Maintain write statistics per group number Bart Van Assche
2023-12-19 1:12 ` [PATCH v8 00/19] Pass data lifetime information to SCSI disk devices Jens Axboe
2023-12-27 16:25 ` Bart Van Assche
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=85be3166-1886-b56a-4910-7aff8a13ea3b@samsung.com \
--to=joshi.k@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=bvanassche@acm.org \
--cc=chuck.lever@oracle.com \
--cc=daejun7.park@samsung.com \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox