<div dir="ltr"><div><div><div>The XFS filesystem is only access by kvm guest, the objetive is store the backup's amanda that running in kvm host.<br><br></div>Now, i answer your questions:<br><br>* Have there been any other storage errors reported in the logs?, <br><br>ans: No, no information inside /var/log/messages , dmesg about xfs., can you suggest other log file for to find any information?<br><br>*  Is the problem reproducible or was it a one off occurrence?<br><br></div>ans: <span tabindex="-1" id="result_box" class="" lang="en"><span class="">It</span> <span class="">is only the</span> <span class="">first occurrence, and the server has a little use, because we are working yet for to complete the amanda backups, it isn't in production yet.<br><br></span></span></div><span tabindex="-1" id="result_box" class="" lang="en"><span class="">-Pablo<br></span></span><div><div><span tabindex="-1" id="result_box" class="" lang="en"><span class=""><br><br><br><br></span></span><div><br><br><br> <br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 11:58 AM, Brian Foster <span dir="ltr"><<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Feb 18, 2015 at 11:13:23AM -0300, Pablo Silva wrote:<br>
> Hi Brian!<br>
><br>
>  Thanks for your time!, i've just to run xfs_repair -n the result you can<br>
> see --> <a href="http://pastebin.centos.org/16106/" target="_blank">http://pastebin.centos.org/16106/</a> and as you can see there was<br>
> problems, but why this problems occurs?, we have xfs partition used for one<br>
> KVM where running Amanda with Centos 7, perhaps it was a bad configuration<br>
> inside KVM or perhaps a bug?, the host server is running centos 6<br>
><br>
<br>
</span>Can you elaborate? You have an isolated XFS filesystem that is accessed<br>
by the host system, the kvm guest, or both? How is the fs used?<br>
<br>
Also, can you answer my other questions related to how this occurred?<br>
Are there any other errors in the logs that precede the one below?<br>
<br>
I assume the fs shut down at the point of the error below. Has it been<br>
mounted since? If not, that might be worth a try to replay the log. If<br>
the log is dirty and replayed, that should be indicated by the output in<br>
the log at mount time. You'll also want to re-run xfs_repair -n in that<br>
case.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> [root@vtl ~]# uname -a<br>
> Linux vtl.areaprod.b2b 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36<br>
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux<br>
><br>
><br>
> But the KVM running centos 7<br>
><br>
> Linux amanda 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014<br>
> x86_64 x86_64 x86_64 GNU/Linux<br>
><br>
> The KVM config is this --> <a href="http://pastebin.centos.org/16111/" target="_blank">http://pastebin.centos.org/16111/</a><br>
><br>
> And /etc/fstab is this---> <a href="http://pastebin.centos.org/16116/" target="_blank">http://pastebin.centos.org/16116/</a><br>
><br>
><br>
> Thanks in advance, for any hint.<br>
><br>
> -Pablo<br>
><br>
><br>
> On Mon, Feb 16, 2015 at 11:10 AM, Brian Foster <<a href="mailto:bfoster@redhat.com">bfoster@redhat.com</a>> wrote:<br>
><br>
> > On Fri, Feb 13, 2015 at 03:44:57PM -0300, Pablo Silva wrote:<br>
> > > Hi !<br>
> > ><br>
> > >     We have a server with centos 6.6, kernel version:<br>
> > > 2.6.32-431.17.1.el6.x86_64, where we got the following message:<br>
> > ><br>
> > > Feb 12 19:22:15 vtl kernel:<br>
> > > Feb 12 19:22:15 vtl kernel: Pid: 3502, comm: touch Not tainted<br>
> > > 2.6.32-431.17.1.el6.x86_64 #1<br>
> > > Feb 12 19:22:15 vtl kernel: Call Trace:<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa041ae5f>] ?<br>
> > > xfs_error_report+0x3f/0x50 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa0422980>] ? xfs_ialloc+0x60/0x6e0<br>
> > [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa041ec2e>] ?<br>
> > xfs_dialloc+0x43e/0x850 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa0422980>] ? xfs_ialloc+0x60/0x6e0<br>
> > [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa044007a>] ?<br>
> > > kmem_zone_zalloc+0x3a/0x50 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa043b814>] ?<br>
> > > xfs_dir_ialloc+0x74/0x2b0 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa043d900>] ?<br>
> > xfs_create+0x440/0x640 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa044aa5d>] ?<br>
> > xfs_vn_mknod+0xad/0x1c0 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffffa044aba0>] ?<br>
> > xfs_vn_create+0x10/0x20 [xfs]<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffff81198086>] ? vfs_create+0xe6/0x110<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffff8119bb9e>] ?<br>
> > do_filp_open+0xa8e/0xd20<br>
> > > Feb 12 19:22:15 vtl kernel: [<ffffffff811a7ea2>] ? alloc_fd+0x92/0x160<br>
> > > Feb 12 19:22:15 vtl kernel: XFS: Internal error<br>
> > > XFS_WANT_CORRUPTED_GOTO at line 990 of file fs/xfs/xfs_ialloc.c.<br>
> > > Caller 0xffffffffa0422980<br>
> > ><br>
> ><br>
> >         /*<br>
> >          * None left in the last group, search the whole AG<br>
> >          */<br>
> >         error = xfs_inobt_lookup(cur, 0, XFS_LOOKUP_GE, &i);<br>
> >         if (error)<br>
> >                 goto error0;<br>
> >         XFS_WANT_CORRUPTED_GOTO(i == 1, error0);<br>
> ><br>
> >         for (;;) {<br>
> >                 error = xfs_inobt_get_rec(cur, &rec, &i);<br>
> >                 if (error)<br>
> >                         goto error0;<br>
> >                 XFS_WANT_CORRUPTED_GOTO(i == 1, error0);<br>
> >                 if (rec.ir_freecount > 0)<br>
> >                         break;<br>
> >                 error = xfs_btree_increment(cur, 0, &i);<br>
> >                 if (error)<br>
> >                         goto error0;<br>
> > --->            XFS_WANT_CORRUPTED_GOTO(i == 1, error0);<br>
> >         }<br>
> ><br>
> > That corresponds to the check above. This code is part of the inode<br>
> > allocator where we expect an AG to have free inodes and we're doing a<br>
> > brute force search for a record. Apparently we go off the AG or some<br>
> > other problem occurs before we find a free inode record.<br>
> ><br>
> > Does 'xfs_repair -n' report any problems with this fs? Have there been<br>
> > any other storage errors reported in the logs? Is the problem<br>
> > reproducible or was it a one off occurrence?<br>
> ><br>
> > Brian<br>
> ><br>
> > > I can't find more information for this..., perhaps a bug or other<br>
> > > thing ..., welcome any hint for to research..<br>
> > ><br>
> > > Thanks in advance!<br>
> > ><br>
> > > -Pablo<br>
> ><br>
> > > _______________________________________________<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>
</div></div></blockquote></div><br></div>