PC trouble ripping to one of two identical HDD (uber frags)

[Sasha]

My most current PC that built is based on the following composition:

Abit AA8 Mptherboard w/Intel LGA775 3GHz CPU
Corsair XMSpro 1GB DDR2 memory
Albatron PCX5300 PCI-Express Video
1xMaxtor 80GB 6Y080P0 Boot HDD on Intel 82801 IDE0 (Master)
1xPioneer A07 DVD-R/RW on Primary Intel 82801 IDE0 (Slave)
1xMaxtor 200GB 6Y200P0 Data HDD on IDE1* (Master)
1xMaxtor 200GB 6Y200P0 Data HDD on IDE2* (Master)
* Promise Ultra100 TX2 controller in PCI slot
Microsoft Windows XP professional w/SP2 & all Critical Updates

All HDDs are single-partitioned as Primaries and no IDE channel has more than one HDD on it. IDE0 is on the AA8 motherboard and IDE1 & IDE2 on the Promise controller in PCI slot.

IDE0 HDD is the C drive, IDE1 is the D drive, and IDE2 is the E drive, with the Pioneer optical drive being the F drive. The 'D' and 'E' drives are identical make/model Maxtors, configured according to XP's default partitioning using NTFS (4KB clusters).

Ok, now the problem:

If I rip a DVD video in the F drive using either DVD Decrypter or DVDshrink I had no initial problem writing the resulting ISO file to the desired HDD, which is the E drive. This ability ceased recently just after consuming about 100GB on that drive. Initially, I thought maybe it was a copy-protection, but this was ruled out when a) another DVD title did the same, and b) I did not have this ripping inability when targeting the D drive instead (which had much less disk capacity consumption.

I then thought that maybe it was a software and or operating system issue, but this was ruled out when I wiped the Boot drive (C) clean and reinstalled the OS and minimal software only to reach the same problem. I then focused on the E drive as a potential problem with it, the Promise controller, and or the operating system in conjunction with them. No clear deal, here.

I then started a closer inspection of both the D and E drives as they are identical, running as Masters off separate channels on the same controller, configured identically by XP, etc. and discovered something strange. None of the ISO files I created through ripping to the D drive resulted in any type of fragmentation. On the other hand, all of the ISO files I ripped to the E drive resulted in fragmentation!

At this point I deleted the primary NTFS partition from the E drive and rebooted. I then re-created a new NTFS Primary partition on the E drive. I then set about using DVD Decrypter to rip an ISO image file to the E drive. This worked just fine, until I inspected the disk in XP's Disk Defragmenter. The one ISO file was fragmented, and the only other files were the MD5 file DVD Decrypter creates and the hidden Windows folder for the Volume Information.

To illustrate what I was looking at for a single ISO image file being written to the disk in a very fragmented way, please see the attached (cropped) screen capture. After realizing this, I ran the defragmenter and the result is shown in the same capture. Additionally, there is a space on the disk that appears that is 'not' being used (XP Pagefile restricted to the C Boot HDD), both before and after the defragment.

Now, the Intel controller has installed the 48-bit LBA needed for large drives such as these two 200GB Maxtor drives, but they are not on that motherboard-embedded controller, but on the Promise controller in a PCI slot. I doubt that it is a 48-bot LBA limitation for the Promise controller as the D drive on that controller is writing fragment-less files. Also, the 'working' HDD (D drive) also seems to be reserving space on the HDD as well.

So, I am confused about the fragmented write-nature when writing to one disk and not the other, and the possability that this is causing when my bigger problem, which is not being able to rip (either with DVD Decrypter or DVDshrink) once 100GB or so are consumed) on the E drive.

Several options:

a) Swap the D and E drives on the Promise controller and see if the fragmentation behavior follws the drive or stays with the channel
b) Try another IDE controller
c) Try an PATA-to-SATA adapter and use the SATA IDE controllers on the motherboard.

I am certainly open to any suggestions, enlightenment, etc.

[Soopafresh]

All good options you mentioned. You can try a daily file defrag with the following command line apps: It'll take a while the first time you run this, but subsequent executions will be quite fast.


Contig - http://www.sysinternals.com/files/contig.zip

Dirms - http://www.dirms.com/download/dirms1220.zip

Create a batch file with the following commands

c:
cd\
contig *.* /s
dirms c
d:
cd\
contig *.* /s
dirms d



etc for your other drives.

[Sasha]

Daily defrag is a band-aid solution, isn't it? When a 200GB disk is empty and the partition new it shouldn't be fraging the first disk write, should it, and then frag all subsequent writes as well before the first file deletion? This also doesn't address why the is a section about 20GB in size near the beginning of the disk that seems to be not used (reserved?) for no apparent reason.

[Faustus]

Frined of mine has something sorta like this. BUt it went away after a reformat and downgrade of his chipset drivers for his mobo/hdd controller

[Sasha]

Ok, I've done testing this morning with the hard drive using Primary and Extended-style partitions with the same result. I have discovered 'something' though. If I copy a 7.5GB ISO image file from the D drive to the E drive it does not fragment at all. I tested and re-tested this in several different scenarios and its the same result. Ripping fragments but copying from another drive does not.

The space on the disk being reserved seems to not be related to this problem. I've not observed this on disks on another PC, both Maxtor and Western Digital. I can test later to insure accessability to that space, but I think its not a problem (have a disk where I've reached +90% of that disk's capacity and the reserved area on the disk has been accessed.

So, I now have to determine why the pioneer drive is causing fragged conditions during ripping situations as I fear the mega-fragmentation was my original problem in ripping (backing up) the Incredibled DVD last week. I'll need to test that theory later in the week.

[otpw1]

Edited- Sorry, I needed to read the details again. Drain Bamage.

[Sasha]

Okay, I had time to spend beating the war drums and I basics started from scratch with the entire computer. I discovered some weird HDD jumper settins between the two data drives, and I experimented with them both being Master and Cable-Select on their isolated IDE channels. I also re-did the boot drive. Fragmentation still occurs (and not sure if this is still the cause of the problem I experienced last week), but the segment of the disk-space for a given drive is seen uniformly on all drives. First, the boot drive:

[Sasha]

Okay, and now a Before/After (w/respect to defragmentation of the DVD Decrypter ripped DVD Dark City) of the D-drive:

Same thing happens on the E-drive, too.

[Sasha]

C-drive with on rip and then defragged: