Split device-alias remount handling into two changes.  The first records a
stable device-to-inode mapping so a custom alias name can be reserved again
after release and remount.  The second uses that mapping to keep released
alias devices out of pinned allocation, both immediately and after remount.

The f2fs-tools layout and mkfs update will be sent separately because it
applies to a different repository.

Wenjie Qi (2):
  f2fs: persist device alias inode across remount
  f2fs: keep released alias devices out of pinned allocation

 fs/f2fs/file.c          | 100 ++++++++++++++++++++++++++++++++++------
 fs/f2fs/super.c         |  48 +++++++++++++++++++
 include/linux/f2fs_fs.h |   3 +-
 3 files changed, 136 insertions(+), 15 deletions(-)

-- 
2.43.0

On Wed, Aug 26, 2026 at 8:42 AM Wenjie Qi <qwjhust@gmail.com> wrote:
>
> Split device-alias remount handling into two changes.  The first records a
> stable device-to-inode mapping so a custom alias name can be reserved again
> after release and remount.  The second uses that mapping to keep released
> alias devices out of pinned allocation, both immediately and after remount.
>
> The f2fs-tools layout and mkfs update will be sent separately because it
> applies to a different repository.
>
> Wenjie Qi (2):
>   f2fs: persist device alias inode across remount
>   f2fs: keep released alias devices out of pinned allocation

Hi Wenjie,

Thanks for pointing out this issue and for the patch series.

However, there are several concerns with the proposed approach:

1. Fresh mount issue:
Since mkfs.f2fs does not populate dev_alias_ino in the superblock, on
the very first mount right after format with a custom alias name,
f2fs_restore_device_alias() will still fall back to the basename
lookup, fail to find the alias file, and leave FDEV(i).has_alias unset
until a release ioctl is explicitly called at runtime.

2. Superblock updates during runtime ioctl:
Writing and committing the superblock (f2fs_commit_super()) during the
runtime release ioctl path adds unnecessary complexity and overhead to
regular filesystem operations.

3. On-disk format change and kernel complexity:
Modifying the on-disk superblock reserved area and introducing
validation logic in the kernel adds notable complexity to resolve a
name-mismatch issue that can be prevented at format time.

The original design intent of device aliasing was to map a device to
an alias file that shares the exact same name as the device basename
(for example, /dev/block/by-name/userdata_exp mapped to userdata_exp).
Rather than changing the on-disk format and kernel runtime paths, the
cleaner and more fundamental fix is to enforce that the alias filename
matches the device basename in mkfs.f2fs.
In addition, we can allow the `-c <device_path>@` syntax in mkfs.f2fs
so that users don't need to specify the filename redundantly.
I will prepare and submit a patch for f2fs-tools to enforce this alignment.

Thanks,

>
>  fs/f2fs/file.c          | 100 ++++++++++++++++++++++++++++++++++------
>  fs/f2fs/super.c         |  48 +++++++++++++++++++
>  include/linux/f2fs_fs.h |   3 +-
>  3 files changed, 136 insertions(+), 15 deletions(-)
>
> --
> 2.43.0
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Hi Daeho,

The f2fs-tools companion patch was sent separately. It populates
dev_alias_ino[] when mkfs assigns the alias inodes, before calculating
the superblock checksum, so a filesystem created with the updated tools
has the mapping on its first mount.

Current mkfs.f2fs accepts an arbitrary slash-free alias_filename.
Enforcing basename equality will prevent new custom aliases, but it does
not handle existing filesystems: after release and remount, reserve
cannot identify a custom-named alias, and has_alias is not restored for
pinned allocation.

The added superblock commit is needed only when the mapping is first
recorded, and the release ioctl already ends with a synchronous
checkpoint.

Should existing filesystems created with custom alias filenames remain
supported? If so, a tools-only restriction does not seem sufficient.

Thanks,
Wenjie

On Wed, Aug 26, 2026 at 10:10 AM Wenjie Qi <qwjhust@gmail.com> wrote:
>
> Hi Daeho,
>
> The f2fs-tools companion patch was sent separately. It populates
> dev_alias_ino[] when mkfs assigns the alias inodes, before calculating
> the superblock checksum, so a filesystem created with the updated tools
> has the mapping on its first mount.
>
> Current mkfs.f2fs accepts an arbitrary slash-free alias_filename.
> Enforcing basename equality will prevent new custom aliases, but it does
> not handle existing filesystems: after release and remount, reserve
> cannot identify a custom-named alias, and has_alias is not restored for
> pinned allocation.
>
> The added superblock commit is needed only when the mapping is first
> recorded, and the release ioctl already ends with a synchronous
> checkpoint.
>
> Should existing filesystems created with custom alias filenames remain
> supported? If so, a tools-only restriction does not seem sufficient.
>

Thanks for the clarification.

However, I don't think we need to modify the on-disk superblock format for this:

1. Custom alias filenames with dynamic reserve/release have never
worked properly from the beginning (as you noted, reserve and remount
with has_alias were already broken upon the introduction).
Since it was never a functioning feature in the wild, enforcing the
name alignment in mkfs.f2fs does not break any existing working
setups.

2. In real-world production environments (such as Android), the
partition name and alias filename are already configured identically
via /dev/block/by-name/ symlinks (e.g., -c
/dev/block/by-name/foo@foo).

3. If someone really wants a specific alias filename, they can simply
point to an appropriately named device node or symlink (e.g.,
/dev/block/by-name/my_alias@).

Modifying the on-disk superblock layout and performing runtime
superblock writes (f2fs_commit_super()) in ioctl paths introduce
permanent architectural baggage and complexity to the kernel, just to
support a corner case that was broken since its inception and can be
cleanly prevented at format time.

Thanks,

> Thanks,
> Wenjie