Our test case is automated:<br>1. Create large number of file of 6KB sizes ( 6KB is taken, we wanted to increase journal load, and file size not in multiple of file system block size) <br>2. Set target to reboot at random seconds seconds.<br>
3. Next boot do "ls" of all files in XFS partition.<br>4. Remove all files in XFS.<br>5. Go back to step 1<br><br>The purpose of this test is to test journal and stability of XFS filestem.<br><br>Do you think, we should consider this test case ?<br>
<br>Other is when we should run xfs_repair ? because if mount fails and journal contain dirty logs then xfs_repair does not run, we are forced to use (-L) option but its description say that (-L) can corrupt the file system.<br>
<br>Other case even if xfs mount successfully, even in that case accessing some files give IO input/ output error.<br><br>1. I recommend the following usage for xfs_repair so that we do not come accross these problem<br> Mount Success -> Umount -> run xfs_repair -> mount<br>
Mount fails -> try xfs_repair -> xfs_repair fails -> finally xfs_repair -L -> mount<br><br>Adding above mount + xfs_repair procedure to script makes file system stable. But other member of my team do not agree as it increases mount time.<br>
<br> <br><br><div class="gmail_quote">On Fri, Dec 3, 2010 at 4:15 AM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5">On Thu, Dec 02, 2010 at 12:31:30PM +0530, Ajeet Yadav wrote:<br>
> Dear all,<br>
> This is XFS fail mount log on linux 2.6.30.9<br>
><br>
> XFS mounting filesystem sda2<br>
> Starting XFS recovery on filesystem: sda2 (logdev: internal)<br>
> XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file<br>
> fs/xfs/xfs_alloc.c. Caller 0x80129658<br>
> Call Trace:<br>
> [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>]<br>
> xfs_free_ag_extent+0x128/0x7ac<br>
> [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>]<br>
> xfs_free_extent+0xb8/0xe8<br>
> [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>]<br>
> xlog_recover_process_efi+0x160/0x214<br>
> [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4>]<br>
> xlog_recover_process_efis+0x98/0x11c<br>
> [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<8016663c>]<br>
> xlog_recover_finish+0x28/0xdc<br>
> [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>]<br>
> xfs_mountfs+0x4d0/0x610<br>
> [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>]<br>
> xfs_fs_fill_super+0x1fc/0x418<br>
> [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>]<br>
> get_sb_bdev+0x11c/0x1c0<br>
> [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>]<br>
> xfs_fs_get_sb+0x20/0x2c<br>
> [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>]<br>
> vfs_kern_mount+0x68/0xd0<br>
> [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>]<br>
> do_kern_mount+0x54/0x118<br>
> [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_mount+0x7b4/0x828<br>
> [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mount+0x9c/0x194<br>
> [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_done+0x20/0x3c<br>
><br>
> Failed to recover EFIs on filesystem: sda2<br>
> XFS: log mount finish failed<br>
<br>
</div></div>You corrupted a free space btree. Care to tell uswhat test you were<br>
running that caused this? Did you pull the plug on the device<br>
during a copy again?<br>
<br>
Cheers,<br>
<br>
Dave.<br>
<font color="#888888">--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</font></blockquote></div><br>