cp: writing 'filename': Input/output error

[jspring]

I am able to partially copy a large file to a mounted USB drive, but the copy terminates with the error message:

cp: writing 'filename': Input/output error

I previously successfully formatted the drive with the command:

root@myname# mkdosfs -F 32 /dev/sda1

Running mount gives:

root@myname# mount
/dev/hda1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /home/jspring/mount type vfat (rw,noexec,nosuid,nodev)

Running df gives:

root@myname# df mount/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 58576464 198784 58377680 1% /home/jspring/mount

It appears to me that the drive is formatted correctly and mounted with rw privileges. Another drive (Iomega) gave similar problems, so I think it's either the Linux configuration or operator error.

Any ideas?

Thanks very much!

[Freston]

How big is the file?? Because FAT32 has a 4GB limit to file size.

[jspring]

Oh, it's not that big. 500 MB. But the idea is to download video data on the order of 7 MB per file for a total of 30 GB. An Iomega drive I tried works just fine on a coworker's Mac, but I cannot get it to copy more than a few files from my Slackware 12.0 computer.

[Freston]

Does it work with other kinds of files? In other words, is it specific to the collection of files you're attempting to copy, or is it a universal problem?
Do other USB devices work?

Is the combo:

 /dev/sda1  /home/jspring/mount

in your fstab? Did you mount it with root permissions?

[jspring]

Sorry I haven't gotten back sooner; this is by no means my only task....
I'll boldface my replies; your questions are in normal font.

Does it work with other kinds of files? In other words, is it specific to the collection of files you're attempting to copy, or is it a universal problem?

It's a universal problem. Any file or collection of files will quit copying after awhile.

Do other USB devices work?

Good question: I tried a USB key (Cruzer micro 2.0 GB) and it did copy the large file.

Is the combo:
Code:

/dev/sda1 /home/jspring/mount

in your fstab? Did you mount it with root permissions?

It is in fstab, and it's mounted with user permissions. Here's the fstab entry:
/dev/sda1 /home/jspring/mount vfat users,rw 0 0

[bryansmith]

If the drive doesn't work and another does (the cruzer), it sounds like a problem with the USB drive.

Can you not even copy a small text file?

Bryan

[jspring]

If the drive doesn't work and another does (the cruzer), it sounds like a problem with the USB drive.

Can you not even copy a small text file?

Bryan

Small text files I can copy; it's the big'ns that give trouble.

I should've mentioned the dmesg output; I think it may give a clue as to what may be wrong....

I'll make what I think are insightful comments after the dmesg output.

Following is the last message concerning the mouse, then messages pertaining to the successful mounting of the Cruzer USB key.

psmouse.c: Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes
away.
usb 1-2: USB disconnect, address 21
usb 1-2: new high speed USB device using ehci_hcd and address 22
usb 1-2: configuration #1 chosen from 1 choice
scsi21 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 22
usb-storage: waiting for device to settle before scanning
scsi 21:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 2.18 PQ: 0 ANSI: 2
SCSI device sda: 4001425 512-byte hdwr sectors (2049 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 4001425 512-byte hdwr sectors (2049 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
sda: sda1
sd 21:0:0:0: Attached scsi removable disk sda
sd 21:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
usb 1-2: USB disconnect, address 22

Now we try to mount a 60 GB Toshiba drive.

usb 1-2: new high speed USB device using ehci_hcd and address 23
usb 1-2: configuration #1 chosen from 1 choice
scsi22 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 23
usb-storage: waiting for device to settle before scanning
scsi 22:0:0:0: Direct-Access TOSHIBA MK6025GAS 0811 PQ: 0 ANSI: 0
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
sda: test WP failed, assume Write Enabled
sda: assuming drive cache: write through
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
sda: test WP failed, assume Write Enabled
sda: assuming drive cache: write through
sda: sda1
sd 22:0:0:0: Attached scsi disk sda
sd 22:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
FAT: Filesystem panic (dev sda1)
fat_free_clusters: deleting FAT entry beyond EOF
File system has been set read-only
usb 1-2: USB disconnect, address 23

Well, that didn't work, so let's try the 120 GB Iomega drive.

usb 1-2: new high speed USB device using ehci_hcd and address 24
usb 1-2: configuration #1 chosen from 1 choice
scsi23 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 24
usb-storage: waiting for device to settle before scanning
scsi 23:0:0:0: Direct-Access Ext Hard Disk PQ: 0 ANSI: 4
SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB)
sda: Write Protect is off
sda: Mode Sense: 10 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB)
sda: Write Protect is off
sda: Mode Sense: 10 00 00 00
sda: assuming drive cache: write through
sda: sda1
sd 23:0:0:0: Attached scsi disk sda
sd 23:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
sd 23:0:0:0: SCSI error: return code = 0x00050000
end_request: I/O error, dev sda, sector 20130325
printk: 62 messages suppressed.
Buffer I/O error on device sda1, logical block 20130262
lost page write due to I/O error on sda1

9 similar messages (different logical blocks)

usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24
usb 1-2: reset high speed USB device using ehci_hcd and address 24

etc....

When I get the resets from the attempted Iomega copy, the blue light on the drive (indicating some sort of action) goes off and stays off (i.e. doesn't blink). I have a couple of questions:

I notice that for both the successful mount and copy of the Cruzer USB key, and the unsuccessful mount and copy of the Iomega and Toshiba drives, there is the message:

sda: assuming drive cache: write through

Is it safe to assume a sufficiently large drive cache? I would also assume a drive cache, but are there any drives that don't have one? I should note that I did not buy either drive, and when I went to the Iomega website to look at the spec sheet, it mentioned that the drive was for Windows and Macs, but did not mention Linux. I'm wondering whether Iomega might be relying on Microsoft's and Apple's software to buffer and control the copying, rather than hardware (this is just a stray thought; I think it's unlikely).

Can I infer from the successful Cruzer mount and copy, the set of messages I would receive for a successful mount and copy of a hard drive?

Is there a step-by-step procedure for mounting and copying an external USB hard drive to Linux? I'm wondering whether there is some driver initialization parameter that is wrong or not there, or some step I'm missing.

By the way, thank you very much for your time and work! It's very helpful.

[jspring]

The problem with my portable Iomega USB drive was not with Slackware or Linux at all. The problem was that the USB cable was not rated for USB 2.0. It was rated for only USB 1.1. But this was masked for awhile because the drive worked a little bit. Here's what happened:

We bought an Iomega drive that had both USB 2.0 and Firewire connections. The latter was needed because one of the engineers has a Mac and preferred Firewire. The CPU we were using is a PC104 form factor Pentium M, with USB 2.0 onboard. So USB 2.0 is USB 2.0, right? I mean, it's a standard, so 484 MB/sec speed and sufficient power (5 VDC @ 500 mA) are required by the standard, right? Wellll....

Iomega claims the drive can be powered by only the USB power. So I tried that. But I could see the blue activity LED blinking and hear the drive heads searching without doing any copying. When I looked at dmesg, there were many over-current messages. So the power was insufficient. OK, I plugged in the adapter and the drive seemed to work. The LED stayed lit and I didn't get any over-current messages. But the copying wouldn't complete; it got hung partway through. I'd get tired of waiting and hit ^C. dmesg told me a reset had been sent to the drive, but not why.

This is when I started posting to the forum. I tried everything suggested and finally gave up until I tried connecting the drive to my Slackware laptop, and the copying worked fine. So it was still a hardware problem. I call Advanced Digital Logic, the CPU vendor, and the service engineer said,

"You bought the standard package with that flimsy flat ribbon cable to the USB connection, didn't you?"
"Yeah, I guess so."
"That's your problem. Get the cable harness with shielded USB cables for $72 apiece." "(mumble,mumble.) OK."

This worked. So the moral of the story is: if you have trouble with reliable USB on new equipment, make sure the hardware, including the cable, is correct!