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

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

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 1830 bytes --]

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.


# 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

[-- Attachment #1.2: Type: text/html, Size: 2118 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

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@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@sandeen.net>
    Signed-off-by: Tim Shimmin <tes@sgi.com>
    Signed-off-by: Lachlan McIlroy <lachlan@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
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 4442 bytes --]

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@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@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@sandeen.net>
>    Signed-off-by: Tim Shimmin <tes@sgi.com>
>    Signed-off-by: Lachlan McIlroy <lachlan@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
> >
>
>

[-- Attachment #1.2: Type: text/html, Size: 5515 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

Amit Sahrawat wrote:
> 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.


http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ae23a5e87dbbf4657a82e1ff8ebc52ab50361c14

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 3989 bytes --]

Hi Eric,

This seems related with the directory Inodes.

I tried the changes mentioned in the patch, they didn't work for me.
As mine seems to be ARM with EABI.

When files are created at the Root . It reports Root Inode :128 at the crash
with bno:2

While suppose if another directory is created and Inode is 137
And then, rm -rf * in that directory
Crash would report error With this inode

xfs_da_do_buf: bno 8388631
dir: inode 137
Filesystem "sda4": XFS internal error xfs_da_do_buf(1) at line 1992 of file
fs/x
fs/xfs_da_btree.c.  Caller 0xc0118eb8
ry
rm: unable [<c0022618>] (dump_stack+0x0/0x14) from [<c0125700>]
(xfs_error_repor
t+0x54/0x64)
[<c01256ac>] (xfs_error_report+0x0/0x64) from [<c0118a74>]
(xfs_da_do_buf+0x334/
0x6ec)
[<c0118740>] (xfs_da_do_buf+0x0/0x6ec) from [<c0118eb8>]
(xfs_da_read_buf+0x34/0
x3c)
[<c0118e84>] (xfs_da_read_buf+0x0/0x3c) from [<c011b5c8>]
(xfs_da_node_lookup_in
t+0x70/0x318)
[<c011b558>] (xfs_da_node_lookup_int+0x0/0x318) from [<c01219d4>]
(xfs_dir2_node
_removename+0x48/0x500)
[<c012198c>] (xfs_dir2_node_removename+0x0/0x500) from [<c011c334>]
(xfs_dir_rem
ovename+0x100/0x10c)
[<c011c234>] (xfs_dir_removename+0x0/0x10c) from [<c014cde4>]
(xfs_remove+0x280/
0x424)
 r6 = 00000000  r5 = 00000000  r4 = 00003951
[<c014cb64>] (xfs_remove+0x0/0x424) from [<c0157044>]
(xfs_vn_unlink+0x30/0x60)
[<c0157014>] (xfs_vn_unlink+0x0/0x60) from [<c009175c>]
(vfs_unlink+0x70/0xac)
 r7 = C471C000  r6 = C43BF598  r5 = C395B3B8  r4 = 00000000
[<c00916ec>] (vfs_unlink+0x0/0xac) from [<c0093ac0>]
(do_unlinkat+0xcc/0x14c)
 r6 = C3968AD8  r5 = C395B3B8  r4 = 00000000
[<c00939f4>] (do_unlinkat+0x0/0x14c) from [<c0093b58>]
(sys_unlink+0x18/0x1c)
 r7 = 0000000A  r6 = 0000000C  r5 = 00000008  r4 = BEDCBC19
[<c0093b40>] (sys_unlink+0x0/0x1c) from [<c001de40>]
(ret_fast_syscall+0x0/0x2c)
to remove `5826'xfs_da_do_buf: bno 8388631
dir: inode 137

Checking this through xfs_check will show:
]# xfs_check /dev/sdb4
dir 128 block 8388609 extra leaf entry d5830 402
dir 128 block 8388609 extra leaf entry d5831 404
dir 128 block 8388609 extra leaf entry d5832 406
dir 128 block 8388609 extra leaf entry d5833 408
dir 128 block 8388609 extra leaf entry d5834 40a
dir 128 block 8388609 extra leaf entry d5835 40c
dir 128 block 8388609 extra leaf entry d5836 40e
dir 128 block 8388609 extra leaf entry d5837 410
...
...
dir 128 block 8388609 extra leaf entry ddab2 5fa
dir 128 block 8388609 extra leaf entry ddab3 5fc
dir 128 block 8388609 extra leaf entry ddab4 5fe
bad free block ent 1 is 65535 should be 0 for dir ino 128 block 16777216
bad free block ent 2 is 0 should be 65535 for dir ino 128 block 16777216
dir ino 128 missing leaf entry for d5a37/260
dir ino 128 missing leaf entry for d5a38/262
dir ino 128 missing leaf entry for d5a39/264
...
...

I tried checking the inode before and after corruption using xfs_db and
xfs_check
When I create files and check using xfs_check, no corruption is showed and
also xfs_db shows correct results for the inode.
While after the crash is observed, xfs_check show the errors I mentioned
above.
Also, the values for Inode using xfs_db differ from the ones I get after i
do xfs_repair -L on the device.


Can u get anything from the above mentioned log.

Thanks & Regards,
Amit Sahrawat


On Wed, Oct 21, 2009 at 11:14 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

> Amit Sahrawat wrote:
> > 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.
>
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ae23a5e87dbbf4657a82e1ff8ebc52ab50361c14
>
> -Eric
>
>

[-- Attachment #1.2: Type: text/html, Size: 4982 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

Amit Sahrawat wrote:
> Hi Eric,
> 
> This seems related with the directory Inodes.
> 
> I tried the changes mentioned in the patch, they didn't work for me.
> As mine seems to be ARM with EABI.

The other one you might check on is:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=94a3f78566ef98a48814d82892f28bb741624cb8

Other than that, if you can try a newer kernel that'd be great, and if 
the problem remains, let me know what the testcase is and I can try it out.

-Eric

> When files are created at the Root . It reports Root Inode :128 at the 
> crash with bno:2
> 
> While suppose if another directory is created and Inode is 137
> And then, rm -rf * in that directory
> Crash would report error With this inode
> 
> xfs_da_do_buf: bno 8388631
> dir: inode 137
> Filesystem "sda4": XFS internal error xfs_da_do_buf(1) at line 1992 of 
> file fs/x
> fs/xfs_da_btree.c.  Caller 0xc0118eb8
> ry
> rm: unable [<c0022618>] (dump_stack+0x0/0x14) from [<c0125700>] 
> (xfs_error_repor
> t+0x54/0x64)
> [<c01256ac>] (xfs_error_report+0x0/0x64) from [<c0118a74>] 
> (xfs_da_do_buf+0x334/
> 0x6ec)
> [<c0118740>] (xfs_da_do_buf+0x0/0x6ec) from [<c0118eb8>] 
> (xfs_da_read_buf+0x34/0
> x3c)
> [<c0118e84>] (xfs_da_read_buf+0x0/0x3c) from [<c011b5c8>] 
> (xfs_da_node_lookup_in
> t+0x70/0x318)
> [<c011b558>] (xfs_da_node_lookup_int+0x0/0x318) from [<c01219d4>] 
> (xfs_dir2_node
> _removename+0x48/0x500)
> [<c012198c>] (xfs_dir2_node_removename+0x0/0x500) from [<c011c334>] 
> (xfs_dir_rem
> ovename+0x100/0x10c)
> [<c011c234>] (xfs_dir_removename+0x0/0x10c) from [<c014cde4>] 
> (xfs_remove+0x280/
> 0x424)
>  r6 = 00000000  r5 = 00000000  r4 = 00003951
> [<c014cb64>] (xfs_remove+0x0/0x424) from [<c0157044>] 
> (xfs_vn_unlink+0x30/0x60)
> [<c0157014>] (xfs_vn_unlink+0x0/0x60) from [<c009175c>] 
> (vfs_unlink+0x70/0xac)
>  r7 = C471C000  r6 = C43BF598  r5 = C395B3B8  r4 = 00000000
> [<c00916ec>] (vfs_unlink+0x0/0xac) from [<c0093ac0>] 
> (do_unlinkat+0xcc/0x14c)
>  r6 = C3968AD8  r5 = C395B3B8  r4 = 00000000
> [<c00939f4>] (do_unlinkat+0x0/0x14c) from [<c0093b58>] 
> (sys_unlink+0x18/0x1c)
>  r7 = 0000000A  r6 = 0000000C  r5 = 00000008  r4 = BEDCBC19
> [<c0093b40>] (sys_unlink+0x0/0x1c) from [<c001de40>] 
> (ret_fast_syscall+0x0/0x2c)
> to remove `5826'xfs_da_do_buf: bno 8388631
> dir: inode 137
> 
> Checking this through xfs_check will show:
> ]# xfs_check /dev/sdb4
> dir 128 block 8388609 extra leaf entry d5830 402
> dir 128 block 8388609 extra leaf entry d5831 404
> dir 128 block 8388609 extra leaf entry d5832 406
> dir 128 block 8388609 extra leaf entry d5833 408
> dir 128 block 8388609 extra leaf entry d5834 40a
> dir 128 block 8388609 extra leaf entry d5835 40c
> dir 128 block 8388609 extra leaf entry d5836 40e
> dir 128 block 8388609 extra leaf entry d5837 410
> ...
> ...
> dir 128 block 8388609 extra leaf entry ddab2 5fa
> dir 128 block 8388609 extra leaf entry ddab3 5fc
> dir 128 block 8388609 extra leaf entry ddab4 5fe
> bad free block ent 1 is 65535 should be 0 for dir ino 128 block 16777216
> bad free block ent 2 is 0 should be 65535 for dir ino 128 block 16777216
> dir ino 128 missing leaf entry for d5a37/260
> dir ino 128 missing leaf entry for d5a38/262
> dir ino 128 missing leaf entry for d5a39/264
> ...
> ...
> 
> I tried checking the inode before and after corruption using xfs_db and 
> xfs_check
> When I create files and check using xfs_check, no corruption is showed 
> and also xfs_db shows correct results for the inode.
> While after the crash is observed, xfs_check show the errors I mentioned 
> above.
> Also, the values for Inode using xfs_db differ from the ones I get after 
> i do xfs_repair -L on the device.
> 
> 
> Can u get anything from the above mentioned log.
> 
> Thanks & Regards,
> Amit Sahrawat
> 
> 
> On Wed, Oct 21, 2009 at 11:14 PM, Eric Sandeen <sandeen@sandeen.net 
> <mailto:sandeen@sandeen.net>> wrote:
> 
>     Amit Sahrawat wrote:
>      > 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.
> 
> 
>     http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ae23a5e87dbbf4657a82e1ff8ebc52ab50361c14
> 
>     -Eric
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 5323 bytes --]

I am already using that patch.
Other than using higher XFS version, can I try any other thing?

I cannot directly use higher XFS version, I will have to backport the
changes for higher to the kernel I am using  because of dependencies.

Thanks & Regards,
Amit Sahrawat
On Thu, Oct 22, 2009 at 7:56 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

> Amit Sahrawat wrote:
>
>> Hi Eric,
>>
>> This seems related with the directory Inodes.
>>
>> I tried the changes mentioned in the patch, they didn't work for me.
>> As mine seems to be ARM with EABI.
>>
>
> The other one you might check on is:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=94a3f78566ef98a48814d82892f28bb741624cb8
>
> Other than that, if you can try a newer kernel that'd be great, and if the
> problem remains, let me know what the testcase is and I can try it out.
>
> -Eric
>
>   When files are created at the Root . It reports Root Inode :128 at the
>> crash with bno:2
>>
>> While suppose if another directory is created and Inode is 137
>> And then, rm -rf * in that directory
>> Crash would report error With this inode
>>
>> xfs_da_do_buf: bno 8388631
>> dir: inode 137
>> Filesystem "sda4": XFS internal error xfs_da_do_buf(1) at line 1992 of
>> file fs/x
>> fs/xfs_da_btree.c.  Caller 0xc0118eb8
>> ry
>> rm: unable [<c0022618>] (dump_stack+0x0/0x14) from [<c0125700>]
>> (xfs_error_repor
>> t+0x54/0x64)
>> [<c01256ac>] (xfs_error_report+0x0/0x64) from [<c0118a74>]
>> (xfs_da_do_buf+0x334/
>> 0x6ec)
>> [<c0118740>] (xfs_da_do_buf+0x0/0x6ec) from [<c0118eb8>]
>> (xfs_da_read_buf+0x34/0
>> x3c)
>> [<c0118e84>] (xfs_da_read_buf+0x0/0x3c) from [<c011b5c8>]
>> (xfs_da_node_lookup_in
>> t+0x70/0x318)
>> [<c011b558>] (xfs_da_node_lookup_int+0x0/0x318) from [<c01219d4>]
>> (xfs_dir2_node
>> _removename+0x48/0x500)
>> [<c012198c>] (xfs_dir2_node_removename+0x0/0x500) from [<c011c334>]
>> (xfs_dir_rem
>> ovename+0x100/0x10c)
>> [<c011c234>] (xfs_dir_removename+0x0/0x10c) from [<c014cde4>]
>> (xfs_remove+0x280/
>> 0x424)
>>  r6 = 00000000  r5 = 00000000  r4 = 00003951
>> [<c014cb64>] (xfs_remove+0x0/0x424) from [<c0157044>]
>> (xfs_vn_unlink+0x30/0x60)
>> [<c0157014>] (xfs_vn_unlink+0x0/0x60) from [<c009175c>]
>> (vfs_unlink+0x70/0xac)
>>  r7 = C471C000  r6 = C43BF598  r5 = C395B3B8  r4 = 00000000
>> [<c00916ec>] (vfs_unlink+0x0/0xac) from [<c0093ac0>]
>> (do_unlinkat+0xcc/0x14c)
>>  r6 = C3968AD8  r5 = C395B3B8  r4 = 00000000
>> [<c00939f4>] (do_unlinkat+0x0/0x14c) from [<c0093b58>]
>> (sys_unlink+0x18/0x1c)
>>  r7 = 0000000A  r6 = 0000000C  r5 = 00000008  r4 = BEDCBC19
>> [<c0093b40>] (sys_unlink+0x0/0x1c) from [<c001de40>]
>> (ret_fast_syscall+0x0/0x2c)
>> to remove `5826'xfs_da_do_buf: bno 8388631
>> dir: inode 137
>>
>> Checking this through xfs_check will show:
>> ]# xfs_check /dev/sdb4
>> dir 128 block 8388609 extra leaf entry d5830 402
>> dir 128 block 8388609 extra leaf entry d5831 404
>> dir 128 block 8388609 extra leaf entry d5832 406
>> dir 128 block 8388609 extra leaf entry d5833 408
>> dir 128 block 8388609 extra leaf entry d5834 40a
>> dir 128 block 8388609 extra leaf entry d5835 40c
>> dir 128 block 8388609 extra leaf entry d5836 40e
>> dir 128 block 8388609 extra leaf entry d5837 410
>> ...
>> ...
>> dir 128 block 8388609 extra leaf entry ddab2 5fa
>> dir 128 block 8388609 extra leaf entry ddab3 5fc
>> dir 128 block 8388609 extra leaf entry ddab4 5fe
>> bad free block ent 1 is 65535 should be 0 for dir ino 128 block 16777216
>> bad free block ent 2 is 0 should be 65535 for dir ino 128 block 16777216
>> dir ino 128 missing leaf entry for d5a37/260
>> dir ino 128 missing leaf entry for d5a38/262
>> dir ino 128 missing leaf entry for d5a39/264
>> ...
>> ...
>>
>> I tried checking the inode before and after corruption using xfs_db and
>> xfs_check
>> When I create files and check using xfs_check, no corruption is showed and
>> also xfs_db shows correct results for the inode.
>> While after the crash is observed, xfs_check show the errors I mentioned
>> above.
>> Also, the values for Inode using xfs_db differ from the ones I get after i
>> do xfs_repair -L on the device.
>>
>>
>> Can u get anything from the above mentioned log.
>>
>> Thanks & Regards,
>> Amit Sahrawat
>>
>>
>> On Wed, Oct 21, 2009 at 11:14 PM, Eric Sandeen <sandeen@sandeen.net<mailto:
>> sandeen@sandeen.net>> wrote:
>>
>>    Amit Sahrawat wrote:
>>     > 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.
>>
>>
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ae23a5e87dbbf4657a82e1ff8ebc52ab50361c14
>>
>>    -Eric
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 6773 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

Amit Sahrawat wrote:
> I am already using that patch.
> Other than using higher XFS version, can I try any other thing?
>  
> I cannot directly use higher XFS version, I will have to backport the
> changes for higher to the kernel I am using  because of dependencies.
> 

backporting xfs would be hard; I was hoping that perhaps you could just
boot a newer kernel, though I know w/ vendor arm kernels that can be tough.

There are drawbacks to not getting machine support upstream... :)

I don't really have other things for you to try, and don't have a lot of
time to debug 3 year old kernels either...  :(

You could try your arm testcase in a qemu emulator on a new kernel; if
that shows the same problem I'll be much more interested & motivated...

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 1172 bytes --]

that means it highely unlikey to get a fix for this issue :(

Yes, backporting just doest not suits for me.

I am trying to dig into the code, but really dont know if that's going to be
that easy.

Thanks Eric for all the help.
W'll you know if I am able to fix this.

Thanks & Regards,
Amit Sahrawat

On Thu, Oct 22, 2009 at 10:10 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

> Amit Sahrawat wrote:
> > I am already using that patch.
> > Other than using higher XFS version, can I try any other thing?
> >
> > I cannot directly use higher XFS version, I will have to backport the
> > changes for higher to the kernel I am using  because of dependencies.
> >
>
> backporting xfs would be hard; I was hoping that perhaps you could just
> boot a newer kernel, though I know w/ vendor arm kernels that can be tough.
>
> There are drawbacks to not getting machine support upstream... :)
>
> I don't really have other things for you to try, and don't have a lot of
> time to debug 3 year old kernels either...  :(
>
> You could try your arm testcase in a qemu emulator on a new kernel; if
> that shows the same problem I'll be much more interested & motivated...
>
> -Eric
>

[-- Attachment #1.2: Type: text/html, Size: 1682 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

Amit Sahrawat wrote:
> that means it highely unlikey to get a fix for this issue :(
>  
> Yes, backporting just doest not suits for me.
>  
> I am trying to dig into the code, but really dont know if that's going 
> to be that easy.
>  
> Thanks Eric for all the help.
> W'll you know if I am able to fix this.

One other thought on the backporting side; RHEL5.4 now has xfs merged 
into a 2.6.18-ish kernel.  There are still some other supporting bits in 
that kernel, it's hardly vanilla 2.6.18, but if you want to try a 
backport route it might be one option.

Testing an upstream kernel w/ your testcase in an emulator would also be 
a reasonable thing to do, I think.

-eric

> Thanks & Regards,
> Amit Sahrawat
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Amit Sahrawat]

[-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --]

Hi Eric,

Can this issue be related to some timing issue/synchronization with disk?
Test case is something like this..

I create thousands of files... (simply keep touching to create '0' bytes
files from a shell script) and in between I do Ctrl + C, to stop.
Then, I issue command to remove files (rm -rf *) and crash appears.

Thanks & Regards,
Amit Sahrawat

On Fri, Oct 23, 2009 at 8:07 AM, Eric Sandeen <sandeen@sandeen.net> wrote:

> Amit Sahrawat wrote:
>
>> that means it highely unlikey to get a fix for this issue :(
>>  Yes, backporting just doest not suits for me.
>>  I am trying to dig into the code, but really dont know if that's going to
>> be that easy.
>>  Thanks Eric for all the help.
>> W'll you know if I am able to fix this.
>>
>
> One other thought on the backporting side; RHEL5.4 now has xfs merged into
> a 2.6.18-ish kernel.  There are still some other supporting bits in that
> kernel, it's hardly vanilla 2.6.18, but if you want to try a backport route
> it might be one option.
>
> Testing an upstream kernel w/ your testcase in an emulator would also be a
> reasonable thing to do, I think.
>
> -eric
>
> Thanks & Regards,
>> Amit Sahrawat
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 1856 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

Amit Sahrawat wrote:
> Hi Eric,
>  
> Can this issue be related to some timing issue/synchronization with disk?
> Test case is something like this..
>  
> I create thousands of files... (simply keep touching to create '0' bytes 
> files from a shell script) and in between I do Ctrl + C, to stop.
> Then, I issue command to remove files (rm -rf *) and crash appears. 
>  
> Thanks & Regards,
> Amit Sahrawat
> 

Whatever it is, I think it must be arch-dependent, I don't think such a 
thing would fail on x86 - I kind of doubt that it's timing, but it's 
hard to say.

Have you tested in an emulator yet?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs