damaged vfat and gam_server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


(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.

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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux