Re: [f2fs-dev] [PATCH v2] f2fs: support dynamic include/exclude for device aliasing
Daeho Jeong <[email protected]>
| Newsgroups | net.sourceforge.lists.linux-f2fs-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CACOAw_xrMij0pXjFkS4gY0kt5buvfZ0gmzbcP+zx4-ox7n+_3Q@mail.gmail.com> |
On Fri, Jun 5, 2026 at 3:10 PM Eric Biggers <[email protected]> wrote: > > 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? By default, this ioctl does not zeroize or discard the underlying physical device upon exclusion. Currently, ensuring that stale random data isn't leaked is the responsibility of the userspace claiming the block device. We deliberately decoupled bulk zeroing/discard from the kernel ioctl because: - Synchronously zeroing out or issuing massive blkdiscard requests across multi-gigabyte partitions inside the ioctl would introduce prohibitive I/O latency spikes and unnecessary flash wear (P/E cycles). - Access Control: The F2FS_IOC_EXCLUDE_DEV_ALIAS ioctl strictly requires CAP_SYS_ADMIN. Unprivileged users cannot trigger this transition. - Raw Device Protection: Accessing the excluded raw block device directly requires root/block-group privileges and matching SELinux permissions. - fscrypt Encryption: In typical production environments (such as Android), file contents are encrypted via fscrypt. Stale disk remnants remain unreadable ciphertext, preventing meaningful data leakage. However, if you believe a kernel-enforced sanitization mechanism is necessary to prevent it, we would be glad to support an optional secure zeroing/discard flag in the exclude ioctl. > > > @@ -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? It seems my test code was not properly cleaned up before submission. I'm sorry about the confusion. > > - Eric _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel