• 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.

ways to test data integrity...

D

dewhite

Gawd
Joined
Sep 13, 2002
Messages
812
OK -

I have sorta a wierd problem, so I'm gonna have to go into a little detail here. It seems like I'm currupting data on the raid0 setup listed in my sig. I have a generally stable setup which can run prime95 for 24 hours. I don't have any problems with crashing etc. However, when I try to run large compressed self-executing files (read: battlefield1942 updates) they report themselves as being corrupted or damaged. I've tried downloading the files from several sources. I've also tried running them from network shares on my roommates' computers, on which they install flawlessly. Still on my machine they report as corrupt or damaged.

This really makes me wanna tear my hair out because I have done everything I can think of figure this out. I have tried running MD5 sums on large files like Linux ISOs etc. The MD5s come back clean, and when I try copying BF1942 updates from my system to the roommates they execute without trouble.

SO - I _think_ my data storage system can be eliminated from the trouble shooting loop. The question is HOW IN THE HELL can I be corrupting information in runtime while still passing prime95 with flying colors?

I guess what I'm really asking for is some advice on how to isolate the source of my problem, so that I can go about throwing enough time/money at it to fix it...
 
I gotta remember not to post semi-important questions at 3am in the morning.

_bump_

So the people who actually sleep at night can have a look at my problem!
 
Try giving memtest86/86+ a run and see what happens. It may be a transient issue, so let it run a good long time.
 
as far as a data integrity program, I don't know of one, other than large files that iclude a checksum or some type of checksum file.
 
Originally posted by Snugglebear
Try giving memtest86/86+ a run and see what happens. It may be a transient issue, so let it run a good long time.
Click to expand...
Well that officially qualifies for really wierd. I swear I just ran memtest86 a few weeks ago with no trouble. However, running the test last night beared out an error.

Who knows what this means:

Code: 
test   pass       Failing Add     good         bad          error bits    ct
2      1,2,3...   00000000410     00000410     000000414    00000004      1
This failure repeats itself on every succesive pass of test number 2. I'm guessing bad module - but how do I know which of them is toast?
 
Haxial Hash freeware

Haxial Hash is useful for verifying that a file has been downloaded correctly (the internet occasionally damages files). It is also useful in other circumstances where you want to verify the validity of a file to see whether or not it has been changed or corrupted.

_______________________________________________


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


Hey...you asked :p

regarding your latest question, test one stick at a time ;)
 
Ice Czar....that was thick real thick. ;) I know what I'm reading tomorrow during keyboarding class.
 
ICE -

I've seen you post some/all of this info for several sets of problems. While I do get that it's really important relevant information, I was thinking maybe this should be a STICKY that you could just point people towards.

What I'm taking from all this is that what feels like data corruption by the storage system often is content creation/manipulation corruption. My data is fine until I try to do something with it, at which time it becomes obfuscated to the point of uselessness.

I'm gonna head over to the O/C&C forum and pursue my memtest86 failures. Thanks again for reading and replying everyone.
 
There are a lot of transient errors. My bp6 has been acting up lately, munching OSes, data, you name it. After running all sorts of diagnostics I went through Memtest86+ and found several million errors. After further tests it turns out the board periodically flips some bits to random banks. There's no consistency to the errors outside of which bits are flipped; it happens at random times, sometimes not at all.

Since I hacked the board to use dual P3s, all memory sticks test good in other machines and in the board with a single processor, all processors test good, and all slots test good, my only remaining guess is one of the wires on the back of the CPU sockets is coming loose. If that's not it, and resoldering the joints doesn't fix the problem, that board is destined to be wall art and the chips & disk subsystem need a new home. The latter part is most depressing given that Supermicro boards are still way too damn expensive when combined with the need to upgrade to ECC modules. However, with ECC and 64/66PCI, that would be the new server here.
 
Originally posted by dewhite
ICE -

I've seen you post some/all of this info for several sets of problems. While I do get that it's really important relevant information, I was thinking maybe this should be a STICKY that you could just point people towards.
Click to expand...

actually Its supposed to be part of a FAQ Im working on, or at least the notes for a FAQ Im working on, which Ideally would be its own unique work, that credited and linked the articles its drawn from

a bit more on the transient errors Snugglebear mentioned
soft error
 
well, this is obviously a memory issue, so I'm not sure why people posted so much information on hard drive data corruption and so on (no offense or anything, it's still totaly useful info hehe)

anyway, I suggest taking out one of your modules, probably the one in your first ram slot, and running the test again to see how it goes. Based on how small the "failing address" is, it's probably within the first module (although that's assuming your mobo adds the ram up in proper order or whatever... i guess that's not really a good assumption but whatever)

messed up ram modules suck :( I bought a new pc133 dimm a few weeks ago for my web server and it was DOA.. went to get it exchanged and they were sold out! *sigh*...
 
You must log in or register to reply here.
Back
Top