public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Roger Willcocks <roger@filmlight.ltd.uk>,
	Leslie Rhorer <lrhorer@mygrande.net>
Cc: Brian Foster <bfoster@redhat.com>,
	Kris Rusocki <kszysiu@braxis.org>,
	"Rhorer, Leslie" <Leslie.Rhorer@level3.com>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: XFS File system in trouble
Date: Sat, 15 Aug 2015 13:48:18 -0500	[thread overview]
Message-ID: <55CF8972.8020306@sandeen.net> (raw)
In-Reply-To: <74DC7EBF-0029-4E5E-9D96-DF193E2BE83F@filmlight.ltd.uk>

On 8/15/15 7:28 AM, Roger Willcocks wrote:
> xfs_repair 3.2.1 runs cleanly.
> 
> xfs_repair 3.1.1 complains about a load of stuff, including:

I wouldn't expect v3.1.1 to work at all, because:

# db/xfs_db -V
xfs_db version 4.2.0-rc1
# db/xfs_db /mnt/test2/leslie/md0.img -c version
versionnum [0xbdb4+0x8a] = V4,NLINK,DIRV2,ATTR,ALIGN,DALIGN,LOGV2,EXTFLG,SECTOR,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT

the filesystem has 32-bit project IDs, and:

# git log --oneline | grep -i "projid32bit"
dd536e1 xfsprogs: Note projid32bit default change in mkfs.xfs manpage
22bc10e xfsprogs: projid32bit handling

# git describe --contains 22bc10e
v3.1.4~2

that feature support didn't show up until v3.1.4.  Were you running a stock v3.1.1?

Anyway, in my testing, up to v3.2.0, repair finds a lot of errors (and spends some
time looking for a proper superblock)

v3.2.1 finds no errors.

The errors stopped showing up as of:

commit d085fb486f8b33304f2fdf704411313ffc8bcc0c
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue Jul 8 10:36:39 2014 +1000

    repair: fix quota inode handling in secondary superblocks
    
    Changes to support separate project quota inodes changed the way
    quota inodes got written to the superblock. The current code is
    tailored for the needs to the kernel, where the inodes should only
    be written if certain falgs are set saying a quota type is enabled.
    
    Unfortunately, when recovering a corrupt secondary superblock, we
    need to unconditionally write the quota inode fields after we
    unconditionally zero the quota flags field. The result of this bug
    is that the bad quota inode fields cannot be cleared and hence
    always are reported by bad by repair in subsequent runs.
    
    Fix this by directly clearing the quota inodes in the superblock
    buffers so that we do need to set special flags to get
    xfs_sb_to_disk() to do the right thing as setting flags leave bad
    flag values in the superblock instead of bad inode numbers....
    
    Also, when clearing the inode numbers, write them as NULLFSINO
    rather than 0 as this is what the kernel will write them as if quota
    is turned off.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Dave Chinner <david@fromorbit.com>

I'll have to look into that commit, and the errors found prior.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-08-15 18:48 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-18  1:46 XFS File system in trouble Rhorer, Leslie
2015-07-18 14:16 ` Eric Sandeen
2015-07-18 17:23   ` Rhorer, Leslie
2015-07-18 17:47     ` Kris Rusocki
2015-07-18 18:12       ` Leslie Rhorer
2015-07-19  1:02       ` Leslie Rhorer
2015-07-19 23:27         ` Dave Chinner
2015-07-20  7:41           ` Leslie Rhorer
2015-07-20  8:05             ` Martin Papik
2015-07-20  8:35               ` Leslie Rhorer
2015-07-20  8:52                 ` Martin Papik
2015-07-20 13:08                 ` Gim Leong Chin
2015-07-20 13:34             ` Eric Sandeen
2015-07-23  3:18             ` Eric Sandeen
2015-07-24 13:47               ` Leslie Rhorer
2015-07-24 14:44                 ` Eric Sandeen
2015-07-24 15:29                   ` Rhorer, Leslie
2015-07-20 11:17         ` Brian Foster
2015-07-23  1:45           ` Leslie Rhorer
2015-07-23 11:36             ` Brian Foster
2015-07-28  7:46           ` Leslie Rhorer
2015-07-28  8:35             ` Stefan Ring
2015-07-28 10:48             ` Roger Willcocks
2015-07-28 12:33             ` Brian Foster
2015-07-28 15:13               ` Leslie Rhorer
2015-07-28 16:53                 ` Eric Sandeen
2015-07-28 19:12                   ` Martin Papik
2015-07-28 19:52                     ` Martin Steigerwald
2015-07-28 22:11                 ` Brian Foster
2015-08-02 20:24                   ` Leslie Rhorer
2015-08-04  7:52                     ` Leslie Rhorer
2015-08-04 12:19                       ` Brian Foster
2015-08-04 22:42                       ` Dave Chinner
2015-08-10  1:37                         ` Leslie Rhorer
2015-08-13  6:21                           ` Leslie Rhorer
2015-08-14  1:26                             ` Dave Chinner
2015-08-14 23:12                               ` Leslie Rhorer
2015-08-15 12:28                                 ` Roger Willcocks
2015-08-15 18:48                                   ` Eric Sandeen [this message]
2015-08-15 18:57                                     ` Roger Willcocks
2015-08-15 22:48                                       ` Dave Chinner
2015-08-15 19:00                                     ` Eric Sandeen
2015-08-15 19:13                                       ` Roger Willcocks
2015-08-16  0:32                                       ` Eric Sandeen
2015-08-18  2:14                                 ` Dave Chinner

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=55CF8972.8020306@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=Leslie.Rhorer@level3.com \
    --cc=bfoster@redhat.com \
    --cc=kszysiu@braxis.org \
    --cc=lrhorer@mygrande.net \
    --cc=roger@filmlight.ltd.uk \
    --cc=xfs@oss.sgi.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