lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 31 Dec 2020 14:52:21 -0800
From:   "Darrick J. Wong" <>
To:     Dmitrii Tcvetkov <>
Subject: Re: [GIT PULL] xfs: new code for 5.11

On Tue, Dec 29, 2020 at 10:49:55AM +0300, Dmitrii Tcvetkov wrote:
> >Please pull the following branch containing all the new xfs code for
> >5.11.  In this release we add the ability to set a 'needsrepair' flag
> >indicating that we /know/ the filesystem requires xfs_repair, but other
> >than that, it's the usual strengthening of metadata validation and
> >miscellaneous cleanups.
> >...
> >New code for 5.11:
> >- Introduce a "needsrepair" "feature" to flag a filesystem as needing a
> >  pass through xfs_repair.  This is key to enabling filesystem upgrades
> >  (in xfs_db) that require xfs_repair to make minor adjustments to
> >metadata.
> Hello.
> Most likely I miss something obvious but according to xfs_repair(8):
> The filesystem to be checked and repaired must have been unmounted
> cleanly  using  normal  system  administration  procedures (the
> umount(8)  command  or  system  shutdown),  not  as  a  result of a
> crash or system reset.  If the filesystem has not been unmounted
> cleanly, mount it and unmount it cleanly before running xfs_repair.
> which is there since commit d321ceac "add libxlog directory"
> Date:   Wed Oct 17 11:00:32 2001 +0000 in xfsprogs-dev[1]. 
> So will be there situation of uncleanly unmounted filesystem with
> "needsrepair" bit set?

No.  If we detect metadata corruption we stop writing metadata
and take the fs offline immediately.  We would not set needsrepair, for
exactly the reasons you outline.


> Will one be able to mount and umount it before running xfs_repair in
> that case?
> [1] git://

Powered by blists - more mailing lists