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

[Amit Sahrawat]

By tracing back to find the cause of the issue:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=f95022161d23ee661a48af8f280472209f513a67
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?

Thanks,
Amit Sahrawat



On Thu, Dec 2, 2010 at 10:08 AM, Amit Sahrawat <amit.sahrawat83 at gmail.com>wrote:

> I am not able to reproduce the same behaviour on 2.6.30.9, 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.
>
> Thanks,
> Amit Sahrawat
>
>   On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner <david at fromorbit.com>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.
>>
>> Cheers,
>>
>> Dave.
>> --
>> Dave Chinner
>> david at fromorbit.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20101202/f7390e51/attachment.htm>