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@xxxxxxxxxxx <mailto:sandeen@xxxxxxxxxxx>> 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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
