Re: fsck.vfat malloc trouble

Steven Mocking wrote in
<44744450.4070303@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> on Wed, May 24
2006 07:32:

Michael B. Trausch wrote:
Steven Mocking wrote in <1270qtjhr9mem6a@xxxxxxxxxxxxxxxxxx> on Sun, May
21 2006 09:31:
The boot sector difference is a non-issue. LILO doesn't overwrite the
backup, which is a sensible thing. The FAT difference is normal for a
disk which has been hit with a hamme^W^W^W^W^W spontaneously failed.

The data on that disk is safely backed up and rather useless anyway, so
reviving it won't be really necessary, but is that a memory leak in
fsck.vfat? Top shows it does indeed allocate all remaining memory. Can't
get a backtrace from it with gdb though.

How large is the filesystem? I see that it's FAT32, but how many
megs/gigs
is it? And do you know exactly how the spontaneous failure occurred?


The filesystem is 153G. How it failed is quite a mystery. However, it
_is_ a Maxtor...

I'll run badblocks overnight and see if and there are any new baddies.
If so it might be that the air bubble under the head has imploded. Or it
could be the usual radiation damage.


Alright. Something else to try is to see what happens when you run it with
the verbose options, say:

# fsck.vfat -v -v /dev/name

And see if you get anything before the malloc error. That is a rather large
filesystem. Now, looking at the README for dosfstools (where this and the
mkfs program come from), it makes no mention of memory consumption
problems.

It looks as if you may be able to contact the program's author at
almesber@xxxxxxxxxxxxxxxxxxxx and see if maybe he can help you to debug the
problem. I don't know why it would run out of memory or anything, because
it should only be looking at certain segments of the filesystem. Even in a
153GiB system, that shouldn't be all available memory, unless the memory is
quite a low amount.

There are some noteworthy bits about FAT32 filesystems with such a size.
First off, even Microsoft's ScanDisk utility won't check an FAT32 partition
that is larger then ~124.5 GB, because it doesn't handle more then 2^22
clusters, so you can't use the "reference" implementation to check such a
large filesystem. Secondly, I am not sure what the advantages of having
such a large FAT partition would be -- is there any reason that you can't
break it down into smaller FAT partitions, or use another filesystem
entirely? FAT is quite well-known for tossing its cookies all over itself,
without very much provocation at all.

Anyway, I wish that I could be of more help. I attempted to look at the
source code for the program, but C confuses the hell out of me and I've
come nowhere close to being good at reading (or writing) it yet.

- Mike

--
Registered Linux User #417338, machine #325045.

Windows: Backups are irrelevant, your hard drive will be assimilated.
.

Relevant Pages

  • Re: Scheduler: Process priority fed back to parent?
    ... > interactivity cache could estimate interactivity over a period of hours ... Then you don't even have to write it to the filesystem. ... For those of us with enough memory or a large variety of programs, ... That way the file is already in disk cache or on its way when the ...
    (Linux-Kernel)
  • Re: fsck.vfat malloc trouble
    ... Top shows it does indeed allocate all remaining memory. ... The filesystem is 153G. ... There are differences between boot sector and its backup. ... First FAT starts at byte 16384 ...
    (alt.os.linux)
  • Re: identifying a floppys filesystem type
    ... > codes (the code is not the filesystem code used by fdisk). ... interpreting the data on the disk to mean that it contains 189 FATs. ... File Allocation Table, or FAT, is a critical data structure that's lent ... Linux should be able to cope with floppies created under OS/2 just fine. ...
    (comp.os.linux.hardware)
  • Re: XFS-Partition trashed?
    ... I don't know how bad you have broken your filesystem. ... It has been quite a while since I studied the FAT filesystem. ... written after the BPB depends on the size of the disk. ... then recovery could be very difficult. ...
    (comp.os.linux.setup)
  • Re: is there a user mode way to flush disk cache
    ... I've got plenty of memory. ... If you have plenty of RAM, then why write to disk at all? ... to filesystem on the disk? ...
    (comp.os.linux.development.system)