damaged vfat and gam_server

From: Ian Malone (ibm21_at_cam.ac.uk)
Date: 10/29/05

  • Next message: Dotan Cohen: "Re: Linux killer!" 
    Date: Sat, 29 Oct 2005 17:31:29 +0100
To: For users of Fedora Core releases <fedora-list@redhat.com>

    (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
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Dotan Cohen: "Re: Linux killer!"