7

I have a large set of data (about nine million files of various sizes and types; mostly student home directories) and when I run chkdsk on the volume it spends a long time on a particular index. By "a long time" I mean several hours, a substantial fraction of the total time the chkdsk takes. During most of the chkdsk you can see progress every second, but at a particular index number it just stops. If I do a chkdsk again (without any changes to the data) it stops at the same number.

I've moved the data from one volume to a newly formatted one, and the same thing happens there. As I delete chunks of the data, the chkdsk time becomes shorter, but there is still a single index that takes a sizable fraction of the total time right up to the point where the disk is nearly empty. The index number in question changes sometimes when I delete a chunk of data.

Is this normal behaviour? Can anyone explain it? Is there a special index that contains all files, or something along those lines?

Harry Johnston
  • 5,875
  • 4
  • 35
  • 52

1 Answers1

1

If indexation has been actived on your hard drive then there is an index table with has the location of every file on your hard drive for future research queries. This index table can be relatively big depending on your hard drive size and whatnot.

If indexation is NOT activated, i'm not entirely sure what could cause this issue. You could be experiencing corruption of data, perhaps there is something wrong with a particular cluster or other HDD issues.

Dexirian
  • 430
  • 2
  • 11
  • 1
    I don't believe that the Index Service uses an NTFS index (and I already tried turning it off IIRC). It can't be a HDD issue because the data was moved to a new HDD without changing the results. I now suspect that this is simply an artifact of the way chkdsk handles rigorous index checking; for example, it may be loading as much metadata as it can into memory and then processing it. The issue goes away if you use the `/I` switch. – Harry Johnston Oct 17 '13 at 19:43