public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Bast <daniel.bast@gmx.net>
To: xfs@oss.sgi.com
Subject: xfs_admin -c 1  + xfs_repair problem
Date: Mon, 28 Apr 2008 20:30:56 +0200	[thread overview]
Message-ID: <481617E0.3070801@gmx.net> (raw)

Hi,

i tried to enable lazy counts with "xfs_admin -c 1 device" with 
xfs_admin from xfsprogs 2.9.8. Unfortunately that process got stuck 
without any message. After several hours without any IO or CPU workload 
i killed the process and started xfs_repair, but that also got stuck (in 
"Phase 6") without any IO or CPU workload or any extra message. The 
xfs_repair being stuck in "Phase 6" is reproduceable with a 
metadump-image of the filesystem.

I was able to mount the device but don't want to use it because i'm not 
sure if everything is ok.

How can i resolve that problem? What information do you need? I can 
provide the metadump image (bzip compressed: 28MB) if necessary.

Here are some informations that are maybe useful:

  xfs_repair -v /dev/sda7
  Phase 1 - find and verify superblock...
          - block cache size set to 11472 entries
  Phase 2 - using internal log
          - zero log...
  zero_log: head block 2 tail block 2
          - 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
          - agno = 2
          - agno = 3
          - 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
          - agno = 2
          - agno = 3
  Phase 5 - rebuild AG headers and trees...
          - agno = 0
          - agno = 1
          - agno = 2
          - agno = 3
          - reset superblock...
  Phase 6 - check inode connectivity...
          - resetting contents of realtime bitmap and summary inodes
          - traversing filesystem ...
          - agno = 0


after the killed xfs_admin -c 1 and xfs_repair processes:
xfs_info /dev/sda7
meta-data=/dev/sda7              isize=256    agcount=4, agsize=24719013 
blks
          =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=98876050, imaxpct=25
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=2
          =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=65536  blocks=0, rtextents=0


a new 'xfs_repair -v /dev/sda7' straced:
strace -ff -p 6364
Process 6409 attached with 6 threads - interrupt to quit
[pid  6364] futex(0x851e2cc, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid  6405] futex(0xb146e3d8, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  6406] futex(0xb146e358, FUTEX_WAIT, 1, NULL <unfinished ...>
[pid  6407] futex(0xb146e358, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid  6408] futex(0xb146e358, FUTEX_WAIT, 3, NULL <unfinished ...>
[pid  6409] futex(0xb146e358, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  6406] <... futex resumed> )       = -1 EAGAIN (Resource 
temporarily unavailable)
[pid  6407] <... futex resumed> )       = -1 EAGAIN (Resource 
temporarily unavailable)
[pid  6408] <... futex resumed> )       = -1 EAGAIN (Resource 
temporarily unavailable)
[pid  6406] futex(0xb146e358, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  6407] futex(0xb146e358, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  6408] futex(0xb146e358, FUTEX_WAIT, 4, NULL


Thanks
  Daniel

P.S. Please CC me, because i'm not subscribed to the list.

             reply	other threads:[~2008-04-28 18:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28 18:30 Daniel Bast [this message]
2008-04-29  0:48 ` xfs_admin -c 1 + xfs_repair problem Barry Naujok
2008-04-29  6:34   ` Daniel Bast
2008-04-29  6:48     ` Barry Naujok

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=481617E0.3070801@gmx.net \
    --to=daniel.bast@gmx.net \
    --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