damaged vfat and gam_server

[Ian Malone]

(Follows on from the previous thread "hard disc health checks".
Thanks again to the people who responded on that thread.)

(This is less a request for help than checking whether anyone
is interested about an odd fat corruption.  Most people can
stop reading here.)

As far as smartctl, the Hitachi fitness test and read-only
badblocks can tell me, the drive is physically fit.  However
the fs seems to be damaged.

There are a number of things that could have caused this:
1. crashes during windows scandisk and defrag
2. generation of lots (O(10000)) of "lost chain" files in
    the root directory by scandisk or fsck.vfat (dosfsck),
    now removed.
3. bug in fsck.vfat (it is supposedly in alpha)
4. other.

Symptoms:
1. Windows scandisk now claims that there is insufficient
    memory to scan the drive.  It does not claim this when
    run on the windows partition on /dev/hda (the other
    drive in the machine, smaller: 80GB partition vs 160GB).
2. DOS scandisk found some problems with directories in the
    root dir and claimed to fix them.
3. Linux ls _on the root directory only_ has a noticeable
    delay before bringing up the listing.  There are only 41
    entries including hidden directories (inc . ..).  I put
    together a basic ls using opendir and readdir, apparently
    opening the root directory is what takes the time.
4. Opening the drive or any subdirectories in nautilus
    results in the system slowing to a crawl.  Like ls,
    nautilus takes a long time to get the file listing.
    Once it has the file listing up, gam_server takes
    ~100% CPU.
5. Loss of data, some files given generic names, others
    now filled with zeros.

1&2 suggest something LFN related.

To me it looks like there are a stack of invalid entries
in the root of the filesystem and gam_server is processing
them every time it is polled.  I don't know how to check
that hypothesis though.  If they're there readdir() won't
find them because they won't get handed to it.

I'll shortly be doing a write mode badblocks and then
starting the fs over again (once I've finished getting
non-backed-up data off).  If anyone wants to try and
work out what's happened to the fs, or knows someone
else who would, they should probably respond before
then.

-- 
imalone