public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c
Date: Wed, 08 Dec 2010 21:51:22 -0600	[thread overview]
Message-ID: <4D00523A.9020703@sandeen.net> (raw)
In-Reply-To: <AANLkTimZt7vefTvg2XkzgUHjD3s8JD3dHLX_qbXpXrra@mail.gmail.com>

On 12/3/10 10:19 PM, Ajeet Yadav wrote:
> Our test case is automated:
> 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)
> 2. Set target to reboot at random seconds seconds.

What exactly is meant by "reboot?"

Does this mean "cycle power" or cleanly reboot?

Based on the problems you are encountering, I am guessing that
you drop power.

Is the storage external for this test?  Is it qualified hardware
or are you planning on supporting anything that the user may choose
to plug into their device?

It's possible that an external USB device is behaving poorly,
and that may be the root of your problems.

-Eric

> 3. Next boot do "ls" of all files in XFS partition.
> 4. Remove all files in XFS.
> 5. Go back to step 1
> 
> The purpose of this test is to test journal and stability of XFS filestem.
> 
> Do you think, we should consider this test case ?
> 
> 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.
> 
> Other case even if xfs mount successfully, even in that case accessing some files give IO input/ output error.
> 
> 1. I recommend the following usage for xfs_repair so that we do not come accross these problem
>     Mount Success -> Umount -> run xfs_repair -> mount
>     Mount fails -> try xfs_repair -> xfs_repair fails -> finally xfs_repair -L -> mount
> 
> 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.
> 
>                                               
> 
> On Fri, Dec 3, 2010 at 4:15 AM, Dave Chinner <david@fromorbit.com <mailto:david@fromorbit.com>> wrote:
> 
>     On Thu, Dec 02, 2010 at 12:31:30PM +0530, Ajeet Yadav wrote:
>     > Dear all,
>     > This is XFS fail mount log on linux 2.6.30.9
>     >
>     > XFS mounting filesystem sda2
>     > Starting XFS recovery on filesystem: sda2 (logdev: internal)
>     > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file
>     > fs/xfs/xfs_alloc.c.  Caller 0x80129658
>     > Call Trace:
>     > [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>]
>     > xfs_free_ag_extent+0x128/0x7ac
>     > [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>]
>     > xfs_free_extent+0xb8/0xe8
>     > [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>]
>     > xlog_recover_process_efi+0x160/0x214
>     > [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4>]
>     > xlog_recover_process_efis+0x98/0x11c
>     > [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<8016663c>]
>     > xlog_recover_finish+0x28/0xdc
>     > [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>]
>     > xfs_mountfs+0x4d0/0x610
>     > [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>]
>     > xfs_fs_fill_super+0x1fc/0x418
>     > [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>]
>     > get_sb_bdev+0x11c/0x1c0
>     > [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>]
>     > xfs_fs_get_sb+0x20/0x2c
>     > [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>]
>     > vfs_kern_mount+0x68/0xd0
>     > [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>]
>     > do_kern_mount+0x54/0x118
>     > [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_mount+0x7b4/0x828
>     > [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mount+0x9c/0x194
>     > [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_done+0x20/0x3c
>     >
>     > Failed to recover EFIs on filesystem: sda2
>     > XFS: log mount finish failed
> 
>     You corrupted a free space btree. Care to tell uswhat test you were
>     running that caused this?  Did you pull the plug on the device
>     during a copy again?
> 
>     Cheers,
> 
>     Dave.
>     --
>     Dave Chinner
>     david@fromorbit.com <mailto:david@fromorbit.com>
> 
> 
> 
> 
> _______________________________________________
> 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

      parent reply	other threads:[~2010-12-09  3:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-02  7:01 XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Ajeet Yadav
2010-12-02 22:45 ` Dave Chinner
2010-12-04  4:19   ` Ajeet Yadav
2010-12-07 11:20     ` Dave Chinner
2010-12-09  3:51     ` Eric Sandeen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D00523A.9020703@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=ajeet.yadav.77@gmail.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox