Re: [f2fs-dev] [PATCH v5] f2fs: support dynamic reserve/release for device aliasing

[Daeho Jeong]

On Wed, Jul 29, 2026 at 4:44 AM Chao Yu <chao@xxxxxxxxxx> wrote:
>
> On 7/24/26 04:20, Daeho Jeong wrote:
> > From: Daeho Jeong <daehojeong@xxxxxxxxxx>
> >
> > This patch adds a dynamic management feature to the existing device
> > aliasing functionality. It allows users to dynamically reserve or
> > release specific devices from the filesystem's free pool at runtime
> > through new ioctls.
> >
> > To support this, three new ioctls are introduced:
> > - F2FS_IOC_RESERVE_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.
> >
> > - F2FS_IOC_RELEASE_DEV_ALIAS: This releases the reserved space of a
> >   previously reserved device aliasing file. It truncates the blocks
> >   associated with the file, which makes them available for general
> >   filesystem allocation again.
> >
> > - F2FS_IOC_GET_DEV_ALIAS_STATUS: This retrieves the current aliasing
> >   status of a device aliasing file, returning whether the file is
> >   released (inactive alias) or reserved (active alias, with blocks
> >   fully allocated on the device).
>
> Hi Daeho,
>
> BTW, could you please consider to do some coverage test to prevent from
> suffering potential corruption.
>
> e.g.:
> 1. call ioctls in low storage environment
> 2. race w/ checkpoint={disable,enable}
> 3. injecting faults in new ioctls + random shutdown
>
> To verify if filesystem or device alias file is corrupted, it needs to
> call fsck after the testcase, and find a way to verify whether device alias
> status is as expected or not.
>
> Please sharing your thoughts about this. :)

Thanks for the great suggestions!

Currently, my internal test case covers:

1. Pinned file allocation exclusion verification against reserved
device aliasing range.
2. Stress test under fsstress + concurrent CP/sync + asynchronous SPO
(Sudden Power Off) shutdowns, followed by fsck & kernel panic checks.
3. ENOSPC error rollback verification when storage is 100% full.

Based on your feedback, I agree we should expand the test coverage. I
will enhance the test case (or add sub-tests) to cover:
1. Race condition testing between new ioctls and
checkpoint={disable,enable} remounts, verifying -EINVAL responses
during checkpoint=disable.
2. Enabling F2FS fault injection to new ioctls.

Thanks!


>
> Thanks,