> -----Original Message----- > From: Manjong Lee <mj0123.lee@xxxxxxxxxxx> > Sent: Wednesday, March 9, 2022 2:31 PM > To: david@xxxxxxxxxxxxx > Cc: axboe@xxxxxxxxx; hch@xxxxxx; kbusch@xxxxxxxxxx; linux- > block@xxxxxxxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx; linux- > nvme@xxxxxxxxxxxxxxxxxxx; linux-raid@xxxxxxxxxxxxxxx; sagi@xxxxxxxxxxx; > song@xxxxxxxxxx; seunghwan.hyun@xxxxxxxxxxx; > sookwan7.kim@xxxxxxxxxxx; nanich.lee@xxxxxxxxxxx; > woosung2.lee@xxxxxxxxxxx; yt0928.kim@xxxxxxxxxxx; > junho89.kim@xxxxxxxxxxx; jisoo2146.oh@xxxxxxxxxxx > 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@xxxxxxxxxxxxx > > > > 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
