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><br>by looking into xfs_repair code, it looks like repair does not handle 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>-----<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 extents (written extents to be precise, thanks dchinner for that), value of "ext" will be same for all of them and xfs_repair does not like it. thus the error message ""data fork in rt inode XX claims used rt block XX". <br>
<br>If I ignore this failure condition, xfs_repairs seems to be happy. (FYI: this file-system is cleanly umounted)<br>But in my opinion, its 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 real-time extents. (maybe use the present API for adding/detecting 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>