On Sat, 29 Jan 2005, I wrote: >A system I built about a month ago is hanging whenever I do any >significant disk I/O. In particular, the system will hang when I use tar >to transfer a bunch of files from an NTFS-formatted disk to a >reiserfs-formatted disk (using tar). This is a hard hang -- the mouse >pointer freezes and nothing except a hardware reset will bring the >system back. > > I thought I'd write an update on what's happened so far. There were three suspects: 1. ASUS A7N8X-E motherboard with known ACPI issues (fixed in kernel 2.6.10) 2. Promise Technology Ultra100 controller 3. NTFS file system I received advice from Chad, Dave and Brian. Chad Walstrom wrote: >Historically, Linux has had crappy NTFS support. Since you mentioned >using tar to transfer, I'm assuming this a read operation. That should >be O.K., but you never know. I'd stay away from write operations on the >NTFS system if possible. Indeed, these were NTFS file systems mounted read-only, hooked up to a Promise Technology controller. Chad also said: >Promise controllers suck royally, IMHO. Their standard IDE >controllers may be O.K., but my experience in working with their >software RAID cards has given me the general impression that you want to >stay away from Promise if you can. So the first thing I did was to move away from the Ultra100 controller. I had two available motherboard IDE connections so I hooked up the source and destination disks to them and reran the archive/restore operations. I got farther than before, but the system still hanged. However, just before it locked up the process running the tar "create archive" operation encountered an "unexpected EOF" error, and the copy was aborted. Based on this result, I decided that the Ultra100 controller might be partially responsible for the failures I was seeing, but it wasn't the only factor. Brian Hurt wrote: >I'd play with hdparm and turning down the I/O speed of the drive, to see >if the problem goes away. The other thing to check is to see if there's >an updated IDE driver that might help. > > I never did play with this, though I thought about turning DMA off. Finally, Dave Erickson wrote: >If possible, install the NTFS drive(s) into a windows box and copy via samba. > >I did this while converting a computer from windows to Linux and it works really well. I did this next. I resurrected the PC that originally held the disks, exported them as Windows shares, and remote-mounted them with samba. I am now copying the directory tree from one SMB file system to a Linux LVG file system. It's been running for over 9 hours and so far there have been no problems. I'm not getting the performance I would have hoped, but at least the copy is running. I've got to transfer about 180gb worth of data spread across 5000 files. I'm getting about 3.6gb/hour so I figure I'm looking at 50 hours. This is on a 100baseT LAN. Thanks to all who offered advice. I'm blaming NTFS support for the problems I encountered. -Jeff