On 3/10/22 4:34 AM, Luca Porzio (lporzio) wrote: >> -----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? You do both realize that this is just the file specific hint? Inode based hints will still work fine for UFS. -- Jens Axboe
