From: John Valdes <valdes@anl.gov>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: log recovery fails at mount
Date: Tue, 24 Jan 2012 16:58:40 -0600 [thread overview]
Message-ID: <20120124225840.GA20222@starfish.mcs.anl.gov> (raw)
In-Reply-To: <4F1E3C71.1020303@sandeen.net>
On Mon, Jan 23, 2012 at 11:06:57PM -0600, Eric Sandeen wrote:
> try:
>
> # xfs_metadump /dev/md4 md4.metadump
> # xfs_mdrestore md4.metadump md4.img
> # xfs_repair -L md4.img
>
> that'll repair a metadata image and you can see how much it runs into.
Good suggestion. Here's the result; looks innocuous:
prompt# xfs_repair -v -L md4.img
Phase 1 - find and verify superblock...
- block cache size set to 1242264 entries
Phase 2 - using internal log
- zero log...
zero_log: head block 123697 tail block 123687
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
- 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
- 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
- agno = 2
- agno = 3
- 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 = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
- agno = 25
- agno = 4
Phase 5 - rebuild AG headers and trees...
- agno = 0
- agno = 1
- agno = 2
- 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
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- agno = 0
- agno = 1
- agno = 2
- 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
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
XFS_REPAIR Summary Tue Jan 24 13:49:49 2012
Phase Start End Duration
Phase 1: 01/24 13:49:12 01/24 13:49:13 1 second
Phase 2: 01/24 13:49:13 01/24 13:49:18 5 seconds
Phase 3: 01/24 13:49:18 01/24 13:49:24 6 seconds
Phase 4: 01/24 : 01/24 13:49:49 01/24 13:49:49
Total run time: 37 seconds
done
However, if I loopback mount the img file, the file/directory names in
the mounted fs are mostly corrupted; that may be expected though since
it's just a metadata dump/restore?
prompt# mount -r -t xfs -o loop md4.img /mnt
prompt# ls /mnt
??5?z+o??%F_4(?R?.wrhE*] data K?ckw? T?o??n2o?,?0-|K#\o Z?w?9=ol\?7j??1T
Any other suggestions or comments before I let loose xfs_repair -L on
the real filesystem?
John
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-01-24 22:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 2:43 log recovery fails at mount John Valdes
2012-01-24 5:06 ` Eric Sandeen
2012-01-24 22:58 ` John Valdes [this message]
2012-01-24 23:03 ` Eric Sandeen
2012-01-24 23:34 ` John Valdes
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=20120124225840.GA20222@starfish.mcs.anl.gov \
--to=valdes@anl.gov \
--cc=sandeen@sandeen.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