From: Eric Sandeen <sandeen@sandeen.net>
To: "Agarwal, Amit" <Amit.Agarwal@echostar.com>
Cc: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: xfs_repair deletes file
Date: Fri, 19 Mar 2010 15:36:37 -0500 [thread overview]
Message-ID: <4BA3E055.2060100@sandeen.net> (raw)
In-Reply-To: <FF09DFEC8ECE664A856A5010EAF760BD0AF56074B4@ECHOEXCC1.SATS.CORP>
Agarwal, Amit wrote:
> Hi
>
> I need some help related to xfs repair.
>
> xfs_repair is deleting files which are more than ~10G from the real time partition. This is happening quite frequently.
>
> xfs_repair version 3.0.0
> Linux -> 2.6.18.8
might be best to retest on a recent kernel, as this looks like something went
wrong at runtime.
Do you have a testcase to recreate the situation?
-Eric
> Following is the output of xfs_repair
>
> 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
> data fork in rt inode 16779171 claims used rt block 16538
> bad data fork in inode 16779171
> cleared inode 16779171
> data fork in rt inode 16779185 claims used rt block 24441
> bad data fork in inode 16779185
> cleared inode 16779185
> - 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
> entry "es33554469.tsp" at block 0 offset 4040 in directory inode 16777344 references free inode 16779171
> clearing inode number in entry at offset 4040...
> entry "es33554472.tsp" at block 1 offset 432 in directory inode 16777344 references free inode 16779185
> clearing inode number in entry at offset 432...
> - agno = 2
> - agno = 3
> Phase 5 - rebuild AG headers and trees...
> - generate realtime summary info and bitmap...
> - reset superblock...
> Phase 6 - check inode connectivity...
> - resetting contents of realtime bitmap and summary inodes
> - traversing filesystem ...
> bad hash table for directory inode 16777344 (no data entry): rebuilding
> rebuilding directory inode 16777344
> - traversal finished ...
> - moving disconnected inodes to lost+found ...
> Phase 7 - verify and correct link counts...
> done
>
> Thanks for your time
>
> Amit Agarwal
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-03-19 20:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-19 17:20 xfs_repair deletes file Agarwal, Amit
2010-03-19 20:36 ` Eric Sandeen [this message]
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=4BA3E055.2060100@sandeen.net \
--to=sandeen@sandeen.net \
--cc=Amit.Agarwal@echostar.com \
--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.