Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mountpoint-util: Deal with kernel API breakage in "norecovery" mount option #32892

Merged
merged 1 commit into from
May 17, 2024

Conversation

DaanDeMeyer
Copy link
Contributor

@DaanDeMeyer DaanDeMeyer commented May 17, 2024

"norecovery" was deprecated for btrfs in
torvalds/linux@74ef001 and removed in
torvalds/linux@a1912f7.

Let's drop our assumption that btrfs supports "norecovery" and first query for the new name of the option followed by querying for the old name.

@github-actions github-actions bot added util-lib tests please-review PR is ready for (re-)review by a maintainer labels May 17, 2024
Copy link

github-actions bot commented May 17, 2024

Note

We had successfully released a new major release. We are no longer in a development freeze phase.
We will try our best to get back to your PR as soon as possible. Thank you for your patience.

…option

"norecovery" was deprecated for btrfs in
torvalds/linux@74ef001
and removed in
torvalds/linux@a1912f7.

Let's drop our assumption that btrfs supports "norecovery" and first query for the
new name of the option followed by querying for the old name.
@bluca bluca added btrfs good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed please-review PR is ready for (re-)review by a maintainer labels May 17, 2024
@yuwata yuwata added good-to-merge/with-minor-suggestions and removed good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed labels May 17, 2024
@kdave
Copy link

kdave commented May 17, 2024

You can call it API breakage as you want but note that it's been deprecated for 3 years (in 5.11). Nobody asked for keeping the option so it got removed.

@bluca
Copy link
Member

bluca commented May 17, 2024

You can call it API breakage as you want but note that it's been deprecated for 3 years (in 5.11). Nobody asked for keeping the option so it got removed.

Sorry, but expecting every one to closely follow the LKML at all times to monitor userspace API breakages is really not realistic. These days Github's code search works great, and can easily show whether an API is actually used or not, so it would be best if proponents of backward-incompatible changes actively tried and look for affected userspace components, rather than expecting everyone to notice by themselves - realistically, that only happens too late, once the breakage is done, as we have seen now.

@DaanDeMeyer
Copy link
Contributor Author

@kdave How were we supposed to know the option was even deprecated or removed? A warning in dmesg is not sufficient to make people aware this is happening. A very simple search on github from your end before removing the option would also have avoided this issue. You can't assume userspace developers are searching dmesg for warnings about deprecations. There is not even a kernel cmdline option we could have enabled to notice this deprecation before the option was actually removed.

@yuwata yuwata added good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed good-to-merge/with-minor-suggestions labels May 17, 2024
@bluca bluca merged commit e3828d7 into systemd:main May 17, 2024
42 of 44 checks passed
@poettering
Copy link
Member

Are you sure this even works? Iirc btrfs only very recently started to support the new mount api, and hence the nount option detection logic that builds on that doesnt work at all, it will always say supported.

I am pretty sure this change causes some serious borkage on old kernels?

@poettering
Copy link
Member

I figure one has to check for some mount option first that definitely doesnt exist. If that test succeeds nonetheless we are on a kernel where btrfs wasnt taught the new mount api yet, and hence assume norecover is the way to got.

What a clusterfuck. I wish kernel folks had any sense of "we dont break userspace" actually means.

@poettering
Copy link
Member

Ah our helper already does exactly that. Ignore me then.

@keszybz keszybz removed the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label May 17, 2024
@poettering
Copy link
Member

So actually no, this isnt right quite yet. I am pretty sure that if support for the new mount api in btrfs is not available we should assume "norecovery" exists. With this PR we assume it doeasnt however.

Hence, please make sure that if we cannot determine if btrfs supports norecovery or not (EAGAIN) we assume it does.

@poettering
Copy link
Member

I posted this on linux-btrfs ML btw:

https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/T/#u

I do hope they will revert this change upstream. But let's see.

@keszybz
Copy link
Member

keszybz commented May 21, 2024

So actually no, this isnt right quite yet. I am pretty sure that if support for the new mount api in btrfs is not available we should assume "norecovery" exists. With this PR we assume it doeasnt however.

Hence, please make sure that if we cannot determine if btrfs supports norecovery or not (EAGAIN) we assume it does.

#32948

intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request May 21, 2024
Although 'norecovery' mount option is marked deprecated for a long time
and a warning message is introduced during the deprecation window, it's
still actively utilized by several projects that need a safely way to
mount a btrfs without any writes.

Furthermore this 'norecovery' mount option is supported by most major
filesystems, which makes it harder to validate our motivation.

This patch would re-introduce the 'norecovery' mount option, and output
a message to recommend 'rescue=nologreplay' option.

Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: systemd/systemd#32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f7 ("btrfs: remove code for inode_cache and recovery mount options")
Cc: stable@vger.kernel.org # 6.8+
Signed-off-by: Qu Wenruo <wqu@suse.com>
@poettering
Copy link
Member

@bluca
Copy link
Member

bluca commented May 21, 2024

That's great, thanks for reporting that - I assume we want to keep this machinery anyway, given it is in at least 2 kernel releases? And there will be a warning anyway if the old option is used

bluca pushed a commit that referenced this pull request May 21, 2024
kdave pushed a commit to btrfs/linux that referenced this pull request May 21, 2024
Although 'norecovery' mount option was marked as deprecated for a long
time and a warning message was printed during the deprecation window,
it's still actively utilized by several projects that need a safer way
to mount a btrfs without any writes.

Furthermore this 'norecovery' mount option is supported by other major
filesystems, which makes it less clear what's our motivation to remove
it.

Re-introduce the 'norecovery' mount option, and output a message to recommend
'rescue=nologreplay' option.

Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: systemd/systemd#32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f7 ("btrfs: remove code for inode_cache and recovery mount options")
CC: stable@vger.kernel.org # 6.8+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request May 21, 2024
Although 'norecovery' mount option was marked as deprecated for a long
time and a warning message was printed during the deprecation window,
it's still actively utilized by several projects that need a safer way
to mount a btrfs without any writes.

Furthermore this 'norecovery' mount option is supported by other major
filesystems, which makes it less clear what's our motivation to remove
it.

Re-introduce the 'norecovery' mount option, and output a message to recommend
'rescue=nologreplay' option.

Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: systemd/systemd#32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f7 ("btrfs: remove code for inode_cache and recovery mount options")
CC: stable@vger.kernel.org # 6.8+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
@poettering
Copy link
Member

yes, new kernels will print an info level message apparently, so i guess we should keep this patch.

kdave pushed a commit to btrfs/linux that referenced this pull request May 22, 2024
Although 'norecovery' mount option was marked as deprecated for a long
time and a warning message was printed during the deprecation window,
it's still actively utilized by several projects that need a safer way
to mount a btrfs without any writes.

Furthermore this 'norecovery' mount option is supported by other major
filesystems, which makes it less clear what's our motivation to remove
it.

Re-introduce the 'norecovery' mount option, and output a message to recommend
'rescue=nologreplay' option.

Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: systemd/systemd#32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f7 ("btrfs: remove code for inode_cache and recovery mount options")
CC: stable@vger.kernel.org # 6.8+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
ionutnechita pushed a commit to sunlightlinux/linux-sunlight that referenced this pull request May 25, 2024
Although 'norecovery' mount option is marked deprecated for a long time
and a warning message is introduced during the deprecation window, it's
still actively utilized by several projects that need a safely way to
mount a btrfs without any writes.

Furthermore this 'norecovery' mount option is supported by most major
filesystems, which makes it harder to validate our motivation.

This patch would re-introduce the 'norecovery' mount option, and output
a message to recommend 'rescue=nologreplay' option.

Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: systemd/systemd#32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f7 ("btrfs: remove code for inode_cache and recovery mount options")
Cc: stable@vger.kernel.org # 6.8+
Change-Id: I10f2d85b9139fa6a8719d7ef2841b1b4ac03d5aa
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
bluca pushed a commit to bluca/systemd-stable that referenced this pull request May 26, 2024
bluca pushed a commit to bluca/systemd-stable that referenced this pull request May 26, 2024
keszybz added a commit to systemd/systemd-stable that referenced this pull request May 27, 2024
bluca pushed a commit to bluca/systemd-stable that referenced this pull request May 27, 2024
…rted by btrfs

Fixup for e3828d7, as requested in
systemd/systemd#32892 (comment).

(cherry picked from commit 055b465)
(cherry picked from commit 78e023a)
bluca pushed a commit to bluca/systemd-stable that referenced this pull request May 27, 2024
…rted by btrfs

Fixup for e3828d7, as requested in
systemd/systemd#32892 (comment).

(cherry picked from commit 055b465)
(cherry picked from commit 78e023a)
bluca pushed a commit to bluca/systemd-stable that referenced this pull request May 27, 2024
…rted by btrfs

Fixup for e3828d7, as requested in
systemd/systemd#32892 (comment).

(cherry picked from commit 055b465)
(cherry picked from commit 78e023a)
bluca pushed a commit to systemd/systemd-stable that referenced this pull request May 27, 2024
…rted by btrfs

Fixup for e3828d7, as requested in
systemd/systemd#32892 (comment).

(cherry picked from commit 055b465)
(cherry picked from commit 78e023a)
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this pull request Jun 7, 2024
BugLink: https://bugs.launchpad.net/bugs/2068591

Although 'norecovery' mount option was marked as deprecated for a long
time and a warning message was printed during the deprecation window,
it's still actively utilized by several projects that need a safer way
to mount a btrfs without any writes.

Furthermore this 'norecovery' mount option is supported by other major
filesystems, which makes it less clear what's our motivation to remove
it.

Re-introduce the 'norecovery' mount option, and output a message to recommend
'rescue=nologreplay' option.

Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: systemd/systemd#32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f7 ("btrfs: remove code for inode_cache and recovery mount options")
CC: stable@vger.kernel.org # 6.8+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

(cherry picked from commit 440861b1a03c72cc7be4a307e178dcaa6894479b)
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

7 participants