From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD99DC433F5 for ; Thu, 10 Mar 2022 12:15:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241926AbiCJMQQ (ORCPT ); Thu, 10 Mar 2022 07:16:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241920AbiCJMQP (ORCPT ); Thu, 10 Mar 2022 07:16:15 -0500 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB2121480E4 for ; Thu, 10 Mar 2022 04:15:13 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id q13so4673977plk.12 for ; Thu, 10 Mar 2022 04:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=hoPWBro4VveouJ4vx2nAAxYFxr+KDw+cTxYyidREMFo=; b=3lHvgXyOZWgBu7xmQFS37eeUDuf1cB/DlgDJKt7JktscFsHvnp2Z8HCO7AOl2uhI4v IfKhXbGVbCyxw6KBqmCJJj9pXcgNwwx8ywoRtiOyPNStQnrxq6KFtxGsd3biz/AqcHWW j/w7UdCS6+jAfG4hgQcTgSKFx6XIqC3Hw8YADTHIrxFAt+0Rmac4VbfJyn/Y1VvMEj6d VMO8rDYU5jzoD8Ukc1lKq/tWuwpvqQxOdscRi7bEgiCGO5gHq1sZuu1Qy9OGPoqkq6Bb HqFsp7iKPtFoQ8ApxZav7UKCYUNl9udtO7+ktT1RlPCAqGWAg58SD0xHYkrZOrmdn/8K 1cUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=hoPWBro4VveouJ4vx2nAAxYFxr+KDw+cTxYyidREMFo=; b=z0C/tCQRUXAj0C9uUE7UO+mdj44G2etjAlLggQA1E6xMeQWHrHKoZyOYVi7D+kv1IA nAv0r0evarFPnvbBgRVkbAruIkYRVPtjusnIb8CFlMnyNrFHMC+K882RYUk1Tmby5wqb MorUGJJailUPN+dYII8XW8Oi8EnfUHaQZ39AQVwg8D4QW6ZqpYE+B49qldpdOdgjH238 46utMFkIlNfqzQcZvQmPI2mJoW2oqIH+5w+SgwkePYDGI91NwONFVho3yootUlc/qUbT SHsrMuiEVA/Dymb2926SA0H1L24tWctzx8FFRHwwzxnABQLszlJYUOzQ2CQ3OCYCV4/M WNwA== X-Gm-Message-State: AOAM533pWZTuAtTbBqZFx5YcpCTBlC8OWo3Z96DBi3YN+bx799ukmcHr zgg93jWBc/7zAgYHqgQ1C+3vxQ== X-Google-Smtp-Source: ABdhPJzSQmxtoIBTxfTuTtDJblYzgJmRRteHsYoyEbd/AE8Ym0coXr6/kU1kFb735T1a56f84F6JHQ== X-Received: by 2002:a17:90b:3a8f:b0:1bf:ccc:59bc with SMTP id om15-20020a17090b3a8f00b001bf0ccc59bcmr4730847pjb.234.1646914513229; Thu, 10 Mar 2022 04:15:13 -0800 (PST) Received: from [192.168.1.100] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id o66-20020a17090a0a4800b001bf388fc96esm5918336pjo.21.2022.03.10.04.15.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Mar 2022 04:15:12 -0800 (PST) Message-ID: Date: Thu, 10 Mar 2022 05:15:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [EXT] Re: [PATCH 2/2] block: remove the per-bio/request write hint. Content-Language: en-US To: "Luca Porzio (lporzio)" , Manjong Lee , "david@fromorbit.com" Cc: "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" References: <20220306231727.GP3927073@dread.disaster.area> <20220309133119.6915-1-mj0123.lee@samsung.com> From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-raid@vger.kernel.org On 3/10/22 4:34 AM, Luca Porzio (lporzio) wrote: >> -----Original Message----- >> From: Manjong Lee >> 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. >> >> >>> 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@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