From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from TYPPR03CU001.outbound.protection.outlook.com (mail-japaneastazon11012005.outbound.protection.outlook.com [52.101.126.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5AB833E7 for ; Mon, 28 Jul 2025 12:22:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.126.5 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753705326; cv=fail; b=Pw9OPA8cx23hz4s3qA3Tn6IizPeE4EIKlSrScG4rDYsp73cdeUiDirrqUT2RnFZDGGWBj/UnOIRDEV/sVI+QSJMlltbqCDgV3SYhdN8O1X7jR72NLNlgiM0kFn3HkPc3uU/xp4UxvxWGqGsBHinTHEbF94uzYqA1qjNt9ZgxPS0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753705326; c=relaxed/simple; bh=AMxj2kG8ElTsdcrOS4B1ops4eh44D2JG/QlNApo6jq0=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=sCHyzRdBbw90GBYw5o4mmVVhQj+024iLEKw/AgO5nZafFYiJWVEiaa1Sto7KkjbAk89V3EgVDoi/JE70BR4P51VkuPLagAdWQBkC8sP6EdtO+qHjnyxHhhDsG/Qwjb3iiUCz/cVtWlmrSJmHCyLznpFloQ6FoCNmeeNeCuWntOc= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com; spf=pass smtp.mailfrom=vivo.com; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b=a/dyJ7jJ; arc=fail smtp.client-ip=52.101.126.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=vivo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b="a/dyJ7jJ" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b8rYUg6C4yK+MM8hMp1Hk/QZ/zaZUFZOQPwWerDMafj+ymlfCypTCMxFxqlHyphzBZO/mau5C6KMTRsGbHNiGFvpozGM3+LgBNY/WuHXG4DZw5dR5yrRm/kS7Ncqmj4dTA54/OUa0CdyavRNekM2D+PFZA1Ip5KAwdroTCYu3p/VtOmVIWFcG7dZm/G85xmznnrQPoy8taZX99GKpO0QnWeXbX/B87AEXRmM5U6YoIzcP37OJMJrOfQHpiO5wlGZfJnaQDYCDCLxmBv+nLjXmznM8IdgS9W3+agl/uRuaRhoFonpgh+w/FyZzb8HG5V9aEAeexhuEuhP+3Rg7Mvktw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iH1K4FqgcWIjRa+0pPWKISePu6hN9/13u2bldjPV/Pw=; b=VWFSIZHBHgkMX1pm9eUHtHkvKFh0vYSwQx1w0r8Cx87EPstShdBH0luTpo+yxlZcoRnQGIukXSFZkKmWzS/XgoyNfqx5K+Vd96GiWtFB430OslZ+U7NnYmLtGciyxpaABAY4b8y77pfAi0FOaw3xF0GPjENbQV2WRe8hrTnZAm3wzubOtbtn/gWd8RfgDQuMouatnKd6F1BKUMPE2Az6wL2MUxuIxNFSA5ZyTKyfVcI39NvyS11DKC0YqO7WB4l9Eb7rUV/iOQpO7DswPopijrut9Q5iSTSg2ATv7ShYXyzC/Nij5IKUG5odumSxVL99KfuMqohaZRYypaguPkcQsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com; dkim=pass header.d=vivo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iH1K4FqgcWIjRa+0pPWKISePu6hN9/13u2bldjPV/Pw=; b=a/dyJ7jJFIA/bzWO9fRpsw/G+Fe0EL40QZb6pbWoWqVbuSMCf4N1cgtAbYNO/WBM/61W9eU8rz6Lli3SOxpyP7Q2UQEDJdIX4Xdg5qPxKJC7kNwWnbwcSW+6cBHeM8LsmW1SKCefa5nyqXYxJw9MMxwRSwwumb29FtXz83Lzin1PyywXPUvBr/Htc/9xpUqF3chYN85xy8fk++9reCx9TBqLLhTQPlAOxGaMtKtrM39Xhl4Es6ZLq0GGcW85qcl7GIhxva0yuNim9kwBN1jgLRD2PJOBC2m345Hn8Eh9+Lm1VOzJvmmYXvmOoRWVpelIBg/Wg78tG8Hee7UtlSe+Nw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=vivo.com; Received: from SEZPR06MB5576.apcprd06.prod.outlook.com (2603:1096:101:c9::14) by TYUPR06MB5874.apcprd06.prod.outlook.com (2603:1096:400:35b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8964.26; Mon, 28 Jul 2025 12:22:01 +0000 Received: from SEZPR06MB5576.apcprd06.prod.outlook.com ([fe80::5c0a:2748:6a72:99b6]) by SEZPR06MB5576.apcprd06.prod.outlook.com ([fe80::5c0a:2748:6a72:99b6%5]) with mapi id 15.20.8964.025; Mon, 28 Jul 2025 12:22:01 +0000 Message-ID: <3fdc4eb9-a3eb-48c7-be90-6ee305ef4442@vivo.com> Date: Mon, 28 Jul 2025 20:21:58 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] f2fs:Add adjustable write endpoints for multiple devices To: Chao Yu Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Jaegeuk Kim References: <20250723084955.547901-1-liaoyuanhong@vivo.com> Content-Language: en-US From: Liao Yuanhong In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TY2PR06CA0022.apcprd06.prod.outlook.com (2603:1096:404:42::34) To SEZPR06MB5576.apcprd06.prod.outlook.com (2603:1096:101:c9::14) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SEZPR06MB5576:EE_|TYUPR06MB5874:EE_ X-MS-Office365-Filtering-Correlation-Id: 6ce84e0d-72d1-498f-aa78-08ddcdd15aa0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|52116014|376014|366016|38350700014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?QU42TWwrN0JxZTBqamJXRloxMHVKL2lTQkRrWllPaFhvelc1STVpRlRzQjVC?= =?utf-8?B?V0pkWkN0S05IS1pvaTlBVE9wMWVpaFVmVnVMcG8rMXdTTUIvYXhtalZJREli?= =?utf-8?B?N1NadVRWeThCbUFQS1RRQSttaEQ1cmhYRFcwdmtsSEcrSllYVjljLy9HaUxC?= =?utf-8?B?VEhMaXg0V3hlRzVhRHRIUHYvWXZlZklSdTJzTUQ3SmZNV2pMQU43TTA5ajAz?= =?utf-8?B?SWRid2lmMCtNYjFIQXlGWk5BNzlRcmZTTUFac2ZBc2Q0NnkxL3ZGdHJpNCtN?= =?utf-8?B?K3FadlBBWTlBcCsySG9XZEdHcFRYanNVR3hmU2hjRU05MXA3Y3pWYmM2RitW?= =?utf-8?B?UkhQVjdJL09vMTJjLzhVblpmWWNpcW1vR2ptNnVmTVB5Rk1GOGxOSU14MXlp?= =?utf-8?B?azhzUHlJUnFCWG1ROUN4VTM1K3lDaktXcWN3MkROK1ZLMXhjNGFwSk51MXJX?= =?utf-8?B?NVRzK0JYQUwwakk5bEZtQXNDMUh1OTVId0x6OGJZL2xaOUhDVXliTTVFU3h6?= =?utf-8?B?QmV5elQ2ZFJ5NU1sbkJXZ0x4SE5iMkY0YWFzeVVjNmF6cnRvaHJSU3JZMHc4?= =?utf-8?B?bVYwSlBZUXB4bkwyMXNUK0dpSU9CRVV1NEEwbk01RXh6bi96UnpXRk9MTllG?= =?utf-8?B?Nm5kTWE0N01nWXdqRmkzK1pVV3NPcmZiSkp4bkpCQWFLb1NPQ2NCekJ3VWs2?= =?utf-8?B?bVJNS3FBdnlQVDc4L3gvYTdLNUphWEZwTHRNekRkR2ZIT0V4SUhWT09YUkpI?= =?utf-8?B?T0craDREZEorZ3hXYmNmWE91bEV5RU5pbFdKU1grWUdMMWE4MEQ5SkgybUVx?= =?utf-8?B?emE1NFFObG9rRXBVWUplbXBucWtaeVE2dWVidTYwQ3l1NC80bzN5TngwcVJJ?= =?utf-8?B?bXNMaEMwVlRXSmxpR2NsLzZqSldzZStLQ0JoSHdlVnYyVWdocWpidldkN0Nk?= =?utf-8?B?STlQcnRsdm5LUi9qV1R0dlhVYU1QZ3dJVGwxUGI0S2J0Vk5JV2dIa0FBNDlL?= =?utf-8?B?cmFTQ2tZQ3NtUlNrZTZsVmtpU3FvNDRyY0ZhR0tHc3pTV0NqRXk4VDlneVBo?= =?utf-8?B?QVBwVGVNOVZxZ1NRd0xhUGxldkYyNDBQOVE3QS96Qkd6UFRtU3IyaXJ3RnlT?= =?utf-8?B?SFovRDdJK3I1VTBmdWFXWHhGQTBJVXREbUhNWk1GZWMvRTZsK2tsWmNyM0Fp?= =?utf-8?B?VDd2YXJGUVVkVG5JWUcyanl5MjFsSGZhM1hGaWdoRVBaNmNTU1JwRTdDditK?= =?utf-8?B?TXJFNGtWdndSaHcwc3h6L2JERVZlaVR1aEx2Y3FteGVYV25zcDVxVDJCTnFE?= =?utf-8?B?MmZGYnNuSDVoU2N4RW1STTdHVW04NC9JTlhPdDNJU25rTnV3Z1NaWXhPSFpu?= =?utf-8?B?eGt5N1ZVS3pnVkgxSzVNWHlLejdkODJYN2Y0cXdhMjRBVks1SkVzczJydXEx?= =?utf-8?B?UEdnWHB0bjBDazdORThZcFZOK1Rxd01ZcHBSZmJIZXRHNW1rWk5PZHlydWRF?= =?utf-8?B?cXpXZjZsa0Uyd1JZK29RaW5jUU90dkVtMnk2Y1hJR0w0ZS9ldm5DNTdLaFhZ?= =?utf-8?B?TWU0WS9PUVdCNnVuL0lGc3BtVUtrSzdoVG5SRWNCbnoybVc0RUswK2orOGxs?= =?utf-8?B?VDRYRFpFWEZReUR4dEhmYVJMd09Qa09IVHh4MUxpVjJuOEh5Wi9LSWc2N0Nt?= =?utf-8?B?Nk55aytVcmY2UklKVU1iRUR4T0RRVVBLbG9OR0pPdElkVWRmRVhhaVlUWWhS?= =?utf-8?B?ZFBHTm1xU3AxU204anRZMitRY1dWcytuYW10Q09UWkkrQUd0Ynd2bG5EZ25a?= =?utf-8?B?NWJoSk5kYmNRZGs0YWRYZlJnNVR4VDBndmMxQmE4eWE1MXY3WVpPQVdkbHRP?= =?utf-8?B?TWsxS3NiTUtsZnhsS25Sdm5VU2RLVkZydUNQMFZmWFREWDZkUlpwTWxqeEVG?= =?utf-8?B?dW1icmhvb0t3QytRRGhkYzgvUitaWlVFY3RNWFJUS1RpWjgzL2Y2NGo5WTl5?= =?utf-8?B?LzF6eUg1Vlp3PT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SEZPR06MB5576.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(52116014)(376014)(366016)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N0J5T0FubUgxY0hYcms0eUdTRUo0Z204RXlIbDJZQ2RaZ2FNTW55NXdxbkVY?= =?utf-8?B?K09jcFhGQitXNnF0NFg4eEVuYWZ6RGNGdWcyUUR3SFZkZzBSTkw0UTg4WXdk?= =?utf-8?B?NjdpWk9BZHc3NHNQUm4rVzNhcnRiamFKNGhvMEcxWS9wUUd1Uk8wbFhTc0Q4?= =?utf-8?B?dFRaSjBvSGtUYWxvbkZ3S2g2NE5RNUNEdXV3bE9BQlZSOTFLQnY0MHM5QWlB?= =?utf-8?B?WWpHa3RNS2x1SnpFUUI5MDF1LzQ3OWlIck53ZksxeE4zK3hqNkhLQWhrclNr?= =?utf-8?B?dDRSeVBXdUc3RGNSWHg1c1l2QmZyazlXRjZ6dXdsN0lqbXVVa0JDbVFzd0t3?= =?utf-8?B?S2Q1bDNKMmZ5REE1eXJrUGVhcFJXMnlYbU01eFpwdUJQU1ZSS1d2ejdWeWhw?= =?utf-8?B?a200a0YyTmhVNXBwd3Q4UlNlMGUySHdrdExMYWFwUTZaVkpqWVlEWkdKL2V3?= =?utf-8?B?ZWR1UzRzWTJLNWV3Mm5MbzdWNDZ6WGErTGdmVUUrSEdQeEpEWnNxY2JXNnRq?= =?utf-8?B?bVNabDY1czQ1N1QwNnRGNWxXbG9NUDR2YkZjbE94Nml6MmtObDJpZjBURzBT?= =?utf-8?B?T0p4elpuWkQ5ZzJLRWlTU1pWdUNiRXJHNHE4V2M2T0F6VnljN3hWdlpaTnFU?= =?utf-8?B?eFBLNC8yTFBSYjFDbys4T0NCc3lYTjhTM1hrQXAwdGJBNGFLMk1LYXNXMExO?= =?utf-8?B?KzhSVjltZzRUYnZwRWtaL0FHenpIRldpcm0xSWNmTEFycTFIOGgvT2pTemFQ?= =?utf-8?B?TlJSR0V1UERrWStLUCsxbDdraVNDZUtCb01XYWNlVzNYelRXbGRXU3BsR0di?= =?utf-8?B?aktPRitWaUd1TE9CNXdFSnR5YWw1VGREc3BvbldPbW5HYjRKeC9sV1N2SHVC?= =?utf-8?B?Q1R6OEpCYnRFREtWZkt6K0dGNmtUWjBJYUlrT1IzWWs2cnNLbnloY3cwWWU5?= =?utf-8?B?bnhIamN4RmxpZE9vd3c4L1J3S0VlQ2JrZkx3b0QyZ0xQeDgvRVZBbVNMd2Vy?= =?utf-8?B?VStOS2ZaUzdudXpSVk11N0VWa3hRUDZYNUQ5TklSR0VTbGMvVERCOGdEYXJj?= =?utf-8?B?b1F6WUc2b3NsckZjV1lXRE9Kb1RCTmpkeXF3YUs5Skw3MnJWTFNOU2R6SC82?= =?utf-8?B?QWl2SWo0aHZiL3FJRm16RkcvWElacGtpc2N2RzBvRnNVY2pxb09Cb2U5Ylli?= =?utf-8?B?QzBjUUdmMmN2aW01QUozalhMTUhneWcxU1FzOEVMZEFwZ1dRdU1jTzdsRVND?= =?utf-8?B?RmkrMlhRc3hRTENndkNVZXlwdjkwSUNsQXBFSy9XWGhwTnEydFpGZGR4RC9M?= =?utf-8?B?M2I3b1BiYjZ5WTVGVkE5TW1zamtlcTNvMkZMTVlhcEFMM0NXbEQwSnRrNmJi?= =?utf-8?B?dHJ0QVQyaDRLZkIvYTNUQU5VNDBobHlGNVUycWx4T0p6SWlGV21TZG9zOEhH?= =?utf-8?B?bjRYdzdCMTJFdm5VbUNRdktQUmdUZm8xRjk5SjRpUmNrdGVWbkZ4MFByY0xz?= =?utf-8?B?YUpJb1VqVmRUOU01YTZWL29TeFZPcnZ4cWVWRnFuaDhTOUJYd29TNGhnbS9n?= =?utf-8?B?WTJKTFJrVGFzNnkxTmRQZzN0SEkrb2hKakFiRmxoWk9uNHB2aGlXN25xbWMv?= =?utf-8?B?ejFDeVBuM2ZFSmllUHNTODZ6Y2VZb0IzMDhyMVF5QUpzWVFDaEo5bHlKazNk?= =?utf-8?B?OW53VUE5RDNXcE45MERhVWt3YXNkY3dmOHJwZWVzRGZXUCs3VzVlSy9SQmRl?= =?utf-8?B?dlZ5T3Y5LzFLUEF1czJVZkI3enRrR1E1UzdzSVE5Tk1BanpmMk8zTFNXTU5v?= =?utf-8?B?RWlUZFZicGNPMkpZNW85Tk1KNGZtVzN1eFpOTXAzcUhUK285NElPeVljcWdm?= =?utf-8?B?ZktibGlhbXF4T0lrUElzcFZDcDJuRHlKMjVPQklBRC9RWGNqRTk2TldhWERp?= =?utf-8?B?c3ZCMDN0clFkM2V4cEw1cnVDK2VzVU1qWHNzYWFCQjhZRUtvaWxxNVFUZW1P?= =?utf-8?B?YnpvRnNrOFlBeTNNR2VwT0s4MnoxMlNuVHpSTXdOQk1MbVV6YWdBdkNVSUh0?= =?utf-8?B?cDI5S1pXY1M3RFhLOEdkRHJWdmR0NllqakEvN1RZNFFNa1FlYkVYSStOSEkw?= =?utf-8?Q?iBe5gBq+CgSGLN1+VEBpUYmUt?= X-OriginatorOrg: vivo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ce84e0d-72d1-498f-aa78-08ddcdd15aa0 X-MS-Exchange-CrossTenant-AuthSource: SEZPR06MB5576.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2025 12:22:01.0080 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: LJdz04o5lkveOivGg0GnWryBnpMgnpxHRVXBWHC/5QhF8Gwk9NOGny+5PJjTYLbQURO/kWWGckWJwxigwGh54A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYUPR06MB5874 On 7/28/2025 3:56 PM, Chao Yu wrote: > On 7/23/25 16:49, Liao Yuanhong wrote: >> During the development process, we encounter the following two issues: >> >> 1.In a multi-device scenario, it's likely that two devices exhibit >> inconsistent performance, causing fluctuations in performance and making >> usage and testing inconvenient. Under normal circumstances, we hope to >> prioritize the use of the device with better performance and consider the >> device with poorer performance when space is insufficient. Using reuse >> mode can solve some of the issues, but tests reveal that the fragmentation >> degree in reuse mode is significantly higher than in default mode, which >> poses performance risks. >> >> 2.We need to examine the differences in data placement for different sizes >> of storage devices under specific write patterns. Currently, this >> comparison can only be made by switching storage devices. >> >> To address the above issues, I am considering adding a last_secno node. By >> adjusting this node, we can change the end of the addressing in >> get_new_segment so that it readdresses from 0 once the set value is >> reached. The default value of the node is the maximum number of sections >> for the current storage device, so making no modifications will not affect >> the current logic. If the space before the set value is already filled with >> valid data, it will normally write into the free area after the set value. >> >> Signed-off-by: Liao Yuanhong >> --- >> Documentation/ABI/testing/sysfs-fs-f2fs | 8 ++++++++ >> fs/f2fs/f2fs.h | 1 + >> fs/f2fs/segment.c | 4 ++-- >> fs/f2fs/super.c | 1 + >> fs/f2fs/sysfs.c | 9 +++++++++ >> 5 files changed, 21 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs >> index c2a233f2a085..e5ad8dc70cb6 100644 >> --- a/Documentation/ABI/testing/sysfs-fs-f2fs >> +++ b/Documentation/ABI/testing/sysfs-fs-f2fs >> @@ -870,3 +870,11 @@ Description: This threshold is used to control triggering garbage collection whi >> reserved section before preallocating on pinned file. >> By default, the value is ovp_sections, especially, for zoned ufs, the >> value is 1. >> + >> +What: /sys/fs/f2fs//last_secno >> +Date: July 2025 >> +Contact: "Yuanhong Liao" >> +Description: This node is used to adjust the addressing end of f2fs when writing. >> + The default value is the maximum number of sections in the storage. If the >> + frontend space is full after adjusting the address, it will still address to >> + the back of the address until reaching the end of the memory. >> \ No newline at end of file >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h >> index e6dcd7e6f47c..7d93d8671033 100644 >> --- a/fs/f2fs/f2fs.h >> +++ b/fs/f2fs/f2fs.h >> @@ -1802,6 +1802,7 @@ struct f2fs_sb_info { >> spinlock_t dev_lock; /* protect dirty_device */ >> bool aligned_blksize; /* all devices has the same logical blksize */ >> unsigned int first_seq_zone_segno; /* first segno in sequential zone */ >> + unsigned int last_secno; /* for adjust the end of target device */ >> >> /* For write statistics */ >> u64 sectors_written_start; >> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c >> index cc82d42ef14c..192619bb2034 100644 >> --- a/fs/f2fs/segment.c >> +++ b/fs/f2fs/segment.c >> @@ -2811,7 +2811,7 @@ static int get_new_segment(struct f2fs_sb_info *sbi, >> secno = find_next_zero_bit(free_i->free_secmap, MAIN_SECS(sbi), hint); >> >> #ifdef CONFIG_BLK_DEV_ZONED >> - if (secno >= MAIN_SECS(sbi) && f2fs_sb_has_blkzoned(sbi)) { >> + if (secno >= sbi->last_secno && f2fs_sb_has_blkzoned(sbi)) { >> /* Write only to sequential zones */ >> if (sbi->blkzone_alloc_policy == BLKZONE_ALLOC_ONLY_SEQ) { >> hint = GET_SEC_FROM_SEG(sbi, sbi->first_seq_zone_segno); >> @@ -2827,7 +2827,7 @@ static int get_new_segment(struct f2fs_sb_info *sbi, >> } >> #endif >> >> - if (secno >= MAIN_SECS(sbi)) { >> + if (secno >= sbi->last_secno) { >> secno = find_first_zero_bit(free_i->free_secmap, >> MAIN_SECS(sbi)); >> if (secno >= MAIN_SECS(sbi)) { >> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c >> index 30c038413040..5b7de0734da7 100644 >> --- a/fs/f2fs/super.c >> +++ b/fs/f2fs/super.c >> @@ -3859,6 +3859,7 @@ static int sanity_check_raw_super(struct f2fs_sb_info *sbi, >> segs_per_sec = le32_to_cpu(raw_super->segs_per_sec); >> secs_per_zone = le32_to_cpu(raw_super->secs_per_zone); >> total_sections = le32_to_cpu(raw_super->section_count); >> + sbi->last_secno = total_sections; >> >> /* blocks_per_seg should be 512, given the above check */ >> blocks_per_seg = BIT(le32_to_cpu(raw_super->log_blocks_per_seg)); >> diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c >> index bdef926b3377..a4ab5c38e883 100644 >> --- a/fs/f2fs/sysfs.c >> +++ b/fs/f2fs/sysfs.c >> @@ -649,6 +649,13 @@ static ssize_t __sbi_store(struct f2fs_attr *a, >> return count; >> } >> >> + if (!strcmp(a->attr.name, "last_secno")) { >> + if (t < 0 || t > MAIN_SECS(sbi)) >> + return -EINVAL; >> + sbi->last_secno = t; > Will this race w/ f2fs_ioc_resize_fs() which will update MAIN_SECS()? > > Thanks, Yes, I missed the size update that will appear in f2fs_resize_fs. I will add the modifications in update_fs_metadata() and submit the v2 version later. Thanks. >> + return count; >> + } >> + >> #ifdef CONFIG_F2FS_IOSTAT >> if (!strcmp(a->attr.name, "iostat_enable")) { >> sbi->iostat_enable = !!t; >> @@ -1122,6 +1129,7 @@ F2FS_SBI_GENERAL_RW_ATTR(max_victim_search); >> F2FS_SBI_GENERAL_RW_ATTR(migration_granularity); >> F2FS_SBI_GENERAL_RW_ATTR(migration_window_granularity); >> F2FS_SBI_GENERAL_RW_ATTR(dir_level); >> +F2FS_SBI_GENERAL_RW_ATTR(last_secno); >> #ifdef CONFIG_F2FS_IOSTAT >> F2FS_SBI_GENERAL_RW_ATTR(iostat_enable); >> F2FS_SBI_GENERAL_RW_ATTR(iostat_period_ms); >> @@ -1285,6 +1293,7 @@ static struct attribute *f2fs_attrs[] = { >> ATTR_LIST(discard_idle_interval), >> ATTR_LIST(gc_idle_interval), >> ATTR_LIST(umount_discard_timeout), >> + ATTR_LIST(last_secno), >> #ifdef CONFIG_F2FS_IOSTAT >> ATTR_LIST(iostat_enable), >> ATTR_LIST(iostat_period_ms),