Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp6477689imm; Mon, 23 Jul 2018 19:42:19 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdbilEOOFgtwbZN868/HnVS4gvRURn3grp5rpgOzuxbqa3w9qyBOdAeQ8EBOZpgpSkVNItm X-Received: by 2002:a65:550d:: with SMTP id f13-v6mr14816369pgr.340.1532400139582; Mon, 23 Jul 2018 19:42:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532400139; cv=none; d=google.com; s=arc-20160816; b=mskD6Yib3DjM1JmTRWYjUnPuN1+jteBJup1M72b3F7WRww0+p73PU/Bb+0akoT4Ovn E6hdXMpQhtAebPgKPThWgcVNzbVzo3OH4Y+eH+cQ0tfRN8dG2+JVZ6fgkrbUBioFY6ai yDOxXp7fjFSpi0ZpibCNQDxEnqvQer38tMDhz48OgLaLbuhI4Fj+m+23uxiprj4YphV2 Jy9G358o67hcYswLcATQUtpkI+C9mNhT5b3ylWxTPH5UO2CMvNj6dxpKtmLYAWwkDtbK hsnicWfplh+u/+G5vdeCEwDLXkhW8r/LVtuTehYsvdqYxnGAdLeKYChwcVG+p1i+/mhN f8dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=pGcu1H4Fh2fjDQHko0MuW7tmcaK8939hD9o4Gb6PVE4=; b=ZcB0j/Z7xuLVByo1GxarNKiMrJEBVvWWmIQ5ffV3mtzx7JmcnjB8C3yJEha5MJhCcO EemkORsQ2fJ52mW1+M5WNw2h7eR7jrvygFslyKAmwYQB0Ef2J/Y2bqT3rjxrADO/rIp8 5LL9/64nQmo/8At2gzF6Vld+C/tLIQy48FNRd+cflEKTZzVCU7vQVvhnEHCjQcZbd45S uNn5xYjmwfI9bcjkaxStlArdySNOt8cKgyZfSA9C8YvNKnB577PCTmqAvVuJ4u1/6M5b BQ25o6jPfl9hTXDCJN2afPSGUA9oTRMHQIRF41cwhycKiV/hWQvXWrm+R1bMGH8/huT5 aZIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 5-v6si9435014plx.517.2018.07.23.19.42.04; Mon, 23 Jul 2018 19:42:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388384AbeGXDpY (ORCPT + 99 others); Mon, 23 Jul 2018 23:45:24 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:56696 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388284AbeGXDpY (ORCPT ); Mon, 23 Jul 2018 23:45:24 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 1BAD84173CB18; Tue, 24 Jul 2018 10:41:11 +0800 (CST) Received: from [127.0.0.1] (10.134.22.195) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.382.0; Tue, 24 Jul 2018 10:40:26 +0800 Subject: Re: [PATCH v3] f2fs: issue discard align to section in LFS mode To: Yunlong Song , , , CC: , , , , , References: <1531836275-94933-1-git-send-email-yunlong.song@huawei.com> <1532005095-111878-1-git-send-email-yunlong.song@huawei.com> From: Chao Yu Message-ID: Date: Tue, 24 Jul 2018 10:40:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1532005095-111878-1-git-send-email-yunlong.song@huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/7/19 20:58, Yunlong Song wrote: > For the case when sbi->segs_per_sec > 1 with lfs mode, take > section:segment = 5 for example, if the section prefree_map is > ...previous section | current section (1 1 0 1 1) | next section..., > then the start = x, end = x + 1, after start = start_segno + > sbi->segs_per_sec, start = x + 5, then it will skip x + 3 and x + 4, but > their bitmap is still set, which will cause duplicated > f2fs_issue_discard of this same section in the next write_checkpoint: > > round 1: section bitmap : 1 1 1 1 1, all valid, prefree_map: 0 0 0 0 0 > then rm data block NO.2, block NO.2 becomes invalid, prefree_map: 0 0 1 0 0 > write_checkpoint: section bitmap: 1 1 0 1 1, prefree_map: 0 0 0 0 0, > prefree of NO.2 is cleared, and no discard issued > > round 2: rm data block NO.0, NO.1, NO.3, NO.4 > all invalid, but prefree bit of NO.2 is set and cleared in round 1, then > prefree_map: 1 1 0 1 1 > write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1, no > valid blocks of this section, so discard issued, but this time prefree > bit of NO.3 and NO.4 is skipped due to start = start_segno + sbi->segs_per_sec; > > round 3: > write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1 -> > 0 0 0 0 0, no valid blocks of this section, so discard issued, > this time prefree bit of NO.3 and NO.4 is cleared, but the discard of > this section is sent again... > > To fix this problem, we can align the start and end value to section > boundary for fstrim and real-time discard operation, and decide to issue > discard only when the whole section is invalid, which can issue discard > aligned to section size as much as possible and avoid redundant discard. > > Signed-off-by: Yunlong Song > Signed-off-by: Chao Yu Reviewed-by: Chao Yu Thanks,