XFS internal error xfs_da_do_buf(1) at line 1992 of file fs/xfs/xfs_da_btree.c

[Amit Sahrawat]

Thanks Eric,

Yes, I am able to get this for the same Inode and Block number.

xfs_check reports error for dir inode 128 missing leaf entries..(exact
string I m missing), will provide you the details.

Using xfs_repair fixes the problem. But again the same operation leads to
the crash.
Even on a freshly formatted disk, I get this error.

Please let me know from where I can get this patch to try whether it fixes
for me or not.

Thanks & Regards,
Amit Sahrawat

On Wed, Oct 21, 2009 at 9:25 PM, Eric Sandeen <sandeen at sandeen.net> wrote:

> Amit Sahrawat wrote:
> > Dear Eric,
> >
> >
> > I am facing an issue with file deletion in XFS. Every time, I perform a
> > remove operation the kernel crashes with the following prints.
> >
>
> Old kernel I'm afraid.  Which ABI are you using?
>
> I'd have to remind what's gone in since then, but at least this:
>
> commit ae23a5e87dbbf4657a82e1ff8ebc52ab50361c14
> Author: Eric Sandeen <sandeen at sandeen.net>
> Date:   Mon Jun 23 13:23:32 2008 +1000
>
>    [XFS] Pack some shortform dir2 structures for the ARM old ABI
>    architecture.
>
>    This should fix the longstanding issues with xfs and old ABI arm boxes,
>    which lead to various asserts and xfs shutdowns, and for which an
>    (incorrect) patch has been floating around for years.
>
>    I've verified this patch by comparing the on-disk structure layouts
> using
>    pahole from the dwarves package, as well as running through a bit of
> xfsqa
>    under qemu-arm, modified so that the check/repair phase after each test
>    actually executes check/repair from the x86 host, on the filesystem
>    populated by the arm emulator. Thus far it all looks good.
>
>    There are 2 other structures with extra padding at the end, but they
> don't
>    seem to cause trouble. I suppose they could be packed as well:
>    xfs_dir2_data_unused_t and xfs_dir2_sf_t.
>
>    Note that userspace needs a similar treatment, and any filesystems which
>    were running with the previous rogue "fix" will now see corruption
> (either
>    in the kernel, or during xfs_repair) with this fix properly in place; it
>    may be worth teaching xfs_repair to identify and fix that specific
> issue.
>
>    SGI-PV: 982930
>
>    SGI-Modid: xfs-linux-melb:xfs-kern:31280a
>
>    Signed-off-by: Eric Sandeen <sandeen at sandeen.net>
>    Signed-off-by: Tim Shimmin <tes at sgi.com>
>    Signed-off-by: Lachlan McIlroy <lachlan at sgi.com>
>
> comes to mind.
>
> But, do you always get an error on the same dir & block nr?  Does an
> xfs_repair fix it?  Maybe it's just plain ol' corruption.
>
> -Eric
>
> > # rm -rf 1* 2* 3* 4*
> > xfs_da_do_buf: bno 16777216
> > dir: inode 128
> > Filesystem "sda1": XFS internal error xfs_da_do_buf(1) at line 1992 of
> > file fs/xfs/xfs_da_btree.c.  Caller 0xc011d2e4
> > [<c0022618>] (dump_stack+0x0/0x14) from [<c0129b2c>]
> > (xfs_error_report+0x54/0x64)
> > [<c0129ad8>] (xfs_error_report+0x0/0x64) from [<c011cea0>]
> > (xfs_da_do_buf+0x334/0x6ec)
> > [<c011cb6c>] (xfs_da_do_buf+0x0/0x6ec) from [<c011d2e4>]
> > (xfs_da_read_buf+0x34/0x3c)
> > [<c011d2b0>] (xfs_da_read_buf+0x0/0x3c) from [<c0126030>]
> > (xfs_dir2_node_removename+0x278/0x500)
> > [<c0125db8>] (xfs_dir2_node_removename+0x0/0x500) from [<c0120760>]
> > (xfs_dir_removename+0x100/0x10c)
> > [<c0120660>] (xfs_dir_removename+0x0/0x10c) from [<c0151be0>]
> > (xfs_remove+0x280/0x424)
> >  r6 = 00000000  r5 = 00000000  r4 = 0000357C
> > [<c0151960>] (xfs_remove+0x0/0x424) from [<c015c3a0>]
> > (xfs_vn_unlink+0x30/0x60)
> > [<c015c370>] (xfs_vn_unlink+0x0/0x60) from [<c0091c58>]
> > (vfs_unlink+0x70/0xac)
> >  r7 = C3E79000  r6 = C3E5AE58  r5 = C4122EB8  r4 = 00000000
> > [<c0091be8>] (vfs_unlink+0x0/0xac) from [<c0093fbc>]
> > (do_unlinkat+0xcc/0x14c)
> >  r6 = C4123D78  r5 = C4122EB8  r4 = 00000000
> > [<c0093ef0>] (do_unlinkat+0x0/0x14c) from [<c0094054>]
> > (sys_unlink+0x18/0x1c)
> >  r7 = 0000000A  r6 = 0000000C  r5 = 00000008  r4 = BECE6A2B
> > [<c009403c>] (sys_unlink+0x0/0x1c) from [<c001de40>]
> > (ret_fast_syscall+0x0/0x2c)
> >
> > *I am using kernel version - 2.6.18.1
> > Platform - ARM
> > *
> > I have searched a lot on this issue, but no solution is available. In
> > the FAQS it is mentioned that it's been fixed 2.6.17.7 onwards.
> > But, i keep getting this issue frequently almost every time I do this
> > operation .
> >
> > Please provide me any help to sort this issue.
> >
> > Thanks & Regards,
> > Amit Sahrawat
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20091021/d5c9dcfe/attachment.htm>