• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Corrupted Files!?

K

KingPariah777

[H]ard|Gawd
Joined
Jun 18, 2003
Messages
1,903
I have a Western Digital 80 gig hard drive that has been in my machine for about 2.5 years, and it seems that whenever I transfer large files onto or off of the drive, they become corrupted. In addition, my Overnet transfers often can't finish because of massive corruptions in them.

Video files look beautiful on my primary 40 gig Maxtor, but as soon as I move them to my 80 gig, they become corrupted and almost unwatchable. Sometimes they freeze or refuse to load.

Some files never leave the drive, and have been on it for years. These files work fine.

I haven't formatted or repartitioned the drive ever since I first got it. Do you think it needs something simple like that, or are my problems more major?
 
Originally posted by CrimandEvil
Nvidia driver problem? Have you defraged your HD?
Click to expand...

1. I fail to see the relevence that has to anything in this post.

2. Yes, but that isn't the problem.
 
The Nvidia IDE drivers are horrendous, I've had to reformat my HD several times now because of them, major file corruption.
 
Originally posted by CrimandEvil
The Nvidia IDE drivers are horrendous, I've had to reformat my HD several times now because of them, major file corruption.
Click to expand...


oh haha the nforce drivers...i was thinking you were talking about Detonators...

Hmm...yeah I have the latest drivers.

I wonder if having a corrupt partition table or something would affect it.
 
Originally posted by KingPariah777
1. I fail to see the relevence that has to anything in this post.

2. Yes, but that isn't the problem.
Click to expand...

Data corruption can occur on the CPU, in the memory, on the system bus, the controller, or the drive itself. In the past the usual problems were the processor being overclocked too far, affecting both processor operation and the bus speeds, impacting devices attached to the bus (i.e. your controller). As time progressed the larger problem was flaky controllers and drives. Today, most of the problems are due to either memory errors or drivers for the controllers.

Given that one drive seems good and the other one not, the easiest step is to try futzing with controller drivers. Should that not do anything, put the drive in another machine and try it there. That will isolate the problem pretty quick.
 
Originally posted by Snugglebear
Data corruption can occur on the CPU, in the memory, on the system bus, the controller, or the drive itself. In the past the usual problems were the processor being overclocked too far, affecting both processor operation and the bus speeds, impacting devices attached to the bus (i.e. your controller). As time progressed the larger problem was flaky controllers and drives. Today, most of the problems are due to either memory errors or drivers for the controllers.

Given that one drive seems good and the other one not, the easiest step is to try futzing with controller drivers. Should that not do anything, put the drive in another machine and try it there. That will isolate the problem pretty quick.
Click to expand...

Any way to change "settings" for controller drivers? Or do you suggest i just swap around different versions...?
 
Try everything at stock speed, maybe you have an overclocking problem corrupting your files

OldMX
 
Originally posted by OldMX
Try everything at stock speed, maybe you have an overclocking problem corrupting your files

OldMX
Click to expand...

This was my original thought...my overclock is prime95 stable (24 hours) and has been since the install of the OS...

Is it possible that during the testing phase I pushed things too far and damaged ONLY the part of the bus that controls the secondary IDE channel? Or damaged the actual IDE channel itself?

Everything else is stable for me and I get good temps (44 C on full load).
 
Is there some kind of utility that determines hard drive errors or corruption caused by data transfers to the drive?

By the way, did i Mention that the two drives are both using Abil Serillel SATA-IDE adapters...so they are using the SATA adapters on the motherboard.
 
Information Dump In progress
stay back at least 20 feet :eek:

Corruption 101
as Snugglebear so eloquently put it there sometimes seems to be a few hundred ways to munge your data
my personal list of probability based on
The Risks To Your Data @ the PC Guide (with a few additions, and split into hardware, software and filesystem)

Hardware Failure

Memory Errors: With so many systems today running without error detection or correction on their system memory, there is a chance of a memory error corrupting the data on the hard disk. It is rare for it to happen, but it does happen.
Test your RAM with memtest86 and or Memtest, consider a board that supports ECC RAM[/url]

Power Loss: Losing power at the wrong time, such as when you are doing sensitive work on your hard disk, can easily result in the loss of many files
Use a high quality PSU with stable voltage, employ a UPS or other line conditioning, avoid hard restarts

Cables not included on the PCGuide's original list it is none the less an importatnt possibility, especially with todays transfer speeds, there is a very real reason that the industry is adopting SATA over PATA see post below for a full discussion and links

System Timing Problems: Setting the timing for memory or cache access too aggressively, or using a hard disk interface transfer mode that is too fast for the system or device, can cause data loss. This is often not something that will generally be realized until after some amount of damage has been done.
see tRAS below, bump back an overclock, try a different divider, dont overclock if you cant lock the PCI bus, I would bump the probability of this up a few slots if the machine is overclocked, otherwise I ve put it here

Resource Conflicts: Conflicts resulting from peripherals that try to use the same interrupt requests, DMA channels or I/O addresses, can cause data to become corrupted.
Review PIRQ routing and manual assignment of IRQs in the worse case senerio, chipset specific but a good overview

The Hard DriveTest with the manufacturers Diagnostic, most of the rest is preventative, proper handling vibration free and cool environment, with clean air and stable floor

Software Failure
Busmastering Drivers

Filesytem Corruption
 
---------------------------------------------------------------------------------
i don't want to go off on a rant....but

there is definately a reason why SATA is being adopted, ATA\IDE\EIDE\ATAPI is an unterminated standard and as speeds increase that causes more and more problems, especially if cheap cables are employed, complex device configurations, hotswap\removable drivebay bridgecards and poor cable routing

a few :)p) links and excerpts:
Standard (40-Conductor) IDE/ATA Cables

In many ways, the cable is the weak link in the IDE/ATA interface. It was originally designed for very slow hard disks that transferred less than 5 MB/s, not the high-speed devices of today. Flat ribbon cables have no insulation or protection from electromagnetic interference. Of course, these are reasons why the 80-conductor cable was developed for Ultra DMA. However, even with slower transfer modes there are limitations on how the cable can be used.

The main issue is the length of the cable. The longer the cable, the more the chance of data corruption due to interference on the cable and uneven signal propagation, and therefore, it is often recommended that the cable be kept as short as possible. According to the ATA standards, the official maximum length is 18 inches, but if you suspect problems with your hard disk you may find that a shorter cable will eliminate them. Sometimes moving where the disks are physically installed in the system case will let you use a shorter cable

Warning: There are companies that sell 24" and even 36" IDE cables. They are not recommended because they can lead to data corruption and other problems. Many people use these with success, but many people do a lot of things they shouldn't and get away with it. :^)

Ultra DMA (80-Conductor) IDE/ATA Cables

There are a lot of issues and problems associated with the original 40-conductor IDE cable, due to its very old and not very robust design. Unterminated flat ribbon cables have never been all that great in terms of signal quality and dealing with reflections from the end of the cable. The warts of the old design were tolerable while signaling speeds on the IDE/ATA interface were relatively low, but as the speed of the interface continued to increase, the limitations of the cable were finally too great to be ignored.

that "upgrade happened at 66MB/s burst, we are now at the same speed as the PCI bus for burst rates 133MB/s

Fancy IDE leads - The Terrible Truth

The spec mandates such short cables for two reasons.

Reason one - practically all IDE cables are unshielded. There's nothing around the conductors but insulation. Electromagnetic radiation goes straight through insulation. So external interference from the rest of your computer's giblets can influence the signal on your IDE leads.

Unshielded cables act like antennas. Generally speaking, the longer you make 'em, the more energy they can pick up from their environment.

Reason two - IDE cables are unterminated. "Termination", in the electrical sense, is essential to provide "impedance matching", which in English is what you have to do to stop the signal from reflecting off the end of the cable like a wave that hits the end of a bathtub.

Electric current does not move instantaneously down a wire. It travels at nearly the speed of light, but when you've got thirty-three and a third million clock pulses per second - which is the speed of the IDE bus - even light in a vacuum only moves a hair under nine metres per clock pulse.

So if you're fooling around with, say, a double-the-rated-length 900mm IDE lead, there's an end-to-end signal delay in it of about a tenth of a clock pulse. The signals you want your drives and your motherboard to be able to hear will be significantly blurred by delayed reflections from each end of the cable.

Transfer your data at twice or three times the UDMA/33 speed - as UDMA/66 and 100 do - and reflected signals get more and more out of step with the real signal, and do it more and more harm.

Serial ATA and the 7 Deadly Sins of Parallel ATA
Critical Limiting Factors in Parallel Design
There are some fundamental differences between serial and parallel buses, more importantly, there are some critical limiting factors in the design and implementation of any parallel bus.

1. Non-Interlocked (source synchronous) clocking
2. 3.3 V high-low signaling with 5V legacy tolerance
3. Cabling constraints
4. Connector legacy
5. Termination
6. Command queuing
7. PCB Design

3. Cable Design Issues: Cross-Talk and Ground Bouncing vs.Ringing

Each signal propagating through a data line makes the data line act like the inductor of a transformer. That is, each voltage swing generates a dynamic electromagnetic field, that, depending on cable length and proximity will induce another signal in adjacent data lines. This cross-talk adds noise to data lines and can produce errors by generating false positives or negatives simply by induction of voltage swings in data lines.

Another problem with parallel pathways is the phenomenon of simultaneously switching outputs (SSO) noise. As we explained in detail in our reviews of the i845 and the SIS645 chipsets, SSO noise becomes really problematic if the majority of signals switch from high to low since this can induce ground bouncing. On the chipset level, workaround in form of dynamic bus inversion (DBI) is feasible, that is, instead of switching all bits, only the reference bit is switched simultaneously at the sender and receiver end which has the same net effect, namely, that the system does not see the reference switch but thinks that all other lines have switched. DBI, however requires an additional latency cycle and this is where the 40 ns clock cycle time starts to look really ugly.

ATA not so Frequently Asked Questions
Or: Why Ribbon Cables are unsuitable for RF transmission of data

The following article was written by snn47 to address some of the issues associated with standard ribbon cables and the use of e.g. removable drive racks as an attempt to share some insight into factors that can adversely affect the life or reliability of of desktop Hard Disk Drives. Specifically, issues like why some drives are working in some systems and not in others, the impact of cable routing and why is it that the drive manufacturers always recommend using their own cables (if supplied with the drive). (emphasis mine)

Any RF system has a limited tolerance for distortion of signals, which, in the worst case, can destroy some of the semiconductor components. While a certain amount of variation is part of any systems specification, one needs to remember that ATA was never intended to handle today's data rates. ATA or Advanced Technology Attachment started as the usual run of the mill or: "just a system at the lowest possible price point that will work most of the time without the need for huge financial investments". The problems started when the system was forced to handle higher and higher clock and data rates within the original design limitations. Keep in mind that the latest ATA-PI7 specifications allow data rates of 133 MB/sec, which is 44-times faster than the original ATA transfer of 3 MB/sec. This increase in speed makes it necessary to enforce minimum tolerances and detailed specifications to allow for the manufacturing of affordable systems with minimum compatibility problems.


these are just a few excerpts, I would highly advice that everyone give them a good read, there ARE good rounded ATA cables RD3XP Super Shielded
"RD3XP is made from ATA 100/133 High impedance flat cable cut into 8 layers of 10 cable wires, with a ground wire and signal wire alternatively, and folded in zigzag-piled so that each signal wire is surrounded by 4 ground wires."

but like their SCSI counterparts, they aint cheap, there are also high quality flat cables (you buy a $300 RAID card, and they dont ship you crappy PVC cables, they are either Teflon or Thermoplastic Olefin (TPO)

Up until a little while ago I would have said ant investment made in high quality cables was money well spent, however with the introduction of SATA, that doesnt necessarily hold true anymore
unless your dealing with critical data (in which case you should be running ECC RAM) or your actually experiencing problems

a further excerpt from ATA not so FAQs

Preliminary Conclusions and Possible Cure

Reasons for changes in the propagation impedance, cross-coupling between adjacent signal wires and signal-velocity from one setup to another are :

Impedance of the drive and controller in high/low signal level will be different for different models.
Reflection of signals that garble the pulse, due to incorrect termination impedance or impedance-inconsistencies from the controller to the drive meaning the Impedance from the controller and the drive(s) differ.


If there is a a second drive (connector present/connected) the impedance will fluctuate at this point.

A. Only one HDD per controller channel.

B. Use a cable with only 2 connectors.

-Signal delay will increase with the length of the flat-ribbon-cable propagation of the signals were intended for a max. flat-ribbon-cable length of 18" with ~ 5ns/m would be 2.3ns delay.

C. shorten the cable whenever possible.

D. If the case requires long cables consider mounting just the HDD closer to the connectors of the controller or consider exchanging the usual desktop case, for a 19" case. Mount the HDD just above or below the PCB-controller-connector to allow you to reduce the length of the flat-ribbon-cable to a few cm.

Flat-ribbon-cable with different isolation material (higher/lower eR) and change in the conductor diameter will change the ratio of (2D/d).

Are rounded cable used?
E. Try exchanging the cable against another type/brand of flat-ribbon-cable.

Is the flat-ribbon-cable at some point parallel to a conducting grounded surface?
F. Try a different routing of your flat-ribbon-cable away from a ground-plane,

Was the cable cut apart and/or rolled it to get a rounded cable?
G. Unroll it and try B., if cut apart then start with A.

Is the drive mounted in a removable drive rack?
H. Remove HDD from the drive-bay and start with A.


well so much for not going on a rant
And this isnt just my opinion, and Im not wrong :p


However you should checkout the section in Dansdata's "IDE Fancy Leads, the terrible truth" as to why with all this goin on,
for the most part, it still works anyway :p

Check out what your chipset has to sort out here
http://www.vicstech.com/en/rd3xp/NoiseTest/
click on a picture to see an animated test
(note not all types of cables where employed, for instance there are no high quality TPO or teflon cables in this test)

like the Power Supply, cables are widely underated as a source of problems, and few ever spend any money on them for anything but "looks"


---------------------------------------------------------------------------------


http://www.lostcircuits.com/advice/ibm_maxtor/4.shtml


TRAS Violation: The Creeping Corruption of a HDD

One of the most common reasons for HDD failure is what is called tRAS violation. tRAS is the minimum bank open time of the DRAM, that is, we are talking about system memory here. Many mainboard manufacturer still include Ultra and Turbo settings in their CMOS setup options that are only workable at 100 MHz memory bus settings, a.k.a PC1600 mode. One setting that has absolutely no impact on performance is the minimum bank open time or tRAS, while the same setting can have catastrophic consequences for data integrity including HDD addressing schemes if the latency is set too short. In theory, tRAS can be as short as tRCD + CAS delay, however, in reality, the minimum bank open time is dictated by the RAS Pulse Width, that is the time required to reach a voltage differential between memory bitlines and reference lines to safely identify a 0 or 1 logical state.

The main reason why tRAS violation does commonly lead to HDD corruption may relate to the translation of the physical memory space into virtual memory sub-spaces by the operating system and finally writing the data back to the storage media but it is not entirely clear what is going on there. A fact is, though, that a tRAS value of 5 is adequate for PC1600 or 100 MHz operation. At 133 Mz or PC2100, tRAS should never undercut 6T, likewise, at PC2700, the value should be increased to 7T where applicable. In terms of performance, tRAS settings hardly make any difference. We challenged some performance gurus at AMD on this matter and they reported a drop in Quake frame rates from 792 fps to 790 fps when increasing tRAS from 5T to 6T.
Click to expand...

BIOS Guide (where I originally read it)
http://www.lostcircuits.com/advice/bios2/7.shtml

tRAS violation as a cause of data corruption

"Bank cycle time tRC (SDRAM active to precharge time), tRAS
[5T, 7T], [7T ,9T] (Intel i815 chipset)
[5T, 7-8T], [6T ,8-9T] (VIA chipsets)
[3-10T, 4-15T] ALiMAGiK1 chipset

The bank cycle time (tRAS) specifies the number of clock cycles needed after a bank active command before a precharge can occur. In other words, after a page has been opened, it needs to stay open a minimum amount of time before it can be closed again. tRC specifies the minimum cycle time until the same bank can be reactivated. Since a precharge has a latency of 2 or 3 cycles, Trc is the sum of tRAS and RAS precharge time (tRP). The Intel i815 chipset allows for 5T,7T and 7T,9T, that is, 7 or 9 cycles bank cycle time, that is, tRP is fixed to 2T. The VIA chipsets offer tRAS values of 5T and 6T and allows to set tRP to 2 and 3 cycles, respectively but they are generally not directly accessible but part of a coctail of settings
Most current high-end SDRAM is specified at about 50-60 ns cycle time. In turn, this means that, theoretically, at up to 133 MHz (7.5ns clock cycle), it is possible to run at a Trc of 7T (7x7.5ns=52 ns). If the clock frequency is increased, the number of cycles has to be increased, too, in order to provide the 50 ns. In other words, the theoretical limitation of the memory speed is somewhere around 183 MHz (9x6ns = 49.2ns). Interestingly, in the early revisions of the i815 chipset boards the bank cycle times were specified as [5T, 7T] and [6T, 8T] which would limit the memory bus to approximately 166 MHz.
For 100 MHz memory bus speed, in order to get best performance, the bank cycle time should be set to 5/7, for the 133 MHz memory bus, it needs to be set to 5/8 or else to 6/8, depending on how much overclocking is involved.

Why is there a minimum bank cycle time and what is tRAS violation?

After the RAS activates a bank, the data are latched onto the sense amplifiers. The signal is measured as the potential differential between two lines, wordlines and wordlines running in parallel where one of them is the signal and the other is the reference. This is not hardwired but works like line interleaving where each line can be the signal and the other one is the reference.

The sense amplifiers sense the voltage differential (the charge released by the memory cell / capacitor onto one wordline) between the charged wordline and the reference wordline and amplify it. This signal can be relatively weak but at the same time it also needs to be restored in the memory cell. This requires amplifying the signal a bit more (up to ca. 2 V). The wordlines themselves have a certain capacitance which slows down the charging up (on average around 30-40 ns).

If a precharge occurs (to wipe all the information from the wordlines for the next bank activate / row access), before the signal is strong enough to restore the original content in the memory cell, "tRAS is violated", resulting in loss or corruption of the data. Often enough, the corruption of data is not enough to crash a system immediately, however, once the data is written back to the HDD, the drive content is corrupted as well which can cause failure of the operating system or even "bad sectors" on the hard disk drive.

To summarize, tRAS is the time necessary to develop the full charge of the wordlines lines and restore the data in the memory cells before a precharge can occur. A precharge is the command that closes the page or bank, and therefore tRAS is also defined as the minimum page open time. If one adds the precharge (tRP) you end up with the total number of clocks required for opening and closing a bank, in other words the bank cycle time or tRC.

Refresh Interval (15.6 µsec)

Because capacitors are leaky, it is necessary to restore their content in 64 msec intervals, as defined by JEDEC standards. The refresh works by reading the data into the sense amps and then, without outputting them, moving them back into the memory cells. A typical memory chip contains 4k or 8k rows (4096 or 8192 rows). Opening a row will allow to refresh all cells within this row simultaneously. However, this also causes increased power consumption. This means that the best scheme for refreshing is not to refresh all rows at a time but to use an alternate refresh protocol, meaning that the best way to distribute the individual refreshes is to divide the 64 msec by the number of rows:


64000 µsec / 4096 = 15.6 µs
Consequently, a refresh command needs to occur every 15.6 µsec to service a single row. If there are more than 4k rows / chip, either 2 rows can be serviced with each command, or else, the refresh frequency needs to be doubled. Some BIOS offer the possibility to select the refresh frequency in µsec intervals. As a rule of thumb, for all current DIMMs the longest value of 15.6 µsec is adequate. As SDRAM densities will increase towards 1 GB / DIMM, it will become necessary to shorten the refresh interval since more address lines will need to be served.

SDRAM PH limit

Refreshing is, at present, an almost negligible factor (less than 1% performance hit), however, as explained above, with increasing DIMM density, refreshing will increasingly gain importance. As mentioned above, the need for refreshing originates in the fact that capacitors lose charge and, thus, the information will expire after a certain time. The same paradigm applies to an open page since the sense amps can hold the high or low (I or O) of the information only for a limited time. In order to maintain integrity of the data, because they also have to be restored to the original memory cells, it is necessary to limit the open-time of a page. Some chipsets (BIOS) offer the option of setting the page hit limit (PH-limit), in the case of the original AMD 751 Irongate North Bridge, this limit can be selected between 8 and 64 page hits before mandatory closing of the page.

SDRAM idle cycle limit

Some BIOS interfaces offer the selection of specifying the SDRAM idle cycle limit. The idle cycle limit is the number of clock cycles that a page is allowed to stay open even if there is no access. The relevance of this setting is that in cases where intermittent accesses to the cache are made or else, the CPU does not issue any read requests, the controller is still able to go back to the same page even after some idle cycles. Whether setting the idle cycle timer shorter or longer results in more performance, depends on the application.

In Server-specific applications where random accesses prevail, a close-page policy is always of advantage, meaning that the idle counter should be set as short as possible.
In applications that are using data streams, an open page policy will yield the highest performance, that is, the counter should be set to a high value. There are trade-offs if the counter is set too high since it may interfere with DRAM refresh. Empirically, we have found that a value between 16 and 64 cycles will give the highest performance in e.g. gaming applications
Bank interleaving

Older DRAM chips with limited density, that is 16 Mbit or less used a single block of DRAM array inside their chips. With the migration to 32 Mbit, this array was split into two internal blocks or banks and all DRAM chips of 64 Mbit or higher are composed of four internal banks or blocks of DRAM that are separated by the central routing of the core logic and I/O traces.

The splitting of the banks into four quarters also allows to use the so-called "bank-select" pins on the DRAM chips open all four internal banks which means that on a per chip basis four pages can be open at any time. This, in turn, allows access to 4 times as many data without having to change the actual address of the data's location (the row and column addresses are shared between all four blocks). As a consequence, the controller can jump from one internal bank to the next in order to get the next set of data. This is called bank interleaving and has the additional advantage that each internal bank can be closed while data are still being output from the other banks. As a consequence, there will be no precharge latency in case of a page miss. Opening all four internal banks cannot be done at the same time, though, there is a one-cycle delay for every bank to which a bank activate command is issued. On the other hand, if the controller knows that the next set of data is going to be in a different bank, it can issue read commands to the next location without trashing the first bank's data burst. This way, there is the possibility to hop from one bank to another with only one penalty cycle (bank-to-bank latency) between four word bursts. In addition, as already mentioned, precharge or bank closing can run in the background of readouts from alternating banks. Settings supported are:

No interleaving
2-way interleaving (data are toggled between 2 banks, not applicable for most modern DRAMs)
4 way interleaving (data are toggled between 4 banks)
Note that many BIOS interfaces still call it 2-way or 4-way interleaving which is blatantly wrong parlance. Moreover, a correct BIOS implementation should be able to read the memory's SPD and determine the DRAM size, and then offer the appropriate setting. In addition, it is hardly conceivable that there are any DIMMs in current circulation that are built on 32 Mbit technology, the maximum density of such a DIMM would be 64 MBytes.
Note also that with the next step in DRAM density, that is 1 Gbit chips, the die will be split into eight internal banks which then will enable 8-bank interleaving.

As nice as interleaving sounds, only streaming applications really take advantage of this feature. Specifically, any application heavily depending on the CPU cache will not be able to benefit from 4-bank interleaving, for the simple reason that the pages may have expired by the time the data from the cache are exhausted. In this case, bank interleaving may even cause a performance hit since a wrong bank may be open and must be closed before the next data access."


---------------------------------------------------------------------------------
 
http://ntfs.com/data-integrity.htm


An Explanation of CHKDSK and the New /C and /I Switches

<MORE

"To understand when it might be appropriate to use these switches (/C and /I) , it is important to have a basic understanding of some of the internal NTFS data structures, the kinds of corruption that can take place, what actions CHKDSK takes when it verifies a volume, and what the potential consequences are in circumventing CHKDSK's usual verification steps.

CHKDSK's activity is split into three major "passes" during which it examines all the "metadata" on the volume and an optional fourth pass. Metadata is "data about data." It is the file system overhead, so to speak, that is used to keep track of everything about all of the files on the volume. Metadata tells what allocation units make up the data for a given file, what allocation units are free, what allocation units contain bad sectors, and so on. The "contents" of a file, on the other hand, is termed "user data." NTFS protects its metadata through the use of a transaction log. User data is not so protected.

During its first pass, CHKDSK displays a message on the screen saying that it is verifying files and counts from 0 to 100 percent complete. During this phase, CHKDSK examines each file record segment (FRS) in the volume's master file table (MFT). Every file and directory on an NTFS volume is uniquely identified by a specific FRS in the MFT and the percent complete that CHKDSK displays during this phase is the percent of the MFT that has been verified. During this pass, CHKDSK examines each FRS for internal consistency and builds two bitmaps, one representing what FRSs are in use, and the other representing what clusters on the volume are in use. At the end of this phase, CHKDSK knows what space is in use and what space is available both within the MFT and on the volume as a whole. NTFS keeps track of this information in bitmaps of its own that are stored on the disk allowing CHKDSK to compare its results with NTFS's stored bitmaps. If there are discrepancies, they are noted in CHKDSK's output. For example, if an FRS that had been in use is found to be corrupted, the disk clusters formerly associated with that FRS will end up being marked as available in CHKDSK's bitmap, but will be marked as being "in use" according to NTFS's bitmap.

During its second pass, CHKDSK displays a message on the screen saying that it is verifying indexes and counts from 0 to 100 percent complete a second time. During this phase, CHKDSK examines each of the indexes on the volume. Indexes are essentially NTFS directories and the percent complete that CHKDSK displays during this phase is the percent of the total number of directories on the volume that have to be checked. During this pass, CHKDSK examines each directory on the volume for internal consistency and also verifies that every file and directory represented by an FRS in the MFT is referenced by at least one directory. It also confirms that every file or subdirectory referenced in each directory actually exists as a valid FRS in the MFT and checks for circular directory references. Finally, it confirms that the various time stamps and file size information associated with files are all up-to-date in the directory listings for those files. At the end of this phase, CHKDSK has ensured that there are no "orphaned" files and that all the directory listings are for legitimate files. An orphaned file is one for which a legitimate FRS exists, but which is not listed in any directory. When an orphaned file is found, it can often be restored to its rightful directory, provided that directory is still around. If the directory that should hold the file no longer exists, CHKDSK will create a directory in the root directory and place the file there. If directory listings are found that reference FRSs that are no longer in use or that are in use but do not correspond to the file listed in the directory, the directory entry is simply removed.

During its third pass, CHKDSK displays a message on the screen saying that it is verifying security descriptors and counts from 0 to 100 percent complete a third time. During this phase, CHKDSK examines each of the security descriptors associated with each of the files and directories on the volume. Security descriptors contain information regarding the owner of the file or directory, NTFS permission for the file or directory, and auditing information for the file or directory. The percent complete in this case is the percent of the number of files and directories on the volume. CHKDSK verifies that each security descriptor structure is well formed and internally consistent. It does not verify that the listed users or groups actually exist or that the permissions granted are in any way appropriate.

The fourth pass of CHKDSK is only invoked if the /R switch is used. /R is used to locate bad sectors in the volume's free space. When /R is used, CHKDSK attempts to read every sector on the volume to confirm that the sector is usable. Sectors associated with metadata are read during the natural course of running CHKDSK even when /R is not used. Sectors associated with user data are read during earlier phases of CHKDSK provided /R is specified. When an unreadable sector is located, NTFS will add the cluster containing that sector to its list of bad clusters and, if the cluster was in use, allocate a new cluster to do the job of the old. If a fault tolerant disk driver is being used, data is recovered and written to the newly allocated cluster. Otherwise, the new cluster is filled with a pattern of 0xFF bytes. When NTFS encounters unreadable sectors during the course of normal operation, it will also remap them in the same way. Thus, the /R switch is usually not essential, but it can be used as a convenient mechanism for scanning the entire volume if a disk is suspected of having bad sectors.

The preceding paragraphs give only the broadest outline of what CHKDSK is actually doing to verify the integrity of an NTFS volume. There are many specific checks made during each pass and several quick checks between passes that have not been mentioned. Instead, this is simply an outline to the more important facets of CHKDSK activity as a basis for the following discussion regarding the time required to run CHKDSK and the impact of the new switches provided in SP4"

MORE>


Description of Enhanced Chkdsk, Autochk, and Chkntfs Tools in Windows 2000
 
There's a fine line between performance and watching your data go up in smoke, sometimes just a few bits at a time, all without you realizing it. Some of us have had our flings with high performance and come back to robustness. You only lose a few percent on overall system performance by using things like ECC and more sane timings, but you gain a lot of insurance against data loss. As your data becomes more valuable over time, this is a big thing. There's a big difference between 'Oh noes! My mp3z are c0rrupz0red', 'whoops, there goes my 20-page research paper', and 'crap, the source for the app someone is paying me $4000 to write just got hosed'.
 
Originally posted by Snugglebear
There's a big difference between 'Oh noes! My mp3z are c0rrupz0red', 'whoops, there goes my 20-page research paper', and 'crap, the source for the app someone is paying me $4000 to write just got hosed'.
Click to expand...

Amen Brother,
Can I get a Hallelujah
:p
 
My timings are all looser than the manufactuer suggested for Corsair...I have 2.5, 3, 3, 8 while the XMS ram that I have is advertised at 2, 3, 3, 6.

I find it hard to believe my tRas timings are too tight...

However, I just woke up and only browsed what Ice Czar gave me...I will have to read it more thoroughly when I am more awake, but let me know if i am off-base with what I said about my ram timings...
 
Originally posted by Snugglebear
There's a fine line between performance and watching your data go up in smoke, sometimes just a few bits at a time, all without you realizing it. Some of us have had our flings with high performance and come back to robustness. You only lose a few percent on overall system performance by using things like ECC and more sane timings, but you gain a lot of insurance against data loss. As your data becomes more valuable over time, this is a big thing. There's a big difference between 'Oh noes! My mp3z are c0rrupz0red', 'whoops, there goes my 20-page research paper', and 'crap, the source for the app someone is paying me $4000 to write just got hosed'.
Click to expand...

This is true, but as of right now, its all about mp3's and pornos. I just like being able to see jenna jameson without huge pixelated neon green corruptions all over her.
 
It is worth noting three things:

1. Both of my drives use the Abit "Serillel" SATA-ATA converters.

2. Only my second drive is causing data corruption.

3. Both partitions in my second drive are compressed in NTFS. The primary drive is uncompressed.

It may also be worth noting that there are files on the second drive that "Cannot be deleted". When researching this, I find that this is caused by a corrupted partition table. Would this drive benefit from a repartitioning? Does anyone think that the compression may be causing the data corruption?
 
Move what you can to the 40gig and see if they play fine, if they do back up as much as you can to the 40gig, burn a CD/DVD and then reformat the 80gig. Then throw some files on to it and see how they work.
 
Files which cannot be deleted can also sometimes be attributed to over-max length filenames. I dunno how these files get created, but once they have been they can't be deleted without using the CLI...
 
If both drives are using the adapters, try swapping them and see what happens. As for the drive compression thing... why? You're having the OS try to compress precompressed data types. That will certainly add some hiccuping into the loop, but not to the extent you're experiencing.
 
Originally posted by Snugglebear
If both drives are using the adapters, try swapping them and see what happens. As for the drive compression thing... why?
Click to expand...

This is true.
 
Originally posted by dewhite
Files which cannot be deleted can also sometimes be attributed to over-max length filenames. I dunno how these files get created, but once they have been they can't be deleted without using the CLI...
Click to expand...

http://support.microsoft.com/default.aspx?scid=kb;EN-US;180410

Usually why you get those 'too long' errors. I don't know how the files or folders get created either, but that should let you get around both.

It is a sticky, and I couldn't just leave that unresolved ;)
 
Originally posted by KingPariah777
I have a Western Digital 80 gig hard drive that has been in my machine for about 2.5 years, and it seems that whenever I transfer large files onto or off of the drive, they become corrupted. In addition, my Overnet transfers often can't finish because of massive corruptions in them.

Video files look beautiful on my primary 40 gig Maxtor, but as soon as I move them to my 80 gig, they become corrupted and almost unwatchable. Sometimes they freeze or refuse to load.

Some files never leave the drive, and have been on it for years. These files work fine.

I haven't formatted or repartitioned the drive ever since I first got it. Do you think it needs something simple like that, or are my problems more major?
Click to expand...

Are the drives on the same ribbon ? some ata100 drives dont play nice with older 5400 rpm ata66 drives or your using the old ribbon from the 5400 ? drives that would not bode well with a drive that requires the 80 pin type (your 7200)
 
Originally posted by jacuzz1
Are the drives on the same ribbon ? some ata100 drives dont play nice with older 5400 rpm ata66 drives or your using the old ribbon from the 5400 ? drives that would not bode well with a drive that requires the 80 pin type (your 7200)
Click to expand...

SATA
 
I tried RAID 0 the other day, and it was so corrupted that I couldn't load the OS...(RAID 0 used my second 80 gig drive as part of the main HDD-0)

I can only assume that the errors continue even after reformatting and repartitioning.

I have not switched the SATA cables and adapters yet...that will come soon...

But in the meantime, is there a peice of software that I can run that can possibly VERIFY that I am getting corruption on my 80 gig drive?
 
im almost positive that it is the partitions, just copy what you can, and burn the rest and format the shit outa that drive, and use just one partition. raid doesnt realy work very well with out 2 identical drives, it will work, but at the lowest/smallest factor of both drives, and i wouldnt recommend it.
 
Originally posted by KingPariah777
But in the meantime, is there a peice of software that I can run that can possibly VERIFY that I am getting corruption on my 80 gig drive?
Click to expand...

Haxial Hash or any other checksum would allow you to compare the source file (on a known good HDD) and a copy on the suspect drive

ATACT (Free Demo Version)
ATA Command Test
A random location and random data write/read test for ATA hard disk drives but it also issues all the other "standard" ATA commands including power management commands. ATACT uses the ATADRVR to perform the actual low level ATA I/O functions.

I still havent got around to running this, download, change the .UG files to .txt and read the assorted instructions
as far as ru7nning on a RAI(D controller
I have no idea
 
Originally posted by Ice Czar
Haxial Hash or any other checksum would allow you to compare the source file (on a known good HDD) and a copy on the suspect drive

ATACT (Free Demo Version)
ATA Command Test
A random location and random data write/read test for ATA hard disk drives but it also issues all the other "standard" ATA commands including power management commands. ATACT uses the ATADRVR to perform the actual low level ATA I/O functions.

I still havent got around to running this, download, change the .UG files to .txt and read the assorted instructions
as far as ru7nning on a RAI(D controller
I have no idea
Click to expand...

THANKS! I will give this a try!
 
You must log in or register to reply here.
Back
Top