<br><br><div class="gmail_quote">On Mon, Sep 24, 2012 at 6:51 AM, Anand Tiwari <span dir="ltr"><<a href="mailto:tiwarikanand@gmail.com" target="_blank">tiwarikanand@gmail.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="HOEnZb"><div class="h5"><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>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>> > 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>> 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><font color="#888888">--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a><br>
</font></span></blockquote></div><br><div><br></div></div></div><div>thanks, I started looking at allocator code and and will report if see something </div>
</blockquote></div><br><br>I think this is what happening. If we have following conditions,<br> 1) we have more than 8gb contiguous space available to allocate. ( i.e. more than 2^21 4k blocks)<br> 2) only one file is open for writing in real-time volume.<br>
<br>To satisfy first condition, I just took empty file-system.<br><br>Now lets start allocating, lets say in chucks of 25000, realtime allocator will have no problem allocating "exact" block while searching forward.<br>
xfs_rtfind_forw(). It will allocate 49 "real-time extents", where the 49th "real-time extent" is partially full. (25000/512 = 48)<br><br>everything is fine for first 83 allocations, as we were able to grow the extent. Now we have 2075000 (25000*83) blocks in first extent ie 4053 "real-time extents" (where last "real-time extent" is partially full).<br>
<br>for 84th allocation, real-time allocator will allocate another 49 "real-time extents" as it does not know about maximum extent size, but we can not grow the extent in xfs_bmap_add_extent_unwritten_real(). so we insert a new extent (case BMAP_LEFT_FILLING). now the new extent starts from 2075000, which is not aligned with rextsize (512 in this case).<br>
<br>To fix this, I see two options,<br>1) fix real-time allocator and teach it about maximum extent size.<br>2) for real-time files, aligned new extent before inserting.<br><br>In my opinion, we should not worry about either of above, as this looks good method for allocation. I can fix xfs_repair tool and make it aware of these conditions ("real-time extents" shared by two or more extents). <br>
<br>Let me know what you guys think, <br><br>anand<br><br>