Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Tigran Aivazian <aivazian.tigran@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Linux Filesystems Development <linux-fsdevel@vger.kernel.org>,
	Linux ext4 <linux-ext4@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Baokun Li <libaokun@linux.alibaba.com>, Jan Kara <jack@suse.cz>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>,
	"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
	Zhang Yi <yi.zhang@huawei.com>
Subject: Re: ext4: spurious "orphan cleanup on readonly fs" due to remount,ro failing to reset orphan_file structures
Date: Mon, 3 Aug 2026 07:28:30 +0700	[thread overview]
Message-ID: <am_gplyBEyvbuHM_@archie.me> (raw)
In-Reply-To: <CAK+_RLmWU-GjYu9Z+AWnoKd__AiaWZUt=zOkx3jr2-a4Hv3KHg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]

[Cc'ing ext4 folks with full reply context]

On Sun, Aug 02, 2026 at 11:18:39PM +0100, Tigran Aivazian wrote:
> Hello,
> 
> I have been experimenting with optimising rootfs for custom builds of
> Ubuntu 26 with various options like fast_commit, sparse_super2,
> orphan_file, inline_data, metadata_csum_seed, etc. And I noticed
> something strange: if my root filesystem is made with "orphan_file"
> feature then on every reboot I get this message:
> 
> EXT4-fs (sda): orphan cleanup on readonly fs
> 
> (tested with SSD, NVMe and even old HDD -- because initially I thought
> that maybe it was NVMe controller failing to flush its volatile DRAM
> cache to the NAND flash, but no, it wasn't the reason)
> 
> I think what happens here is that when a filesystem with the
> "orphan_file" feature is fully unmounted, ext4_put_super()
> successfully clears the "orphan_present" superblock flag AND properly
> collapses/resets the physical orphan file headers. However, during a
> read-only remount (which systemd must do for / in order to halt the
> system) ext4_reconfigure() clears the "orphan_present" superblock flag
> but skips resetting the physical orphan file structures. Consequently,
> on the next boot (which starts with a read-only mount of /),
> ext4_fill_super() observes that while the superblock flag is clear,
> the orphan file itself appears non-empty. This unconditionally
> triggers ext4_orphan_cleanup(), which prints the spurious warning,
> scans the file, finds 0 orphans, and completes silently.
> 
> Let's test this theory on the kernel 7.0.0-28-generic of Ubuntu 26:

Can you also confirm this on latest mainline (7.2-rc6)?

> 
> # 1. Create a filesystem with the orphan_file feature
> mkfs.ext4 -O orphan_file /dev/sda
> 
> # 2. Mount read-write
> mount -o rw /dev/sda /mnt
> 
> # 3. Remount read-only (Simulating systemd shutdown)
> # This clears the orphan_present flag in the superblock, but leaves
> the orphan file structures intact.
> mount -o remount,ro /mnt
> 
> # 4. Unmount and mount read-only (Simulating the next boot)
> umount /mnt
> mount -o ro /dev/sda /mnt
> 
> Expected result in dmesg: nothing (well, except the usual
> mount/remount messages about ordered data mode, etc).
> 
> Actual result in dmesg:
> 
> EXT4-fs (sda): orphan cleanup on readonly fs
> 
> Since this affects the default shutdown path for any modern Linux
> distribution using systemd and ext4 with the "orphan_file" feature, it
> would be great to get the remount,ro teardown path aligned with the
> full unmount teardown path in this aspect.
> 

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

           reply	other threads:[~2026-08-03  0:28 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAK+_RLmWU-GjYu9Z+AWnoKd__AiaWZUt=zOkx3jr2-a4Hv3KHg@mail.gmail.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=am_gplyBEyvbuHM_@archie.me \
    --to=bagasdotme@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=aivazian.tigran@gmail.com \
    --cc=jack@suse.cz \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox