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?
Thanks,
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 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 SahrawatOn 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:That's pretty much a guaranteed recipe for data and filesystem
> While the copy operation is in progress, simply unplug the usb device and
> then replug.
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.
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
