Bug#956877: release-notes: Upgrade from XFS removes mount option "barrier|nobarrier"

[Benedikt Tuchen]

Package: release-notes
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

*** End of the template - remove these template lines ***

While doing an upgrade from Stretch to Buster on a Laptop with XFS
Filesystem in use. After the upgrade the laptop doesn't boot into
the system because of the removed "barrier|nobarrier" mount option
for XFS in version 4.19.

I think this issue should be mentioned in the "5. Issues to be aware
of for buster" part of the release-notes in Buster.


-- System Information:
Debian Release: 9.12
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-0.bpo.6-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

[Hendrik Boom]

Dear Benedikt, all,

Post by Benedikt Tuchen
While doing an upgrade from Stretch to Buster on a Laptop with XFS
Filesystem in use. After the upgrade the laptop doesn't boot into
the system because of the removed "barrier|nobarrier" mount option
for XFS in version 4.19.
I think this issue should be mentioned in the "5. Issues to be aware
of for buster" part of the release-notes in Buster.

What is exactly the problem? Does everybody with XFS run into this
issue? Do you have a solution for the problem that we can mention? Or,
phrased differently, what should the user do if they have an XFS
filesystem and want to upgrade to buster?
Paul

They would have to remove the "barrier" or "nobarrier" keyword if they
use either in their fstab (or in scripts that passes that mount option
explicitly).
If I try to mount an XFS file system with "barrier" (or "nobarrier"), I
"""
mount: <path>: wrong fs type, bad option, bad superblock on <path>,
missing codepage or helper program, or other error.
"""
(using mount -o ...,barrier - I don't remember if the fstab message is
better)

Would that refer to the write battier on the hard drive? Isn't that
essential to the safe operation of XFS?

-- hendrik

[Hendrik Boom]

Post by Hendrik Boom

[...]

Would that refer to the write battier on the hard drive? Isn't that
essential to the safe operation of XFS?
-- hendrik

Not any longer AFAICT. The following patch discussion in the Linux
* https://patchwork.kernel.org/patch/9486549/

Yes. That tells me that the option was ignored, but write barriers were
still used when required for integrity.

-- hendrik

[Paul Gevers]

Control: tag -1 patch

Hi,

How's this?

+ <section id="xfs-removes-mount-options">
+ <title>The XFS file system no longer supports barrier/nobarrier
+ option</title>
+ <para>
+ The XFS file system has removed the <literal>barrier</literal>
+ and <literal>nobarrier</literal> mount options. It is
+ recommended to check <filename>/etc/fstab</filename> for the
+ presence of either keyworrd and remove if. XFS will fail to start
+ when mounted with either option.
+ </para>
+ </section>

Paul

[Justin B Rye]

Post by Paul Gevers
Control: tag -1 patch
Hi,
How's this?
+ <section id="xfs-removes-mount-options">
+ <title>The XFS file system no longer supports barrier/nobarrier
+ option</title>
+ <para>
+ The XFS file system has removed the <literal>barrier</literal>
+ and <literal>nobarrier</literal> mount options. It is
+ recommended to check <filename>/etc/fstab</filename> for the
+ presence of either keyworrd and remove if. XFS will fail to start

^ ^

Post by Paul Gevers
+ when mounted with either option.
+ </para>
+ </section>

Make that
presence of either keyword and remove it. XFS will fail to start
^ ^
And I'm not sure about "start"... maybe it should be swapped around to
"Partitions using these options will fail to mount".

[Miguel Figueiredo]

Às 21:43 de 13/03/21, Paul Gevers escreveu:
[...]

Post by Paul Gevers
+ The XFS file system has removed the <literal>barrier</literal>
+ and <literal>nobarrier</literal> mount options.

[...]


How about: The mount options were removed from the XFS file system ?

[Justin B Rye]

Post by Miguel Figueiredo
[...]

Post by Paul Gevers
+ The XFS file system has removed the <literal>barrier</literal>
+ and <literal>nobarrier</literal> mount options.

How about: The mount options were removed from the XFS file system ?

Oh, yes, it's true that it was the developers who did the removing,
not the software... but phrasing it like that makes it sound as if we
were talking about one particular XFS-formatted partition that was at
some point given different options in /etc/fstab. How about:

Support for the <literal>barrier</literal> and
<literal>nobarrier</literal> mount options has been removed
from the XFS file system.

(Or we could even just say

The XFS file system no longer supports the <literal>barrier</literal>
and <literal>nobarrier</literal> mount options.

except that when I go and look at the context I see this is more or
less identical to the title line, so no, don't use that.)

[Debian Bug Tracking System]

This post might be inappropriate. Click to display it.

[Debian Bug Tracking System]

Your message dated Sun, 14 Mar 2021 07:52:47 +0100
with message-id <878957ec-c025-ceb8-1954-***@debian.org>
and subject line Re: Bug#956877: release-notes: Upgrade from XFS removes mount option "barrier|nobarrier"
has caused the Debian Bug report #956877,
regarding release-notes: Upgrade from XFS removes mount option "barrier|nobarrier"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)