Comment 15 for bug 40561

I have a new Freecom Classic SL 80GB USB hard drive connected to
Ubuntu 6.06 Dapper Drake Linux 2.6.15-29-386 on old (2001) hardware
also tried with Mac PowerBook G4 MacOS 10.3.9.

After playing with the VFAT filesystem on the disk as it came, using both computers,
I used GNU Parted 1.6.25.1 to put a single-partition EXT2 filesystem on it.
However, fdisk v2.12r thinks that it's still VFAT, whilst (after doing the copies below)
the Mac still sees the old VFAT files, but not the new EXT2 ones.

I started trying to copy the partitions of the 20GB disk on the Linux machine,
using GNU cpio v2.6. The two smallest ones (/=168MB and /var=316MB) were
copied corrrectly, as verified using md5sums.

When I tried the bigger ones (/usr=2168MB and /home=1754MB), the copy failed
after some time (after almost 1GB on one occasion) and the disk was disconnected.

STDERR said: cpio: write error: Input/output error

dmesg said: Buffer I/O error on device sda1, logical block 8587112
and (repeatedly) rejecting I/O to dead device

/var/log/messages contained lines like the following
usb 1-1: new full speed USB device using uhci_hcd and address 3
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: HDS72808 Model: 0PLAT20 Rev: 0 0
Type: Direct-Access ANSI SCSI revision: 00
SCSI device sdb: 160836480 512-byte hdwr sectors (82348 MB)
sd 1:0:0:0: Attached scsi disk sdb
Driver 'sd' needs updating - please use bus_type methods
printk: 17347 messages suppressed.
lost page write due to I/O error on sda1

After this, /dev/sda1 no longer appeared in the output of "df",
and both mount and umount denied the existence of /dev/sda1.
However, usbview said that the usb device was still there.
After turning the disk power off/on, it appeared as /dev/sdb1.

A subsequent e2fsck found numerous errors with free block counts,
unattached inodes, inode ref counts, directory counts, etc.

This happened four times, including once using tar instead of cpio.

I tried using "e2fsck -c" to check for bad blocks. The first 3% of the disk
was ok, but took ages, so I went away to do something else. When I
came back, the disk had been disconnected as before, but I couldn't
see how far the bad block check had gone, as the screen saver wouldn't
restore the text of that terminal window. Subsequent e2fsck was clean.

I have no idea whether this is a Linux bug or faulty hardware. I am posting
this report here because the comments above were the closest that I could
find in a web search to the symptoms that I have.