<div>By tracing back to find the cause of the issue:</div>
<div><a href="http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=f95022161d23ee661a48af8f280472209f513a67">http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=f95022161d23ee661a48af8f280472209f513a67</a></div>
<div>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.</div>
<div>So, either this value can be lowered or this patch can be reverted so that pdflush takes care of all this.</div>
<div>Removing the changes from this patch seems viable solution at this moment.</div>
<div> </div>
<div>What do you suggest?</div>
<div> </div>
<div>Thanks,</div>
<div>Amit Sahrawat</div>
<div><br><br> </div>
<div class="gmail_quote">On Thu, Dec 2, 2010 at 10:08 AM, Amit Sahrawat <span dir="ltr"><<a href="mailto:amit.sahrawat83@gmail.com">amit.sahrawat83@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>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.</div>
<div>I will try more things and update if I can find anything new in this.</div>
<div> </div>
<div>Thanks,</div>
<div>Amit Sahrawat<font color="#888888"><br><br></font></div>
<div>
<div></div>
<div class="h5">
<div class="gmail_quote">On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat wrote:<br>> While the copy operation is in progress, simply unplug the usb device and<br>> then replug.<br><br></div>That's pretty much a guaranteed recipe for data and filesystem<br>
corruption regardless of the filesystem you are using. Even if you<br>are lucky enough that there was is no IO being issued while the<br>device is unplugged, what guarantee is there that the device even<br>comes back with the same device name? Further, if the device is usb<br>
powered, there is no guarantee that the drive caches were<br>flushed correctly before the unplug so random log and metadata<br>corruptions are definitely possible.<br>
<div>
<div></div>
<div><br>Cheers,<br><br>Dave.<br>--<br>Dave Chinner<br><a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a><br></div></div></blockquote></div><br></div></div></blockquote></div><br>