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 18.104.22.168 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.
> One thing I noticed is - there is difference in speed for 2 versions - in
> case of 22.214.171.124 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.
> 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