[EXT] Re: [PATCH 2/2] block: remove the per-bio/request write hint.

[Luca Porzio (lporzio)]

> -----Original Message-----
> From: Manjong Lee <mj0123.lee at samsung.com>
> Sent: Wednesday, March 9, 2022 2:31 PM
> To: david at fromorbit.com
> Cc: axboe at kernel.dk; hch at lst.de; kbusch at kernel.org; linux-
> block at vger.kernel.org; linux-fsdevel at vger.kernel.org; linux-
> nvme at lists.infradead.org; linux-raid at vger.kernel.org; sagi at grimberg.me;
> song at kernel.org; seunghwan.hyun at samsung.com;
> sookwan7.kim at samsung.com; nanich.lee at samsung.com;
> woosung2.lee at samsung.com; yt0928.kim at samsung.com;
> junho89.kim at samsung.com; jisoo2146.oh at 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.
> 
> 
> >On Sun, ddMar 06, 2022 at 11:06:12AM -0700, Jens Axboe wrote:
> >> On 3/6/22 11:01 AM, Christoph Hellwig wrote:
> >> > On Sun, Mar 06, 2022 at 10:11:46AM -0700, Jens Axboe wrote:
> >> >> 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.
> >> >> 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
> >> >
> oejchUYPeorpCL0Ov3jPGvXpXgxa7hpSCViD7XQy7uJDMDLo3U8v_bmoUtg$
> >
> >Yup, I like that.
> >
> >> 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.
> >> 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 at 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?

Cheers,
   Luca