From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E318D1FE47B for ; Fri, 5 Jun 2026 22:10:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780697430; cv=none; b=BF6fsgmkwWy/05ERXqQ7SQ3CCz/lz7wE3/aeFv9CoBxD48nQM8TTzZkRWLDoM5VePt7p2LsgYPxmIVnOarWlOsW1+MxDze2qI++ZhLbMQLSkSLPOQrOWzEQ3tugodiEaD/979jPRRBymEvktpXcOw44EUHyMmyMgRXAvJLJOHnk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780697430; c=relaxed/simple; bh=VmWY4wK3W6V0F7STjFDjEhBw28smu1H0r5IlJkzEYxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=i+AtcC3TdIj+DkWGAAD/zr8Mn3xQ8NG3F+FJ5WycK1+kYK6XsJHQoig+9zfcWgfna9acsTrP2hQvzP4OBzATG5trmmtG94SCjwPUKan/aXDj/30BSAPKLjS7GBLLx9nATS+F9Ku/XSX3Ajtga+Yq4PuRK9P7wTc39XJXtlbYdJc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DZJs1NeG; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DZJs1NeG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 622D31F00893; Fri, 5 Jun 2026 22:10:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780697429; bh=iJT3Q7smY0LrmHruOEmo/PCSRB3GG8ERa4x6kmx4d+Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=DZJs1NeGHa6Aj5cGd2/4LKJNYX2ZOA007sU5tt1nQypR4gNWPS3L9LOEZfYrAYKIQ RTq217bR6iiqBK2d7qIhYjnUT+KbWjx1CwcLmkqDXnchtgIfICxGsfaVqI1g/rHhjQ 3bQaKxcYxDY0FdR+r064rlpKMDClNrsBXkPzXQ8V8VlyvWXERTIOMaZjkeGUCd03CW /bvma0EHSo8m52mqnvJKuRkL8B8XbrisWxR1u/8GmeJ161Cy/OKrjM752FGbhY4Q4M AbLNTaNZSh4pqPSFWH6MO0rpf7I2xEyKdY0tVY66HSW6Gh5RlGEr1ik4a7CvL99VKN a9v2JnKDIS3gA== Date: Fri, 5 Jun 2026 22:10:27 +0000 From: Eric Biggers To: Daeho Jeong Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Subject: Re: [f2fs-dev] [PATCH v2] f2fs: support dynamic include/exclude for device aliasing Message-ID: <20260605221027.GA2312230@google.com> References: <20260605212504.1080138-1-daeho43@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260605212504.1080138-1-daeho43@gmail.com> On Fri, Jun 05, 2026 at 02:25:04PM -0700, Daeho Jeong wrote: > - F2FS_IOC_EXCLUDE_DEV_ALIAS: This reclaims the space occupied by a > device aliasing file. It first performs a capacity check, resets GC > victim information for the target range, marks the segments as in-use > to prevent new allocations, and then triggers GC to migrate existing > valid data out of the range. Finally, it reserves these blocks in the > SIT to effectively exclude the device from the usable capacity. Does this do anything to zeroize the device so that random data isn't leaked in it, or is that the responsibility of the userspace code that reallocates the device to something? > @@ -2214,7 +2231,8 @@ static const struct { > FS_INLINE_DATA_FL | \ > FS_NOCOW_FL | \ > FS_VERITY_FL | \ > - FS_CASEFOLD_FL) > + FS_CASEFOLD_FL | \ > + F2FS_DEVICE_ALIAS_FL) This is extending FS_IOC_GETFLAGS, which you probably don't really want to be doing, right? - Eric