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