Find the answer to your Linux question:
Results 1 to 8 of 8
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Aug 2006
    Posts
    7

    cp: writing 'filename': Input/output error


    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!

  2. #2
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    How big is the file?? Because FAT32 has a 4GB limit to file size.
    Can't tell an OS by it's GUI

  3. #3
    Just Joined!
    Join Date
    Aug 2006
    Posts
    7

    Reply to thread 'cp: writing 'filename': Input/output error'

    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.

  4. #4
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    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:
    Code:
     /dev/sda1  /home/jspring/mount
    in your fstab? Did you mount it with root permissions?
    Can't tell an OS by it's GUI

  5. #5
    Just Joined!
    Join Date
    Aug 2006
    Posts
    7
    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

  6. #6
    Linux Guru bryansmith's Avatar
    Join Date
    Nov 2004
    Location
    /Ontario/Canada
    Posts
    2,619
    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
    Looking for a distro? Look here.
    "There can be no doubt that all our knowledge begins with experience." - Immanuel Kant (Critique of Pure Reason)
    Queen's University - Arts and Science 2008 (Sociology)
    Registered Linux User #386147.

  7. #7
    Just Joined!
    Join Date
    Aug 2006
    Posts
    7
    Quote Originally Posted by bryansmith View Post
    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.

  8. #8
    Just Joined!
    Join Date
    Aug 2006
    Posts
    7

    Problem solved! It was hardware!

    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •