SelectaDock III with HDD - File transfers, PIO, corruption

[pkiff]

I'm setting up a 770E in a SelectaDock III to act as a home file and print server. The 770E is running Windows 2000 SP4 on an old 8GB "C" drive and currently has 128MB [correction: 160MB] memory. The SelectaDock has a brand new, internal 300GB hard drive. Most everything seems to be working great, except I ran into repeated problems with file corruption when transferring large files over to the "server" drive (the drive installed in the SelectaDock III).

Symptoms:
- the file corruption occurred only on very large files (at least over 10MB, but usually over 50MB or so).
- it did not not seem to occur when I transfered directly from my primary drive (C:/) to the "server" drive.
- but it occurred whenever I transfered files from a third hard drive to the "server" drive, and in these cases, it did not matter if the third drive was inserted in the UltraBayII in the laptop, the UltraBayII in the dock, or used a PCMCIA Portable Device Bay connection.
- to be clear then, I've got 3 drives in the config that is giving me problems:
1. my 8GB primary OS drive in my 770E
2. my large 300GB "server" drive in the SelectaDock III device bay
3. any one of a series of other drives that I insert into the UltraBay II slots (for 770 series drives) or into a Portable Device Bay that holds UltraSlimBay devices (for 600 series drives).

Unhappy Solution:
After testing various confugurations, I started disabling features that I thought might be causing file corruption. So I turned off "write caching" on all drives, and then eventually turned off all my DMA settings as well, and set all devices on both the Primary and Secondary IDE channels to use PIO mode only. This finally appears to have solved the file corruption. I'm not sure if the write caching settings had any effect, as the file corruption did not go away until everything was set to PIO.

What is going on here? Has anyone else had this trouble with file corruption like this?

I don't understand write caching and PIO settings very well, and I wonder if this will make the file server too slow to deliver files (like streaming multimedia files) across the home network.

Anyone have ideas or thoughts on this?

Thanks,

Phil.

[pomdas]

DMA means DirectMemoryAccess which again means that your harddisk communicates with your memory without the work of your cpu. Cause of this it might be imaginable that your memory is bad or (more probable) you have only too less memory which causes large amounts of transfer by creating virtual memory by taking some place on your harddisk. I think that your problems are caused by this fact...

Pomdas

[pkiff]

Thanks for the suggestions, Pomdas. I've been reading up a bit more on the function of DMA access and on PIO/ATA/UDMA transfer standards. Based on what I've read, I don't think the amount of memory I have is the issue (Win2000 should run fine with over 100MB, and I actually have 160MB currently). But it occurred to me that you might be right about the problem being traceable to some kind of memory flaw/instability. The 770E/ED series was notorious for having flakey memory.

However, since then, I've set up my 770Z on the same SelectaDock with the same internal "server" hard drive, and this time it's running XP. So, different memory, different hardware, different OS, but same SelectaDock III and same 300GB internal drive. Unfortunately, today I discovered that this config also produces periodic transfer errors. So now I suspect it is a problem with the IDE interfaces or cables of the SelectaDock III itself. It could be a general problem with all SelectaDock III units, or it could be a specific failure of this single unit.

Phil.

[pomdas]

In my first answer I forgot to ask you, if you use some kind of harddisk manager. 300GB will be not supported by your thinpad with its BX chipset, I think. Some time ago I had a problem with bad data on my harddisk on an older pc and the solution was that this pc could not manage this large disk. The problme is that you cannot recognize this fact when your formated your disk in another pc or you use a preformated disk. Only when you format your disk in the target pc you can be sure to recognize this fact when you only can format a lower data amount.

The second point I want to mention is the IDE cable in the SelctaDock which has 40 wires which is ok for UDMA 66, but for better shilding I would try to use a 80 wire UDMA 100/133 cable. This cable also fits in the 40 wire socket but has some wire between the data wires to lower crosstalking. Maybe that might be a solution.

The third task might be that your large harddisk has not implemented a good UDMA 66 interface. Normaly you do not use such a harddisk in older machines

Pomdas

[pkiff]

In my first answer I forgot to ask you, if you use some kind of harddisk manager. 300GB will be not supported by your thinpad with its BX chipset, I think.

I'm not using any special disk manager, but the full drive is recognized correctly under Win98SE, Win2000 SP4, and WinXP SP2. I had some minor issues getting the partitions sorted out, but I think I fixed all that.

I used Rainish Partition Manager to create and format an initial 120GB FAT32 partition (because Win2000/XP won't natively format disks larger than 30GB). But at that point, only 128GB appeared to be recognized by Rainish for some reason. Then I used Win2000 SP4 Computer Managemet -> Disk Management, which recognized the whole disk, and I partitioned the rest into two more partitions, both NTFS. Rainish now recognizes the full disk and all partitions correctly, and so does Windows. I had the impression that disk size maximums were more of a BIOS limitation than a chipset limitation in most cases, but I'm not sure about that.

The second point I want to mention is the IDE cable in the SelctaDock which has 40 wires which is ok for UDMA 66, but for better shilding I would try to use a 80 wire UDMA 100/133 cable. This cable also fits in the 40 wire socket but has some wire between the data wires to lower crosstalking. Maybe that might be a solution.

I took a look at my current cabling, and it looks like it uses standard socket connectors, so I think I will investigate replacing these as you suggest. I have read about some other examples on the web where people solved their file transfer corruption issues by simply replacing cables. I'll look for one of these 80 wire cables.

The third task might be that your large harddisk has not implemented a good UDMA 66 interface. Normaly you do not use such a harddisk in older machines

I'm not sure I follow this one. It's a brand new, 300GB Maxtor (late 2005 model) and I'm pretty sure they must make them 100% compatible with all the old ATA/UDMA standards.

Thanks for the suggestions.

Phil.

[pomdas]

I had the impression that disk size maximums were more of a BIOS limitation than a chipset limitation in most cases, but I'm not sure about that.

Your are right, that is mostly a BIOS problem. The second point is the limitation of some programs. Hard to say what your BIOS does...

I'm not sure I follow this one. It's a brand new, 300GB Maxtor (late 2005 model) and I'm pretty sure they must make them 100% compatible with all the old ATA/UDMA standards.

That is more a thought in a much unprobable direction. Since the older computers have limitations in BIOS or their OS, it might be imaginable that it would be no problem not to implement a proper UDMA 66 interface. Or it is not tested in a good way. But this topic is, as I really said, more unlikely...

Pomdas

A question from me to this topic: Where do you have connected your large harddisk? In the tray normaly used for CDROM?