On 3/10/22 4:34 AM, Luca Porzio (lporzio) wrote:

quoted

-----Original Message-----
From: Manjong Lee <redacted>
Sent: Wednesday, March 9, 2022 2:31 PM
To: david@fromorbit.com
Cc: axboe@kernel.dk; hch@lst.de; kbusch@kernel.org; linux-
block@vger.kernel.org; linux-fsdevel@vger.kernel.org; linux-
nvme@lists.infradead.org; linux-raid@vger.kernel.org; sagi@grimberg.me;
song@kernel.org; seunghwan.hyun@samsung.com;
sookwan7.kim@samsung.com; nanich.lee@samsung.com;
woosung2.lee@samsung.com; yt0928.kim@samsung.com;
junho89.kim@samsung.com; jisoo2146.oh@samsung.com
Subject: [EXT] Re: [PATCH 2/2] block: remove the per-bio/request write hint.

CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless
you recognize the sender and were expecting this message.

quoted

On Sun, ddMar 06, 2022 at 11:06:12AM -0700, Jens Axboe wrote:

quoted

On 3/6/22 11:01 AM, Christoph Hellwig wrote:

quoted

On Sun, Mar 06, 2022 at 10:11:46AM -0700, Jens Axboe wrote:

quoted

Yes, I think we should kill it. If we retain the inode hint, the
f2fs doesn't need a any changes. And it should be safe to make the
per-file fcntl hints return EINVAL, which they would on older kernels

anyway.

quoted

quoted

quoted

quoted

Untested, but something like the below.

I've sent this off to the testing farm this morning, but EINVAL
might be even better:

https://urldefense.com/v3/__http://git.infradead.org/users/hch/bloc
k.git/shortlog/refs/heads/more-hint-

removal__;!!KZTdOCjhgt4hgw!qsgy

quoted

quoted

quoted

oejchUYPeorpCL0Ov3jPGvXpXgxa7hpSCViD7XQy7uJDMDLo3U8v_bmoUtg$

quoted

Yup, I like that.

quoted

I do think EINVAL is better, as it just tells the app it's not
available like we would've done before. With just doing zeroes, that
might break applications that set-and-verify. Of course there's also
the risk of that since we retain inode hints (so they work), but fail file

hints.

quoted

quoted

That's a lesser risk though, and we only know of the inode hints
being used.

Agreed, I think EINVAL would be better here - jsut make it behave like
it would on a kernel that never supported this functionality in the
first place. Seems simpler to me for user applications if we do that.

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com

Currently, UFS device also supports hot/cold data separation and uses
existing write_hint code.

In other words, the function is also being used in storage other than NVMe,
and if it is removed, it is thought that there will be an operation problem.

If the code is removed, I am worried about how other devices that use the
function.

Is there a good alternative?

Hi all,

I work for Micron UFS team. I confirm and support Manjong message above.
There are UFS customers using custom write_hint in Android and due to the 
"upstream first" policy from Google, if you remove write_hints in block device,
The Android ecosystem will suffer this lack.

Can we revert back this decision? Or think of an alternative solution which 
may work?

You do both realize that this is just the file specific hint? Inode
based hints will still work fine for UFS.

-- 
Jens Axboe