From: Dave B <xfs_bugs@daxxi.net>
To: xfs@oss.sgi.com
Subject: Corrupt xfs on USB HDD : sub-optimal xfs_repair
Date: Mon, 02 Apr 2012 08:45:32 +0100 [thread overview]
Message-ID: <4F79591C.6090508@daxxi.net> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2461 bytes --]
Hi,
The two files in the root directory of a 500GB external USB HDD became
corrupt,
probably due to a power failure.
dave@K-Matrix $ ls -l /media/Galaxy/
ls: cannot access /media/Galaxy/ChnSchld_pre_4-14.tgz: No such file or
directory
ls: cannot access /media/Galaxy/dhr820xu.ext: No such file or directory
total 24
?????????? ? ? ? ? ? ChnSchld_pre_4-14.tgz
?????????? ? ? ? ? ? dhr820xu.ext
drwxr-xr-x 7 dave dave 4096 2012-02-13 12:45 DHR recordings
drwxr-xr-x 212 dave dave 12288 2008-11-30 00:21 Miles Davis
drwxr-xr-x 5 dave dave 4096 2012-02-16 06:06 PartImage
xfs_repair didn't help much; it just removed the two filenames.
At minimum, I expected two entries in L+F but the L+F directory was not
created.
dave@K-Matrix $ sudo xfs_repair /dev/sdc1
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
- 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
entry "ChnSchld_pre_4-14.tgz" in shortform directory 128 references free
inode 48145461
junking entry "ChnSchld_pre_4-14.tgz" in directory inode 128
entry "dhr820xu.ext" in shortform directory 128 references free inode
48145451
junking entry "dhr820xu.ext" in directory inode 128
- agno = 1
- agno = 2
- agno = 3
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 ...
Phase 7 - verify and correct link counts...
done
See longer console session and before/after metadumps in ~7MB d/l at:
http://daxxi.net/xfs/Galaxy_500GB_xfs.tar.gz
user: xfs , p/w: xfs
(please only d/l if 2x240MB metadumps will be meaningful to you)
Environment:
Linux K-Matrix 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC
2012 i686 athlon i386 GNU/Linux
Dave
[-- Attachment #1.2: Type: text/html, Size: 3477 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2012-04-02 7:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 7:45 Dave B [this message]
2012-04-03 18:39 ` Corrupt xfs on USB HDD : sub-optimal xfs_repair Eric Sandeen
2012-04-04 16:14 ` Eric Sandeen
2012-04-04 18:57 ` Dave B
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=4F79591C.6090508@daxxi.net \
--to=xfs_bugs@daxxi.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