All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Amit Sahrawat <amit.sahrawat83@gmail.com>
Cc: sandeen-xfs@sandeen.net, xfs@oss.sgi.com
Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34
Date: Wed, 01 Dec 2010 21:56:55 -0600	[thread overview]
Message-ID: <4CF71907.60803@sandeen.net> (raw)
In-Reply-To: <AANLkTimiST8VNVsV49mniKLBudSxFj+O883Mwwe7ucac@mail.gmail.com>

On 12/1/10 9:40 PM, Amit Sahrawat wrote:
> While the copy operation is in progress, simply unplug the usb device and then replug.

that's not a simple copy operation either ;)

> The issue can be seen from XFS (2.6.31) onwards, I am trying to figure out the changes between 2.6.30.9 and 2.6.31.

If you have a regression, perhaps you can do:

# git bisect start v2.6.31 v2.6.30 fs/xfs

and methodically test the changes in between.

-Eric

> One thing I noticed is - there is difference in speed for 2 versions - in case of 2.6.30.9 if I remove the USB within '5' seconds - I can see the file being created at the destination and some data written, while in case of 2.6.31(onwards), it takes around 20 seconds to get some data to disk.
> I am using MIPS at the moment with VIPT(fixes included)
> 
> Please let me know if this information is useful.
>  
> Thanks,
> Amit Sahrawat
> On Wed, Dec 1, 2010 at 8:25 PM, Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>> wrote:
> 
>     On 12/1/10 1:14 AM, Amit Sahrawat wrote:
>     > Dear Member,
>     >
>     > I am getting following corruption on XFS formatted disk during a simple copy operation:
>     > sd 9:0:0:0: Attached scsi removable disk sdc
>     > sd 9:0:0:0: Attached scsi generic sg2 type 0
>     > XFS mounting filesystem sdc2
>     > Starting XFS recovery on filesystem: sdc2 (logdev: internal)
>     > XFS: xlog_recover_process_data: bad transaction
>     > XFS: log mount/recovery failed: error 5
>     > XFS: log mount failed
> 
>     hm, that's not a simple copy operation, that is a mount failing;
>     your log appears to be corrupted.
> 
>     offhand I'm going to blame it on having a write cache enabled
>     on your drive, and having barriers either off, or not working
>     properly.
> 
>     -Eric
> 
> 

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

  reply	other threads:[~2010-12-02  3:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-01  7:14 XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Amit Sahrawat
2010-12-01 14:55 ` Eric Sandeen
2010-12-02  3:40   ` Amit Sahrawat
2010-12-02  3:56     ` Eric Sandeen [this message]
2010-12-02  4:09       ` Amit Sahrawat
2010-12-02  4:13     ` Dave Chinner
2010-12-02  4:38       ` Amit Sahrawat
2010-12-02 12:23         ` Amit Sahrawat
2010-12-02  2:16 ` Dave Chinner
2010-12-02  3:41   ` Amit Sahrawat

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=4CF71907.60803@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=amit.sahrawat83@gmail.com \
    --cc=sandeen-xfs@sandeen.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.