All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis.henriques@linux.dev>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Theodore Ts'o <tytso@mit.edu>,
	 Andreas Dilger <adilger@dilger.ca>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/2] e2fsck: make sure orphan files are cleaned-up
Date: Mon, 21 Oct 2024 10:24:31 +0100	[thread overview]
Message-ID: <87bjzdn700.fsf@linux.dev> (raw)
In-Reply-To: <62c41f80-4bfc-488e-ba8f-8e1d5fc472a9@sandeen.net> (Eric Sandeen's message of "Fri, 18 Oct 2024 19:46:24 -0500")

On Fri, Oct 18 2024, Eric Sandeen wrote:

> On 6/11/24 9:27 AM, Luis Henriques (SUSE) wrote:
>> Hi!
>> 
>> I'm sending a fix to e2fsck that forces the filesystem checks to happen
>> when the orphan file is present in the filesystem.  This patch resulted from
>> a bug reported in openSUSE Tumbleweed[1] where e2fsck doesn't clean-up this
>> file and later the filesystem  fails to be mounted read-only (because it
>> still requires recovery).
>
> Looks like Fedora is hitting this bug now:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2318710
>
> (unclear why fedora upgrade is leaving an unclean root fs on reboot, but
> that's a separate issue.)
>
> With this patch in place, bare e2fsck asks for confirmation, not sure if that's
> expected. But with "yes" answers, the filesystem is cleaned properly and
> mounts just fine.
>
> Also - shouldn't we go ahead and deal with the orphan inode file even on a
> readonly mount, as long as the bdev itself is not readonly?

Since that would be a filesystem-level change, my opinion is that we
should not do that in a read-only mount.  But that's just my opinion and
maybe there are other similar cases (I didn't check) where changes are
written on read-only mounts.

Cheers,
-- 
Luís

> ext4_mark_recovery_complete():
>
>         if (sb_rdonly(sb) && (ext4_has_feature_journal_needs_recovery(sb) ||
>             ext4_has_feature_orphan_present(sb))) {
>                 if (!ext4_orphan_file_empty(sb)) {
>                         ext4_error(sb, "Orphan file not empty on read-only fs.");
>                         err = -EFSCORRUPTED;
>                         goto out;
>                 }
>                 ext4_clear_feature_journal_needs_recovery(sb);
>                 ext4_clear_feature_orphan_present(sb);
>                 ext4_commit_super(sb);
>         }
>
> # losetup /dev/loop0 2318710-e2image.raw   ## from above bz attachment
> # e2fsck /dev/loop0 (without this patch)
> ...
> # mount -o ro /dev/loop0 mnt
> mount: /root/e2fsprogs/mnt: fsconfig system call failed: Structure needs cleaning.
>        dmesg(1) may have more information after failed mount system call.
> # dmesg | tail -n 2
> [ 3083.343622] EXT4-fs error (device loop0): ext4_mark_recovery_complete:6229: comm mount: Orphan file not empty on read-only fs.
> [ 3083.345339] EXT4-fs (loop0): mount failed
> # mount -o rw /dev/loop0 mnt
> # echo $?
> 0
>
> -Eric
>
>
>> I'm also sending a new test to validate this scenario.
>> 
>> [1] https://bugzilla.suse.com/show_bug.cgi?id=1226043
>> 
>> Luis Henriques (SUSE) (2):
>>   e2fsck: don'k skip checks if the orphan file is present in the
>>     filesystem
>>   tests: new test to check that the orphan file is cleaned up
>> 
>>  e2fsck/unix.c                      |   4 ++++
>>  tests/f_clear_orphan_file/expect.1 |  35 +++++++++++++++++++++++++++++
>>  tests/f_clear_orphan_file/expect.2 |   7 ++++++
>>  tests/f_clear_orphan_file/image.gz | Bin 0 -> 12449 bytes
>>  tests/f_clear_orphan_file/name     |   1 +
>>  tests/f_clear_orphan_file/script   |   2 ++
>>  6 files changed, 49 insertions(+)
>>  create mode 100644 tests/f_clear_orphan_file/expect.1
>>  create mode 100644 tests/f_clear_orphan_file/expect.2
>>  create mode 100644 tests/f_clear_orphan_file/image.gz
>>  create mode 100644 tests/f_clear_orphan_file/name
>>  create mode 100644 tests/f_clear_orphan_file/script
>> 
>> 
>


  reply	other threads:[~2024-10-21  9:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 14:27 [PATCH 0/2] e2fsck: make sure orphan files are cleaned-up Luis Henriques (SUSE)
2024-06-11 14:27 ` [PATCH 1/2] e2fsck: don't skip checks if the orphan file is present in the filesystem Luis Henriques (SUSE)
2024-06-11 14:27 ` [PATCH 2/2] tests: new test to check that the orphan file is cleaned up Luis Henriques (SUSE)
2024-08-21 13:12 ` [PATCH 0/2] e2fsck: make sure orphan files are cleaned-up Luis Henriques
2024-10-19  0:46 ` Eric Sandeen
2024-10-21  9:24   ` Luis Henriques [this message]
2024-10-21 21:08     ` Eric Sandeen
2024-10-25  3:53 ` Theodore Ts'o

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=87bjzdn700.fsf@linux.dev \
    --to=luis.henriques@linux.dev \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.