[Top] [All Lists]

Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34
From: Amit Sahrawat <amit.sahrawat83@xxxxxxxxx>
Date: Thu, 2 Dec 2010 17:53:34 +0530
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx, sandeen-xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KtjGyAF3BXwyLH8vhsDPunhw5Fs3LPRDTPxIIQTQK9E=; b=PvdVRoz0C6xPQXDZYvkTyYW5/8tjqN4G6+89FW3C1zGL4p1Ntj2oLDnFYxutb61U1/ qwU0OLBmE7OP2stMvDgQbUKDTAc3YGSiIePpbdGcq7da1qLgDHFQ2ItApFr9gGqEU8Ej EsrRnmIqeGXEiOoKeBP5lhpwogVusuo33Tu2Q=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c+E28sYntqcphII+xzBTu3uRgrfLuO/pQawK4N1STyu6eRC8XqhO2QSQmQrvJE/cVg CA4IE2UU6X9nAl5HyC0o6xlFXXPgFhoUgX2Fe0wOGTwC54aaxbqp1cb7JaWwJP07idTX E/pD3psGCkeQ3aG0JZHxUW9J2fVFQtBpbgLSw=
In-reply-to: <AANLkTimO0+qJ7SLh720nFh9Sw+4hdshuipRXxDSSORmp@xxxxxxxxxxxxxx>
References: <AANLkTikzCpQ1j9uWGSTY9TEguVDvAB5AVYtbDtdePFci@xxxxxxxxxxxxxx> <4CF661C7.2020103@xxxxxxxxxxx> <AANLkTimiST8VNVsV49mniKLBudSxFj+O883Mwwe7ucac@xxxxxxxxxxxxxx> <20101202041312.GX16922@dastard> <AANLkTimO0+qJ7SLh720nFh9Sw+4hdshuipRXxDSSORmp@xxxxxxxxxxxxxx>
By tracing back to find the cause of the issue:
This patch results in generating different behaviour for write. - it makes dependency on xfssyncd(for which default time out value is 3000centisecs - cat /proc/sys/fs/xfs/xfssyncd_centisecs) - 30secs is too large for committing to disc.
So, either this value can be lowered or this patch can be reverted so that pdflush takes care of all this.
Removing the changes from this patch seems viable solution at this moment.
What do you suggest?
Amit Sahrawat

On Thu, Dec 2, 2010 at 10:08 AM, Amit Sahrawat <amit.sahrawat83@xxxxxxxxx> wrote:
I am not able to reproduce the same behaviour on, had it been on all versions - this can safely be termed as behaviour. But from 2.6.31 onwards this is very much reproducable, especially the change in behaviour of writing to disk.
I will try more things and update if I can find anything new in this.
Amit Sahrawat

On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat wrote:
> While the copy operation is in progress, simply unplug the usb device and
> then replug.

That's pretty much a guaranteed recipe for data and filesystem
corruption regardless of the filesystem you are using. Even if you
are lucky enough that there was is no IO being issued while the
device is unplugged, what guarantee is there that the device even
comes back with the same device name? Further, if the device is usb
powered, there is no guarantee that the drive caches were
flushed correctly before the unplug so random log and metadata
corruptions are definitely possible.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>