public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bs@q-leap.de>
To: linux-xfs@oss.sgi.com
Subject: xfs corruptions
Date: Thu, 04 Sep 2008 19:11:48 +0200	[thread overview]
Message-ID: <g9p4sl$smg$1@ger.gmane.org> (raw)

Hello,

I'm presently debugging the error handler of the MPT fusion driver and
therefore causing errors on the disk (Infortrend scsi hardware raids).
When I later on try to delete files and directories having been created
before and during the failures, "rm -fr" simply says directory not empty.
No message in dmesg about it, but xfs_repair reports errors, see below.
Once xfs_repair has done its jobs, removing these directories works fine.
But this shouldn't happen, should it? This is with 2.6.26

root@beo-11:~# xfs_repair /dev/inf/box-3a/disc
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
imap claims a free inode 1073741964 is in use, correcting imap and clearing
inode
cleared inode 1073741964
        - agno = 2
imap claims a free inode 2147483788 is in use, correcting imap and clearing
inode
cleared inode 2147483788
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
entry "9B769A18" in shortform directory 1073741962 references free inode
1073741964
junking entry "9B769A18" in directory inode 1073741962
        - agno = 2
entry "E95A1D2D" in shortform directory 2147483786 references free inode
2147483788
junking entry "E95A1D2D" in directory inode 2147483786
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...


Thanks,
Bernd

             reply	other threads:[~2008-09-04 17:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04 17:11 Bernd Schubert [this message]
2008-09-04 23:02 ` xfs corruptions Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2015-11-30 16:51 XFS corruptions Sandeep Patel
2015-11-30 17:40 ` Emmanuel Florac
2015-11-30 18:06   ` Sandeep Patel
2015-11-30 18:45     ` Emmanuel Florac
2015-12-01 12:18       ` Sandeep Patel
2015-12-01 13:50         ` Emmanuel Florac
2015-12-01 14:01           ` Sandeep Patel
2015-12-10 15:07           ` Sandeep Patel
2015-12-10 15:46             ` Emmanuel Florac
2015-12-10 19:51               ` Sandeep Patel
2016-01-11 14:20               ` Sandeep Patel
2016-01-11 15:16                 ` Emmanuel Florac
2016-03-16 13:15                   ` Sandeep Patel
2016-03-16 14:07                     ` Emmanuel Florac
2015-11-30 21:51 ` Dave Chinner
2015-11-30 22:04   ` Darrick J. Wong
2015-12-10 16:46 ` Eric Sandeen

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='g9p4sl$smg$1@ger.gmane.org' \
    --to=bs@q-leap.de \
    --cc=linux-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