chkdsk /f is enough for most purposes, unless one is having severe hard drive problems.
particularly since the only reason you would ever want to run /r (it's for Recover, Not "Repair") is if you suspect bad sectors, in which case you either waste 2-5 hours determining that- no, you don't have bad sectors, or you find that you do have bad sectors and should replace the drive. /f on the other hand fixes the file system errors that prompt the message in question. interestingly the default chkdsk that runs in this case with XP and later uses the /f switch by default.
/r should only be used if one is having serious issues with a drive- refusal to boot,strange noises, files that take a long time to access,hang or even reboot the entire PC when accessed or give a bluescreen in NTFS.SYS. Using /R in any other circumstance is just a gigantic waste of time. The only real checks that would need to be done would be those that are performed by /f (fix) which involves security descriptors, File Records, indexes, checking for recursive hard-links in directory trees (which can hang badly written programs).
/R merely adds an additional (and overly long and arduous) phase to a set of checks that are already performed. without /f or /r, chkdsk runs in read-only mode, where it will tell you about file system errors but will not open the volume for writing and thus will not open them. This Serves a purpose quite plainly since opening a entire volume for write access requires that all handles to that volume be invalidated (force closed) and the volume essentially being "dismounted" from the system. Since not all people will have the privileges (user account wise) nor the desire to do so, running without switches can be used to determine if a more thorough check needs to be done. the boot-time autochk does open the volume for writing and fix errors, though.
Autochk and Chkdsk are functionally identical.
Whatever the case, chkdsk always runs through at least 3 phases. In The first phase Chkdsk states that it is "verifying files" and counts a percentage completion. During this time, it examines each File Record segment in the Master File Table. All files and folders/Directories on an NTFS volume are uniquely identified by a FRS in the MFT, and the percent completion that is displayed during this phase is the percentage of those records that have been verified. Verification of each record entails chkdsk examining each FRS for internal consistency and builds two bitmaps- one representing those FRS's in use, and the other representing what clusters on a volume are currently in use. When chkdsk is finished with this phase, it now knows what space is in use and what space is available both within the MFT and on the volume itself. NTFS keeps track of this information in bitmaps of it's own that are stored on the disk; chkdsk compares what it has determined to be true and what the on-disk bitmap metadata says and corrects any issues it finds in the on-disk bitmap (of course it merely reports the discrepancy without /f). Issues of this sort are in cases such as 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 "in-use" according to the on-disk bitmap that NTFS maintains.
It's task still only just begun, Chkdsk displays that it is now "verifying indexes" and repeats the 0 through 100% progress. During this phase, it examines each of the indexes stores on the volume. An "Index" is essentially an NTFS directory and the percent completion that CHKDSK shows during this time is the percentage of the total number of directories on the volume that have been examined. It Examines each directory(index) on the volume for internal consistency and also makes sure that every file and directory represented by an FRS in the MFT is referenced by at least one directory. Since it's in the neighborhood it also confirms that the various timestamps and size information associated with the files are up to date in the directory listings for those files. When it completes this phase, CHKDSK has ensured that no "orphaned" files (files that exist on the drive but have no directory and thus are inaccessible) exist and that all the directory listings are for legitimate files. Orphaned files can often be restored to their 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 (found.000, found.001, found.002, etc anybody?). 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.
The third phase verifies security descriptors. I imagine this merely makes sure there are no crazy values or corrupted entries.
All three of these phases take place regardless of the switches passed. /R does not need to be specified to invoke "repairs". /f is required for it to open the volume for writes and make the appropriate changes, otherwise it merely reports what it found.
/R only adds a fourth phase. The surface scan. Basically this simply finds bad sectors in the volume's free space. This is accomplished by chkdsk reading every single sector on the volume to confirm that the sector is usable. Sectors associated with metadata and FRS entries and so forth were read in the natural course of run chkdsk without /R; Sectors associated with user data are read during earlier phases(when convenient) if /R is specified. Either way, when an unreadable sector is located, NTFS with add the cluster containing that sector to it's list of bad clusters and, if the cluster was in use, allocate a new cluster to do the job of the old. If a proper Disk driver is being used, the new cluster is written with data that is recovered from the driver for the associated cluster; otherwise chkdsk just writes a bunch of 0xFF bytes. Note that this is hardly a function that is only unique for chkdsk; NTFS performs this exact same function during the course of normal operation and remaps them in exactly the same fashion; /R should therefore only be used if a volume is suspected of having bad sectors, not just because so many fallacy filled sites ascribe that "it's a good maintenance procedure". Bad sectors don't just appear out of nowhere; disk performance slows down as the disk itself has it's own remapping that is otherwise invisible to the operating system. As the hard disk uses up it's "reserve" space for remapping bad disk areas, only then do disk errors start becoming visible to the operating system, So if a modern drive has a single bad sector detected by /r (or any disk scan utility) you are almost guaranteed that that drive has tens, if not hundreds more that the disk itself had remapped during it's lifetime. Each time the disk itself has to remap some information there will be a perceivable delay- the entire system may even become unresponsive for a few moments. Performing a chkdsk /r at this time will tell you you have "no bad sectors" (after several hours of doing nothing, of course) which is patently false. So aside from being entirely unnecessary the /r switch can also give people with hard drives that are slowly failing a false sense of security that the drive is perfectly fine.
