Jump to content

Welcome to Geeks to Go - Register now for FREE

Geeks To Go is a helpful hub, where thousands of volunteer geeks quickly serve friendly answers and support. Check out the forums and get free advice from the experts. Register now to gain access to all of our features, it's FREE and only takes one minute. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more.

Create Account How it Works
Photo

Unable to Defrag my HD - Chkdsk is scheduled prob


  • Please log in to reply

#16
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
When running Speedefrag I always use the letter A

And after the first time of running it it is a lot quicker so hopefully it has done something.

Silly question time:

In the Tweaks section is the following

CHKDSK - Check the hard disk drive running FAT for errors.
CHKNTFS - Check the hard disk drive running NTFS for errors

My G: drive is NTFS so why is it asking me to run Chkdsk?
  • 0

Advertisements


#17
Retired Tech

Retired Tech

    Retired Staff

  • Retired Staff
  • 20,563 posts
What do you get if you set Speedefrag to G only

Check Disc is the only game in town irrespective of the drive being FAT or NTFS

Understanding what CHKDSK does

CHKDSK's activity is divided into three major passes, during which CHKDSK examines all the metadata on the volume, and an optional fourth pass.

Metadata is "data about data." Metadata is the file system "overhead," so to speak, that keeps track of information about all of the files that are stored on the volume. Metadata includes information about 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 data that the file contains, on the other hand, is termed "user data." NTFS protects its metadata through the use of a transaction log. User data is not protected in this way.
Phase 1: Checking files
During its first pass, CHKDSK displays a message that tells you that CHKDSK is verifying files and also displays the percent of verification that is completed, counting from 0 to 100 percent. During this phase, CHKDSK examines each file record segment in the volume's master file table (MFT).

A specific file record segment in the MFT uniquely identifies every file and directory on an NTFS volume. The "percent completed" that CHKDSK displays during this phase is the percentage of the MFT that CHKDSK has verified. During this pass, CHKDSK examines each file record segment for internal consistency and builds two bitmaps, one representing the file record segments that are in use and the other representing the clusters on the volume that are in use.

At the end of this phase, CHKDSK has identified the space that is in use and the space that is available, both within the MFT and on the volume as a whole. NTFS keeps track of this information in bitmaps of its own, which are stored on the disk. CHKDSK compares its results with the bitmaps that NTFS keeps. If there are discrepancies, the discrepancies are noted in the CHKDSK output. For example, if a file record segment that was in use is found to be corrupted, the disk clusters that were associated with that file record segment are marked as "available" in the CHKDSK bitmap but are marked as "in use" in the NTFS bitmap.

Phase 2: Checking indexes

During its second pass, CHKDSK displays a message that tells you that CHKDSK is verifying indexes and again displays the percent completed, counting from 0 to 100 percent. During this phase, CHKDSK examines each of the indexes on the volume.

Indexes are essentially NTFS directories. The "percent completed" that CHKDSK displays during this phase is the percentage of the total number of the volume's directories that have been checked. During this pass, CHKDSK examines each directory that is on the volume, checking for internal consistency and verifying that every file and directory that is represented by a file record segment in the MFT is referenced by at least one directory. CHKDSK confirms that every file or subdirectory that is referenced in a directory actually exists as a valid file record segment in the MFT and also checks for circular directory references. Finally, CHKDSK confirms that the time stamps and file size information for the files are up-to-date in the directory listings for those files.

At the end of this phase, CHKDSK has made sure that there are no "orphaned" files and that all directory listings are for legitimate files. An orphaned file is a file for which there is a legitimate file record segment but for which there is no listing in any directory. An orphaned file often can be restored to its proper directory if that directory still exists. If the proper directory no longer exists, CHKDSK creates a directory in the root directory and places the file there. If CHKDSK finds directory listings for file record segments that are no longer in use, or for file record segments that are in use but that do not correspond to the file that is listed in the directory, CHKDSK simply removes the directory entry for the file record segment.

Phase 3: Checking security descriptors

During its third pass, CHKDSK displays a message that tells you that CHKDSK is verifying security descriptors and, for the third time, displays "percent completed," counting from 0 to 100 percent. During this phase, CHKDSK examines each security descriptor that is associated with files or directories that are on the volume.

Security descriptors contain information about ownership of a file or directory, about NTFS permissions for the file or directory, and about auditing for the file or directory. The "percent completed" that CHKDSK displays during this phase is the percentage of the volume's files and directories that have been checked. CHKDSK verifies that each security descriptor structure is well formed and is internally consistent. CHKDSK does not verify the actual existence of the users or groups that are listed or the appropriateness of the permissions that are granted.

Phase 4: Checking sectors

If the /R switch is in effect, CHKDSK runs a fourth pass to look for bad sectors in the volume's free space. CHKDSK attempts to read every sector on the volume to confirm that the sector is usable. Even without the /R switch, CHKDSK always reads sectors that are associated with metadata. Sectors that are associated with user data are read during earlier phases of CHKDSK if the /R switch is specified.

When CHKDSK finds an unreadable sector, NTFS adds the cluster that contains that sector to its list of bad clusters. If the bad cluster is in use, CHKDSK allocates a new cluster to do the job of the bad cluster. If you are using a fault-tolerant disk, NTFS recovers the bad cluster's data and writes the data to the newly allocated cluster. Otherwise, the new cluster is filled with a pattern of 0xFF bytes.

If NTFS encounters unreadable sectors during the course of normal operation, NTFS remaps the sectors in the same way that it does when CHKDSK runs. Therefore, using the /R switch is usually not essential. However, using the /R switch is a convenient way to scan the entire volume if you suspect that a disk might have bad sectors.

Understanding CHKDSK time requirements

The preceding description of the phases of running CHKDSK gives you only a broad outline of the most important tasks that CHKDSK performs to verify the integrity of an NTFS volume. CHKDSK also makes many additional specific checks during each pass and several quick checks between passes. However, even such a broad outline provides some basis for the following discussion of the variables that affect the amount of time that CHKDSK takes to run and of the impact of the new /C and /I switches that are available in Windows XP.

Variable 1: The "Indexes" phase

During the first and third phases of running CHKDSK (checking files and checking security descriptors), the progress of the "percent completed" indicator is relatively smooth. Unused file record segments do require less time to process, and large security descriptors do take more time to process, but overall the "percent completed" is a fairly accurate reflection of the actual time that the phase requires.

However, this percentage/time relationship is not necessarily applicable to the second phase, when CHKDSK examines indexes (NTFS directories). The time that it takes to process a directory is closely tied to the number of files and subdirectories that are in that directory, but the "percent completed" during this phase is based only on the number of directories that CHKDSK must examine. There is no adjustment for how long it might take, for example, to process a directory that has an extremely large number of files and subdirectories. Unless the directories on a volume all contain about the same number of files, the "percent completed" that is displayed during this phase does not reliably reflect the actual time that the second phase requires.

To make matters worse if you are caught in the middle of an unexpected CHKDSK procedure, the second phase of CHKDSK is the one that typically takes the longest to run.

Variable 2: The Condition of the volume

Many factors that concern the state of a volume play a role in how long CHKDSK takes to run. A formula for predicting the time that is required to run CHKDSK on a given volume would have to include such variables as the number of files and directories, the degree of fragmentation of the volume in general and of the MFT in particular, the format of file names (long names, 8.3-formatted names, or a mixture), and the amount of actual damage that CHKDSK must repair.

Variable 3: Hardware issues

Hardware issues also affect how long it takes for CHKDSK to run. The variables include the amount of available memory, CPU speed, disk speed, and so on.

Variable 4: The CHKDSK settings

If you do not use the /R switch, the biggest time concern on a given hardware platform is the number of files and directories that are on the volume, rather than the absolute size of the volume.

For example, without the /R switch, a 50-gigabyte (GB) volume that has only one or two large database files might take only seconds for CHKDSK to run. If you use the /R switch, CHKDSK has to read and verify every sector on the volume, which adds significantly to the time that is required for large volumes. On the other hand, running CHKDSK on even a relatively small volume might require hours if the volume has hundreds of thousands or even millions of small files--regardless of whether you specify the /R switch.

Predicting CHKDSK time requirements

As you can see, running CHKDSK can take anywhere from a few seconds to several days, depending on your specific situation. The best way to predict how long CHKDSK will take to run on a given volume is to actually do a trial run in read-only mode during a period of low system usage.

However, you must use this technique with great care, for the following reasons: • In read-only mode, CHKDSK quits before it completes all three phases if it encounters errors in earlier phases, and CHKDSK is prone to falsely reporting errors. For example, CHKDSK may report disk corruption if NTFS happens to modify areas of a disk while CHKDSK is examining the disk. For correct verification, a volume must be static, and the only way to guarantee a static state is to lock the volume. CHKDSK locks the volume only if you specify the /F switch (or the /R switch, which implies /F). You may need to run CHKDSK more than once to get CHKDSK to complete all its passes in read-only mode.

• CHKDSK is both CPU- and disk-intensive. The time that it takes to run CHKDSK is affected by how much load is on the system and whether CHKDSK runs online or during the Windows XP startup sequence. Which factor becomes the bottleneck depends on the hardware configuration, but high CPU usage or heavy disk I/O while CHKDSK is running in read-only mode will inflate the CHKDSK running time. Also, Autochk.exe runs in a different environment from that of Chkdsk.exe. Running CHKDSK through Autochk.exe gives CHKDSK exclusive use of CPU and I/O resources, but it also prevents CHKDSK from using virtual memory. Although you might expect Autochk.exe to run faster than Chkdsk.exe, Autochk.exe may actually take longer if the computer has relatively little available RAM.

• Fixing corruption adds to the time required. In read-only mode, CHKDSK runs to completion only if CHKDSK does not find any significant corruption. If a disk shows only minor corruption, you can predict that fixing the problems will not add much to the time that is required just to run CHKDSK. But if CHKDSK finds major damage, for example from a serious hardware failure, you can predict that the time that is required to run CHKDSK will increase in proportion to the number of damaged files that CHKDSK must repair. In extreme cases, this can more than double the time that it takes for CHKDSK to run.

Introducing the /C and /I switches

The /C switch

The /C switch directs CHKDSK to skip the checks that detect cycles in the directory structure. Cycles are a very rare form of corruption in which a subdirectory has itself for an "ancestor."

Using the /C switch can speed up CHKDSK by about 1 to 2 percent, but using this switch can also leave directory "loops" on an NTFS volume. Such loops might be inaccessible from the rest of the directory tree, and some files might be orphaned in the sense that Win32 programs, including backup programs, cannot see the files.

The /I switch

The /I switch directs CHKDSK to skip the checks that compare directory entries to their corresponding file record segments. With this switch in effect, directory entries are still checked for internal consistency, but the directory entries are not necessarily consistent with the data that is stored in the corresponding file record segments.

How much time you will save by using the /I switch is difficult to predict. Typically, the /I switch lowers CHKDSK times by 50 to 70 percent, depending on factors such as the ratio of files to directories and the speed of disk I/O relative to CPU speed.

Using the /I switch has these limitations:

You may have directory entries that refer to incorrect file record segments. In this case, any program that tries to use such an entry will encounter errors.

You may have file record segments that no directory entry references (another way that orphaned files occur). A file that is actually intact, as represented by the file record segment, may be invisible to all Win32 programs, including backup programs.

The value of the /C and /I switches

When disk corruption is detected on a volume, there are three basic options for response.

The first option is to take no action. On a mission-critical server that is expected to be online 24 hours a day, this is often the choice of necessity. The drawback is that relatively minor corruption can snowball into major corruption. Therefore, consider this option only if keeping the server online is more important than guarding the integrity of the data that is stored on the corrupted volume. All data on the corrupted volume should be considered "at risk" until you run CHKDSK. The second option is to run a full CHKDSK operation to repair all file system data and restore all of the user data that can be recovered by means of an automated process. However, running a full CHKDSK operation can cost you several hours of downtime for a mission-critical server at an inopportune time. Your third option is to run an abbreviated CHKDSK operation by using one or both of the /C and /I switches, to repair the kinds of corruption that can snowball into bigger problems in much less time than a full CHKDSK requires.

Note however that running an abbreviated CHKDSK does not repair all of the corruption that might exist. You still need to run a full CHKDSK at some future time to guarantee that all recoverable data has in fact been recovered.

Note also that NTFS does not guarantee the integrity of user data after an instance of disk corruption, even if you immediately run a full CHKDSK operation. There might be files that CHKDSK cannot recover, and files that CHKDSK does recover might still be internally corrupted. It remains vitally important that you protect mission-critical data by performing periodic backups or by using some other robust method of data recovery.


Of course I just sat here and wrote that for you :tazz:
  • 0

#18
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
LOL

I didn't know you cared

Will try speedefrag to just do G: only and report back
  • 0

#19
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
Right Keith interesting development

Clicked Speedefrag

Selected G only

It rebooted the machine up to the point of Windows starting but I didn't get any box opening with Speedefrag working, then after a few seconds it turned the machine off like before but without the box making an appearance.

Before it must have been just doing the C: drive as it scrolled so fast after telling me C: was not fragmented that I couldn't tell if it had done G: or not.
  • 0

#20
Retired Tech

Retired Tech

    Retired Staff

  • Retired Staff
  • 20,563 posts
Are there any big differences in any settings for C and G
  • 0

#21
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
Just had a look in the properties part of each drive in My Computer

C: Local Disc
NTFS
Location 0 (0)

G: Local disc
NTFS
Location 0 (0)

and obviously the size of each disc is differant but everything else is the same
  • 0

#22
Retired Tech

Retired Tech

    Retired Staff

  • Retired Staff
  • 20,563 posts
Whenever you arrive at the limitations of your present knowledge on any subject, ask a woman for the answer :tazz:

I will ask Samm who is the Hardware genius

Keith
  • 0

#23
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
Cheers Keith and can I say before I get off to bed how much I appreciate the help you have given today.

The G: drive does work fine and I experience no problems but the not able to defrag is doing my head, also when Chkdsk checks the drive on all 5 elements - 4 and 5 take forever it never seems to find any problem.

Once again thanks for the effort mate.
  • 0

#24
Retired Tech

Retired Tech

    Retired Staff

  • Retired Staff
  • 20,563 posts
No problem, at least it isn't system critical, but I don't like functions on anything which do not do what they are supposed to
  • 0

#25
Samm

Samm

    Trusted Tech

  • Member
  • PipPipPipPipPipPip
  • 3,476 posts
Hi Guys

Not sure how much help I can be with this one but I'll give it a go!

Can you confirm the following please?

1. Do you have Crypkey software installed?
2. Do you use a Kensington mouse?
3. Is the G drive basic or dynamic?
4. Are you running XP Pro or Home and which Service pack?
5. What is the outcome of running the fsutil dirty query G: command?
  • 0

Advertisements


#26
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
Hi Samm thanks for helping out

1) I don't think I have any Crypkey software, have checked the running processes for e.g and nothing in there.

2) Microsoft mouse

3) Im sure the drive is Slave if that helps, it used to be an external drive but XP suddenly couldn't access the MFT, then the HD light remained permantly on, then it wouldn't acknowledge it existed at all but these were Random not all the time.

I wondered if it was the actual Caddie not the HD that was the problem and it appears it could have been the case as since I unplugged what was the internal D:\ drive ( a small 8GB HD which had nothing on it) and plugged the same cables into this G:\ drive, the HD has been fine and is accessed all right every time except for the inability to Defrag due to the message Chkdsk is scheduled to start at boot up which it isn't im sure.

4) XP Corp service pack 2

5) It tells me the drive is dirty

Hope these have helped

Rob
  • 0

#27
Samm

Samm

    Trusted Tech

  • Member
  • PipPipPipPipPipPip
  • 3,476 posts
OK, thanks for the info. I was under the impression that the G drive was simply a partition of the main hard drive, i.e one physical drive split into 2 partitions (C: & G:). Are saying then that the G drive is a physically seperate drive from the C drive & is now connected internally to the IDE ribbon cable, as opposed to being in a caddy?

Have you tried using the chkntfs /x g: command? This should disable checking at boot time for that drive.

The other thought that occurs to me, given the problems you said you had with this drive when it was in the caddy, were almost certainly due to the caddy rather than the drive itself. However, the drive may have benefitted from a complete wipe & repartition partition/format when it was moved out of the caddy. Its possible that the problem you have now is a hang over from when it used in the caddy.
  • 0

#28
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
Hi Samm

Sorry if I didn't make myself clear, no the G:\ is a totally seperate HD which was used as a External drive.

Have tried the Chkntfs /x G:\ command and it does indeed now no longer check the drive.

I also find it strange how Speedefrag doesn't seem to even recognise the drive is there, the worst bit or should I say the most infuriating bit is that the drive apart from that is working just fine.

I know a lot of people will say if its working ok then just be thankful but if I ever get to the point where I am filling the HD up a bit of a Defrag is going to come in handy.

Rob
  • 0

#29
gerryf

gerryf

    Retired Staff

  • Retired Staff
  • 11,365 posts
Rob,

I read this a couple days ago, and something has been nagging at me but I couldn't place it until just now.

Why do you have the page file on your G drive? All drives will have system volumne information, but not all will have page files.

There is certainly a reason to put a page file on a non system disk, but that could be the process that is using the disk at the time. I do not have a dual disk machine in front of me at the moment so I can test it, but it may block a defrag

Furthermore, a corrupt page file would kick out a checkdsk error.

Also Diskkeeper will not, by default, defrag a page file.

I would remove the page file in the normal way from G:, run chkdsk /r on it, then see if it will defrag in windows on reboot.
  • 0

#30
carbuncle

carbuncle

    Member

  • Topic Starter
  • Member
  • PipPipPip
  • 111 posts
Hi Gerry

I must admit I put the Paging File on there as well as the drive C:\ because I thought it helped in reading the MFT or something like that, I set it in Diskeeper so that each drive had approx 1.5 GB of Paging File.

I will remove the Paging File after reinstalling Diskeeper and run Chkdsk again and post back.

Thanks again mate

Rob
  • 0






Similar Topics

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

As Featured On:

Microsoft Yahoo BBC MSN PC Magazine Washington Post HP