<br><br><div class="gmail_quote">On Thu, Sep 20, 2012 at 11:00 PM, Eric Sandeen <span dir="ltr"><<a href="mailto:sandeen@sandeen.net" target="_blank">sandeen@sandeen.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 9/20/12 7:40 PM, Anand Tiwari wrote:<br>
> Hi All,<br>
><br>
> I have been looking into an issue with xfs_repair with realtime sub volume. some times while running xfs_repair I see following errors<br>
><br>
> ----------------------------<br>
> data fork in rt inode 134 claims used rt block 19607<br>
> bad data fork in inode 134<br>
> would have cleared inode 134<br>
> data fork in rt inode 135 claims used rt block 29607<br>
> bad data fork in inode 135<br>
> would have cleared inode 135<br>
> - agno = 1<br>
> - agno = 2<br>
> - agno = 3<br>
> - process newly discovered inodes...<br>
> Phase 4 - check for duplicate blocks...<br>
> - setting up duplicate extent list...<br>
> - check for inodes claiming duplicate blocks...<br>
> - agno = 0<br>
> - agno = 1<br>
> - agno = 2<br>
> - agno = 3<br>
> entry "test-011" in shortform directory 128 references free inode 134<br>
> would have junked entry "test-011" in directory inode 128<br>
> entry "test-0" in shortform directory 128 references free inode 135<br>
> would have junked entry "test-0" in directory inode 128<br>
> data fork in rt ino 134 claims dup rt extent,off - 0, start - 7942144, count 2097000<br>
> bad data fork in inode 134<br>
> would have cleared inode 134<br>
> data fork in rt ino 135 claims dup rt extent,off - 0, start - 13062144, count 2097000<br>
> bad data fork in inode 135<br>
> would have cleared inode 135<br>
> No modify flag set, skipping phase 5<br>
> ------------------------<br>
><br>
> Here is the bmap for both inodes.<br>
><br>
> xfs_db> inode 135<br>
> xfs_db> bmap<br>
> data offset 0 startblock 13062144 (12/479232) count 2097000 flag 0<br>
> data offset 2097000 startblock 15159144 (14/479080) count 2097000 flag 0<br>
> data offset 4194000 startblock 17256144 (16/478928) count 2097000 flag 0<br>
> data offset 6291000 startblock 19353144 (18/478776) count 2097000 flag 0<br>
> data offset 8388000 startblock 21450144 (20/478624) count 2097000 flag 0<br>
> data offset 10485000 startblock 23547144 (22/478472) count 2097000 flag 0<br>
> data offset 12582000 startblock 25644144 (24/478320) count 2097000 flag 0<br>
> data offset 14679000 startblock 27741144 (26/478168) count 2097000 flag 0<br>
> data offset 16776000 startblock 29838144 (28/478016) count 2097000 flag 0<br>
> data offset 18873000 startblock 31935144 (30/477864) count 1607000 flag 0<br>
> xfs_db> inode 134<br>
> xfs_db> bmap<br>
> data offset 0 startblock 7942144 (7/602112) count 2097000 flag 0<br>
> data offset 2097000 startblock 10039144 (9/601960) count 2097000 flag 0<br>
> data offset 4194000 startblock 12136144 (11/601808) count 926000 flag 0<br>
<br>
</div></div>It's been a while since I thought about realtime, but -<br>
<br>
That all seems fine, I don't see anything overlapping there, they are<br>
all perfectly adjacent, though of interesting size.<br>
<div class="im"><br>
><br>
> by looking into xfs_repair code, it looks like repair does not handle<br>
> a case where we have more than one extent in a real-time extent.<br>
> following is code from repair/dinode.c: process_rt_rec<br>
<br>
</div>"more than one extent in a real-time extent?" I'm not sure what that means.<br>
<br>
Every extent above is length 2097000 blocks, and they are adjacent.<br>
But you say your realtime extent size is 512 blocks ... which doesn't go<br>
into 2097000 evenly. So that's odd, at least.<br>
<br></blockquote><div><br>well, lets look at first extent<br>> data offset 0 startblock 13062144 (12/479232) count 2097000 flag 0<br>
> data offset 2097000 startblock 15159144 (14/479080) count 2097000 flag 0<br>startblock is aligned and rtext is 25512, since the blockcount is not multiple of 512, last realtime extent ( 25512 + 4095) is partially used, 360 blks<br>
second extent start from realtime extent 29607 (ie 25512 + 4095). so, yes, extents are not overlapping, but 29607 realtime extent is shared by two extents.<br>Now once xfs_repair detects this case in phase 2, it bails out and clears that inode. I think search for duplicate extent is done in phase 4, but inode is marked already. <br>
<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you provide your xfs_info output for this fs?<br>
Or maybe better yet an xfs_metadump image.<br>
<div class="im"><br></div></blockquote><div><br>I will do it soon. The other thing I noticed is if I try to delete this file (inode 135), I get following assertion failure. <br><br>[75669.291000] Assertion failed: prev.br_state == XFS_EXT_NORM, file: fs/xfs/xfs_bmap.c, line: 5187 <br>
[75669.300000] [<8024dc44>] assfail+0x28/0x2c <br>[75669.300000] [<801d8864>] xfs_bunmapi+0x1288/0x14e4 <br>
[75669.300000] [<8020aff4>] xfs_itruncate_finish+0x344/0x738 <br>[75669.300000] [<802363b0>] xfs_inactive+0x4a8/0x51c <br>
[75669.300000] [<80109124>] evict+0x28/0xd0 <br>[75669.300000] [<80109c14>] iput+0x19c/0x2d8 <br>
[75669.300000] [<800fe58c>] do_unlinkat+0x10c/0x19c <br>[75669.300000] [<80011b7c>] stack_done+0x20/0x40 <br>
<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> -----<br>
> for (b = irec->br_startblock; b < irec->br_startblock +<br>
> irec->br_blockcount; b += mp->m_sb.sb_rextsize) {<br>
> ext = (xfs_drtbno_t) b / mp->m_sb.sb_rextsize;<br>
> pwe = xfs_sb_version_hasextflgbit(&mp->m_sb) &&<br>
> irec->br_state == XFS_EXT_UNWRITTEN &&<br>
> (b % mp->m_sb.sb_rextsize != 0);<br>
> -----<br>
><br>
> In my case rextsize is 512 (512 * 4096 = 2mb). So we have multiple<br>
> extents (written extents to be precise, thanks dchinner for that),<br>
> value of "ext" will be same for all of them and xfs_repair does not<br>
> like it. thus the error message ""data fork in rt inode XX claims<br>
> used rt block XX".<br>
<br>
</div>"ext" should not be the same for all of them; ext is the realtime extent<br>
number in the fs, based on the physical start, br_startblock,<br>
divided by the rt extent size. There shouldn't be duplicate values<br>
of "ext" based on the bmaps above.<br>
<br>
The error comes from search_rt_dup_extent() which looks for overlaps<br>
elsewhere in the fs...<br>
<br>
If you can provide a metadump of the fs it might be easier to see what's going on.<br>
<br>
-Eric<br>
<div class="im"><br>
> If I ignore this failure condition, xfs_repairs seems to be happy.<br>
> (FYI: this file-system is cleanly umounted) But in my opinion, its<br>
> not good as these multiple extents can overlap too.<br>
<br>
> Should we be using XR_E_MULT to flag and keep track of duplicated<br>
> real-time extents. (maybe use the present API for adding/detecting<br>
> duplicate extents)<br>
><br>
> I am open of suggestion or comments on how to fix this.<br>
><br>
> xfs_repair version is 3.1.8 and kernel 2.6.37.<br>
><br>
> thanks,<br>
> Anand<br>
><br>
><br>
><br>
</div>> _______________________________________________<br>
> xfs mailing list<br>
> <a href="mailto:xfs@oss.sgi.com">xfs@oss.sgi.com</a><br>
> <a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_blank">http://oss.sgi.com/mailman/listinfo/xfs</a><br>
><br>
<br>
</blockquote></div><br>