All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.