CHKDSK 0.1 testing results
Eric Auer <[email protected]> Mon, 11 Nov 2002 00:26:24 +0100 (MET)
| Newsgroups | gmane.os.freedos.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, I have done some tests with CHKDSK. Most of the problems are
already known, but to share them with fd-dev...
Chkdsk [<volume>] [/f] [/d <files>] [/r] [/s]
/f: attempt to fix any errors found.
/d: print out the indicated files and show the fragmentation factor.
/r: scan the data area and try to recover unreadable data.
/s: only show drive summary.
Note: if volume is ommited, the current drive is assumed.
You can use a disk image file as "volume", but you can NOT omit the
volume argument if you use any of the other switches. Then you must
mention it (like "chkdsk /f" does not work, you must say "chkdsk c: /f").
The /r switch needs explanation: Imre modelled it after the Windows 2000
meaning, it means "surface scan". Tries to read->write->read back every
sector, and if there is an error, the data on the affected cluster is
moved to another cluster (I hope the cluster is also marked as unusable,
as MS scandisk would do).
The filename selection for /d does not accept relative paths and always
acts as if you had prepended "\", so /d *.* will tell you about \*.* and
/d foo\bar will not work as you may expect.
Imre explains the "Found a number of invalid long file name entries"
message: When you delete a file that has a long file name with a tool
that does not use long file names, the orphaned long file name of the
deleted file (which should have been deleted as well) will be flagged
by this message. I recommend that CHKDSK should display the long file
name and offer to either associate it with another file or to delete
the long file name, at the choice of the user.
CHKDSK is extremely slow: On my smallest partition, and with a big
LBAcache loaded, it took 6 minutes until I got the message that it
would contain 100 directories and 1700 files.
I notice that CHKDSK does not display the actually used amount of space:
If you have two files of 100 bytes each, on a partition with 2k cluster
size, it will tell you that "200 bytes are used" and "64 bytes are used
for directories". I appreciate the output of CHKDSK, but it should display
the MS CHKDSK style output IN ADDITION (4k used, 4k in directories). Also,
CHKDSK does not count the root directory as "space used by a directory".
For FAT12/16, the root directory does indeed not consume any clusters, but
I wonder if MS CHKDSK would count the root directory!
By the way, CHKDSK reports that BITDISK is lacking a "FAT16" or "FAT12"
identification string in the boot sector. I think this should be fixed
in BITDISK.
Imre, could you point us to where in CHKDSK the most time-consuming
algorithms sit? If they implement tests that MS CHKDSK (or SCANDISK)
could not do, then they should be made optional with a command line
switch.
By the way, DOSFSCK under Linux (admittedly with a great builtin disk
driver and cache :-)) takes 0.9 seconds to check the partition TWICE
(verification pass, checks if all errors would be removed by the planned
changes to the filesystem). CHKDSK takes 357 seconds to check it ONCE.
And if you read the manual of dosfsck, you see that it checks for many
types of filesystem problems. For Imre, it might be interesting to know
that the source code (part of the DOSFSTOOLS package, check out with
www.rpmfind.net) contains some code to generate test images to test it
with.
Eric