My hard drive is self-destructing
Moderator: Wiz Feinberg
-
erik
- Posts: 2018
- Joined: 7 Mar 2000 1:01 am
My hard drive is self-destructing
A while back i mentioned here that i had some bad clusters on my drive. They existed in the used area. I've been starting my computer since having to hit my space bar to bypass scandisk. Just now i left the room forgetting my routuine and came back to scandisk in process. Now i have bad clusters in unused clusters. How is this possible? BTW, when i surf the net my pages in "history" are listed out of order like a shuffled deck. I'm only using about 15% of my HD. Any ideas? Erik
-
Everett Cox
- Posts: 497
- Joined: 13 Jul 1999 12:01 am
- Location: Marengo, OH, USA (deceased)
Erik--In replying to that earlier post, some of us offered good advise/suggestions that you may not yet have followed. (The thread seemed to be left 'hanging'.)
First, though, DO NOT continually bypass the ScanDisk process. A system 'flag' is set when Windows detected a problem and, probably is 'turned off' only upon the completion of ScanDisk. That may account for it trying to start at every boot-up.
It is possible that your (older?) system was configured with the hard drive formatted NOT to use 32-bit access. With a 10Gig drive, though, I suspect it SHOULD have been, and the BIOS set to use LBA (LargeBlockAccess), unless the drive was partitioned into 2 or more smaller 'drives'. Is 'C:' your only hard drive???
In my experience, ScanDisk seldom is able to really 'correct' problems, but should be run in order to, at least, re-establish conditions to allow the operating system to function. You should take the time to do a 'thorough' scan -- but DO NOT have the 'automatically fix errors' check-marked. That way, it will stop when each error is detected and you can note what files are involved. ScanDisk must be run with all app's or processes which might change the drive contents closed. (If something modifies a file during the scan, it will have to start over again.)
This is rather lengthy but I'll try to describe how the file system works.
Because it is too inefficient to read/write the files one character at a time, data is handled in 'chunks' - usually of 512 characters, or bytes. In earlier days, that was OK, but as larger drives and files became common, along with faster computers, the optimal size of the data 'chunks' increased. Untill recently, those 'chunks' were grouped together into 'clusters' of 32KB in size. That meant the SMALLEST amount of data transferred to/from a file on the drive would be 32,768 characters even if the file was intended to contain a single byte. (The 'unused' space in the 32KB cluster is left with whatever data it previously contained.) Many systems, thus, had a large amount of wasted or 'slack' space on the hard drive.
Improvements have lowered the cluster size to 4KB (4096 characters/bytes) on most current systems. The fact that the data is read/written in 'chunks', though, has not changed. MicroSoft employed the method of using a FAT (FileAllocationTable) to control how the individual pieces of a file are 'stitched' together and data integrity is preserved. A special area at the beginning of a disk and, at the beginning of each partition of the disk, is used by the system to hold the required information.
For FILE related matters, we start with the DIRECTORY. That is an area containing a table with a first-level entry for each file contained on the disk. Among other things, that entry has the file name, length, and the PHYSICAL location on the disk of the FIRST chunk of that particular file. (Or more properly, it points to the FIRST entry for that file in the FAT.)
The FAT is a table with an entry for each cluster-space on the disk in sequential order. Each of these entries contains a description of its related cluster. Among other things, there is a special byte that flags the cluster as bad - not to be written to. There are also 'to/from' addresses that tell the system there are other clusters for the file that contain preceeding or additional data.
As stated (for an existing file), the directory points to the first FAT entry for the file. If the file is short enough, the 'to' address will indicate no additional cluster-spaces required. Otherwise, the first FAT entry for the file will point to the NEXT place in the FAT relating to that same file. That entry would then have a 'from' address of the FIRST/PREVIOUS one and may or may not point to the NEXT depending on the size of the file. (Remember, the FAT entries each represent, in sequence, PHYSICAL locations on the disk.) So in this way, the system knows where the FIRST piece of a file is, has a 'chain' of the other pieces that it can follow front or back, and knows when it has reached the final piece of the file.
When WRITING file data, then, the system simply begins looking at the FAT entries in sequence. When one is found that has no 'from' address and is not flagged as BAD, the system writes the first part of the file to the PHYSICAL disk location represented by that FAT entry and puts the FAT address in the DIRECTORY. If more of the file must be written, the system searches for the next available FAT entry and adjusts the 'to/from' addresses accordingly. In this fashion, a file's individual parts might be written anywhere on the disk - seldom 'in sequence'.
The above is over simplified, but close enough.
If something happens that prevents the completion of writing a file, the FAT will likely be messed up. There will not be an entry which indicates the END of the file's chain or there will be a break in the chain of 'to/from' addresses. Sometimes a 'to' address will point to a FAT entry whose 'from' address does not match. Or two different FAT entries might point to the same one, resulting in 'cross-linked files. (That means that as one file is being read data from a different file gets accessed.)
So, we can all understand that, while inconvenient, IT IS IMPORTANT to let ScanDisk run, when prompted, and even occasionally just to 'check on things'. Once these types of errors have occured, it is usually too difficult for us to truly salvage or reconstruct a corrupted file. But we must let the system, at least, adjust the FAT so as to preclude the errors from compounding.
As much as we may complain, it is amazing that things work as well as they usually do.
--Everett
First, though, DO NOT continually bypass the ScanDisk process. A system 'flag' is set when Windows detected a problem and, probably is 'turned off' only upon the completion of ScanDisk. That may account for it trying to start at every boot-up.
It is possible that your (older?) system was configured with the hard drive formatted NOT to use 32-bit access. With a 10Gig drive, though, I suspect it SHOULD have been, and the BIOS set to use LBA (LargeBlockAccess), unless the drive was partitioned into 2 or more smaller 'drives'. Is 'C:' your only hard drive???
In my experience, ScanDisk seldom is able to really 'correct' problems, but should be run in order to, at least, re-establish conditions to allow the operating system to function. You should take the time to do a 'thorough' scan -- but DO NOT have the 'automatically fix errors' check-marked. That way, it will stop when each error is detected and you can note what files are involved. ScanDisk must be run with all app's or processes which might change the drive contents closed. (If something modifies a file during the scan, it will have to start over again.)
This is rather lengthy but I'll try to describe how the file system works.
Because it is too inefficient to read/write the files one character at a time, data is handled in 'chunks' - usually of 512 characters, or bytes. In earlier days, that was OK, but as larger drives and files became common, along with faster computers, the optimal size of the data 'chunks' increased. Untill recently, those 'chunks' were grouped together into 'clusters' of 32KB in size. That meant the SMALLEST amount of data transferred to/from a file on the drive would be 32,768 characters even if the file was intended to contain a single byte. (The 'unused' space in the 32KB cluster is left with whatever data it previously contained.) Many systems, thus, had a large amount of wasted or 'slack' space on the hard drive.
Improvements have lowered the cluster size to 4KB (4096 characters/bytes) on most current systems. The fact that the data is read/written in 'chunks', though, has not changed. MicroSoft employed the method of using a FAT (FileAllocationTable) to control how the individual pieces of a file are 'stitched' together and data integrity is preserved. A special area at the beginning of a disk and, at the beginning of each partition of the disk, is used by the system to hold the required information.
For FILE related matters, we start with the DIRECTORY. That is an area containing a table with a first-level entry for each file contained on the disk. Among other things, that entry has the file name, length, and the PHYSICAL location on the disk of the FIRST chunk of that particular file. (Or more properly, it points to the FIRST entry for that file in the FAT.)
The FAT is a table with an entry for each cluster-space on the disk in sequential order. Each of these entries contains a description of its related cluster. Among other things, there is a special byte that flags the cluster as bad - not to be written to. There are also 'to/from' addresses that tell the system there are other clusters for the file that contain preceeding or additional data.
As stated (for an existing file), the directory points to the first FAT entry for the file. If the file is short enough, the 'to' address will indicate no additional cluster-spaces required. Otherwise, the first FAT entry for the file will point to the NEXT place in the FAT relating to that same file. That entry would then have a 'from' address of the FIRST/PREVIOUS one and may or may not point to the NEXT depending on the size of the file. (Remember, the FAT entries each represent, in sequence, PHYSICAL locations on the disk.) So in this way, the system knows where the FIRST piece of a file is, has a 'chain' of the other pieces that it can follow front or back, and knows when it has reached the final piece of the file.
When WRITING file data, then, the system simply begins looking at the FAT entries in sequence. When one is found that has no 'from' address and is not flagged as BAD, the system writes the first part of the file to the PHYSICAL disk location represented by that FAT entry and puts the FAT address in the DIRECTORY. If more of the file must be written, the system searches for the next available FAT entry and adjusts the 'to/from' addresses accordingly. In this fashion, a file's individual parts might be written anywhere on the disk - seldom 'in sequence'.
The above is over simplified, but close enough.
If something happens that prevents the completion of writing a file, the FAT will likely be messed up. There will not be an entry which indicates the END of the file's chain or there will be a break in the chain of 'to/from' addresses. Sometimes a 'to' address will point to a FAT entry whose 'from' address does not match. Or two different FAT entries might point to the same one, resulting in 'cross-linked files. (That means that as one file is being read data from a different file gets accessed.)
So, we can all understand that, while inconvenient, IT IS IMPORTANT to let ScanDisk run, when prompted, and even occasionally just to 'check on things'. Once these types of errors have occured, it is usually too difficult for us to truly salvage or reconstruct a corrupted file. But we must let the system, at least, adjust the FAT so as to preclude the errors from compounding.
As much as we may complain, it is amazing that things work as well as they usually do.
--Everett
-
Mark Ardito
- Posts: 899
- Joined: 9 Aug 1999 12:01 am
- Location: Chicago, IL, USA
erik,
I have always disliked Scan Disk. I found a product many years ago called "Spin Rite" It is made by Steve Gibson at GRC It can only be used on disk partitions that are FAT. If you do purchase this product, be prepared for a LONG run time. If I remember correctly, a 20 GB Hard Drive took me 22 hours to run it. It runs in the back ground and you just turn off your monitor and check back in a day. It fixed my HD when I had tons of bad clusters. Then I backed up and reformatted.
Mark
------------------
Sho~Bud Pro I, Fender D-8 (C6&E13) http://www.darkmagneto.com
I have always disliked Scan Disk. I found a product many years ago called "Spin Rite" It is made by Steve Gibson at GRC It can only be used on disk partitions that are FAT. If you do purchase this product, be prepared for a LONG run time. If I remember correctly, a 20 GB Hard Drive took me 22 hours to run it. It runs in the back ground and you just turn off your monitor and check back in a day. It fixed my HD when I had tons of bad clusters. Then I backed up and reformatted.
Mark
------------------
Sho~Bud Pro I, Fender D-8 (C6&E13) http://www.darkmagneto.com
-
erik
- Posts: 2018
- Joined: 7 Mar 2000 1:01 am