<br><br><div class="gmail_quote">On Mon, Sep 24, 2012 at 1:55 AM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Sep 21, 2012 at 12:00:13AM -0500, Eric Sandeen wrote:<br>
> 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>
</div>.....<br>
<div class="im">> > 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>
> 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>
<br>
</div>Yeah, the size is the problem.<br>
<br>
....<br>
<div class="im">> 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>
</div>Once you realise that the bmapbt is recording multiples of FSB (4k)<br>
rather than rtextsz (2MB), it becomes more obvious what the problem<br>
is: rounding of the extent size at MAXEXTLEN - 2097000 is only 152<br>
blocks short of 2^21 (2097152).<br>
<br>
I haven't looked at the kernel code yet to work out why it is<br>
rounding to a non-rtextsz multiple, but that is the source of the<br>
problem.<br>
<br>
The repair code is detecting that extents are not of the<br>
correct granularity, but the error message indicates that this was<br>
only ever expected for duplicate blocks occurring rather than a<br>
kernel bug. So "fixing repair" is not what is needd here - finding<br>
and fixing the kernel bug is what you shoul be looking at.<br>
<br>
Cheers,<br>
<br>
Dave.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</font></span></blockquote></div><br><div><br></div><div>thanks, I started looking at allocator code and and will report if see something </div>