Formatting External USB Drives
in [General Linux]
|
Prev: NYC LOCAL: Wednesday 7 April 2010 NYCBUG: Marco Figueroa on Nepenthes Against Script Kiddies
Next: How deep an I buried?
From: Grant Edwards on 10 Apr 2010 09:33 On 2010-04-10, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > On Fri, 09 Apr 2010 22:50:04 -0400, Grant Edwards <invalid(a)invalid.invalid> wrote: > >> Can somebody explain why IDE DMA timing would affect a USB attached >> drive? > > As I understand it, even though the usb-storage module is being used > to provide the raw access, the ide modules are used to actually do > the data transfer. No, the drivers for the USB controller do the data trasfer. Above that is the USB mass storage driver, and above that is the SCSI disk driver. AFAIK, the IDE modules have nothign to do with it. > I may be wrong in this, which is why I'd like to know if either of > the workarounds I suggested actually work. > > Both of those workarounds were from when the ata module(s) were > detecting 80 wire ide cables when 40 wire ide cables were actually > installed. In that case, the kernel module selected udma transfer > rates, that the cables could not handle. > > This may have no impact in this case, but I can't think of any other > reason why the use of usb to access the drive would fail, while the > same drive works fine when internally connected, other then a problem > with the enclosure. I think you've hit the nail on the head: the USB<->IDE chip in the enclosure is buggy. > Note that usb uses dma access too. Yes, but it has nothing to do with the IDE settings. -- Grant
From: Robert Heller on 10 Apr 2010 09:55 At Sat, 10 Apr 2010 13:33:47 +0000 (UTC) Grant Edwards <invalid(a)invalid.invalid> wrote: > > On 2010-04-10, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > > On Fri, 09 Apr 2010 22:50:04 -0400, Grant Edwards <invalid(a)invalid.invalid> wrote: > > > >> Can somebody explain why IDE DMA timing would affect a USB attached > >> drive? > > > > As I understand it, even though the usb-storage module is being used > > to provide the raw access, the ide modules are used to actually do > > the data transfer. > > No, the drivers for the USB controller do the data trasfer. Above > that is the USB mass storage driver, and above that is the SCSI disk > driver. AFAIK, the IDE modules have nothign to do with it. > > > I may be wrong in this, which is why I'd like to know if either of > > the workarounds I suggested actually work. > > > > Both of those workarounds were from when the ata module(s) were > > detecting 80 wire ide cables when 40 wire ide cables were actually > > installed. In that case, the kernel module selected udma transfer > > rates, that the cables could not handle. > > > > This may have no impact in this case, but I can't think of any other > > reason why the use of usb to access the drive would fail, while the > > same drive works fine when internally connected, other then a problem > > with the enclosure. > > I think you've hit the nail on the head: the USB<->IDE chip in the > enclosure is buggy. Or the motherboard's DMA controller and/or USB controller and/or the motherboard's USB<=>DMA interface logic... It might also be that some *newer* IDE disks are using a more advanced IDE spec (ATA-6?) and the USB<->IDE chip in the enclosure does not really support this and the disk(s) are not downgrading themselves properly. > > > Note that usb uses dma access too. > > Yes, but it has nothing to do with the IDE settings. > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: Kevin the Drummer on 10 Apr 2010 15:04 Grant Edwards <invalid(a)invalid.invalid> wrote: > > This may have no impact in this case, but I can't think of any other > > reason why the use of usb to access the drive would fail, while the > > same drive works fine when internally connected, other then a problem > > with the enclosure. > > I think you've hit the nail on the head: the USB<->IDE chip in the > enclosure is buggy. Is there a USB<->IDE chip in my enclosure if it supports SATA drives and not ATA (IDE) drives? Thanks.... -- PLEASE post a SUMMARY of the answer(s) to your question(s)! Unless otherwise noted, the statements herein reflect my personal opinions and not those of any organization with which I may be affiliated.
From: Kevin the Drummer on 10 Apr 2010 16:26 David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > On Fri, 09 Apr 2010 12:28:57 -0400, Kevin the Drummer <nobody(a)cosgroves.us> wrote: > > > Apr 8 23:21:22 : sd 9:0:0:0: SCSI error: return code = 0x8000002 > > Apr 8 23:21:22 : sdf: Current: sense key: Aborted Command > > Apr 8 23:21:22 : Additional sense: > > Apr 8 23:21:22 : Logical unit communication CRC error (Ultra-DMA/32) > > Apr 8 23:21:22 : end_request: I/O error, dev sdf, sector 96238085 > > Apr 8 23:21:22 : Buffer I/O error on device sdf8, logical block 2168 > > Try booting with the kernel option "all_generic_ide=1", then running > the mkfs commands again. Well, I tried that. Same story again. When I did my rsync to the external drive it appeared to work for many files, then I got a bunch of this rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: \ Broken pipe (32) rsync: write failed on \ "/media/disk/mirror/music/etc/gconf/schemas/evolution-mail.schemas": \ Read-only file system (30) rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.6] rsync: recv_generator: mkdir \ "/media/disk/mirror/music/etc/locale/en_CA/LC_MESSAGES" failed: \ Read-only file system (30) *** Skipping any contents from this failed directory *** rsync: failed to set times on \ "/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1": \ Read-only file system (30) rsync: symlink \ "/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1/LC_COLLATE" -> \ "../ISO-8859-1/LC_COLLATE" failed: Read-only file system (30) rsync: symlink \ "/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1/LC_CTYPE" -> \ "../ISO-8859-1/LC_CTYPE" failed: Read-only file system (30) rsync: recv_generator: mkdir \ "/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1/LC_MESSAGES" \ failed: Read-only file system (30) *** Skipping any contents from this failed directory *** rsync: failed to set times on \ "/media/disk/mirror/music/etc/locale/en_DK.UTF-8": While rsync was reporting a read-only file system, 'mount' claimed /dev/sdh8 on /media/disk type ext3 (rw,nosuid,nodev,uhelper=hal) Also, /var/log/messages reported a huge number of lines like these: Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Sense Key : Aborted Command [current] Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Add. Sense: Logical unit communication CRC error (Ultra-DMA/32) Apr 10 13:00:43 music klogd: end_request: I/O error, dev sdh, sector 127315565 Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Sense Key : Aborted Command [current] Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Add. Sense: Logical unit communication CRC error (Ultra-DMA/32) Apr 10 13:00:43 music klogd: end_request: I/O error, dev sdh, sector 127315661 Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Sense Key : Aborted Command [current] The good news is that files actually got transferred to the drive, unlike last time when rsync reported that, but the files weren't actually there. The bad news is that a few minutes later the drive can't talk to the computer at all. That situation doesn't change with multiple combinations of rebooting and power cycling. My very unprovable hunch is that this is an enclosure problem, or a compatibility problem between the enclosure chips/firmware and the USB/ATA stuff in each of my two computers. If I knew whether my two computers were using the same chipsets, then I might be able to pile more evidence for or against this hunch. I think I'll return my external drive enclosures. One person suggested that I try a Vantec NexStar as he's used numerous enclosures from them over the years and had zero problems. Thanks for the suggestions!!! -- PLEASE post a SUMMARY of the answer(s) to your question(s)! Unless otherwise noted, the statements herein reflect my personal opinions and not those of any organization with which I may be affiliated.
From: Kevin the Drummer on 10 Apr 2010 16:30
David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > Another option to try, is addin a line to /etc/modprobe.conf with > options libata force=2:udma33 > and then rebooting. I didn't try that. My drive is messed up enough now (actually both of them) that I'd need to reinstall them internally on the SATA bus (again!) in order to return them to a usable state. > Both of these are attempts to try to get the kernel to use a slower > dma mode. But, what if I don't want a slower DMA mode on my internal drives? I'd take a slower transfer rate on the external drives, if it was absolutely required. But, I'd like to rule out oddities with my enclosure first. > Either way, a bug report should probably be raised at > https://qa.mandriva.com/index.cgi I've tried so many things, with such unrepeatable failures. Only the fact that it fails is repeatable. I'm not sure I could come up with a cogent report, at least not with out hours of very clear experimentation in order to see what is repeatable. Your thoughts on that? Thanks again.... -- PLEASE post a SUMMARY of the answer(s) to your question(s)! Unless otherwise noted, the statements herein reflect my personal opinions and not those of any organization with which I may be affiliated. |