fsck.vfat malloc trouble

[Steven Mocking]

When I tried to boot into my wintendo for a little gaming this morning,
chkdsk locked up the box while checking the first percent of the disk.
Fscking it from linux _looked_ like a good idea.

This is the transcript:

roestbak:~# fsck.vfat /dev/hda1
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
65:03/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
FATs differ but appear to be intact. Use which FAT ?
1) Use first FAT
2) Use second FAT
? 1
malloc:Cannot allocate memory
roestbak:~# free
total used free shared buffers cached
Mem: 515364 489292 26072 0 3556 349524
-/+ buffers/cache: 136212 379152
Swap: 497972 248664 249308
roestbak:~#

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.

Steven.

[Michael B. Trausch]

Post by Steven Mocking
When I tried to boot into my wintendo for a little gaming this morning,
chkdsk locked up the box while checking the first percent of the disk.
Fscking it from linux _looked_ like a good idea.

[snip]

Post by Steven Mocking
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.
Steven.

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?

- Mike

[Steven Mocking]

Post by Michael B. Trausch

Post by Steven Mocking
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.

[Michael B. Trausch]

Steven Mocking wrote in

Post by Steven Mocking

Post by Michael B. Trausch

Post by Steven Mocking
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
***@nessie.cs.id.ethz.ch 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

[Steven Mocking]

Post by Michael B. Trausch
Steven Mocking wrote in

Post by Steven Mocking

Post by Michael B. Trausch

Post by Steven Mocking
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
# fsck.vfat -v -v /dev/name

roestbak:/home/ufo# fsck.vfat -v -v /dev/hda1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
65:03/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
Boot sector contents:
System ID "MSWIN4.1"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
4096 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
159760384 bytes per FAT (= 312032 sectors)
Root directory start at cluster 817325 (arbitrary size)
Data area starts at byte 319537152 (sector 624096)
39939895 data clusters (163593809920 bytes)
63 sectors/track, 255 heads
63 hidden sectors
320143257 sectors total
malloc:Cannot allocate memory

Post by Michael B. Trausch
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
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.

512 MB of RAM here. Should be more than enough.

Post by Michael B. Trausch
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.

At least you were able to find the sourcecode, which is quite a a feat
in itself. Do you help old ladies cross the street as well? Major kudos
for making the effort to look into it anway.

If there was another properly documented filesystem which would allow
cooperation with
the-operating-system-from-redmond-oregon-which-starts-with-a-w-and-ends
-with-indows I'd be more than happy to adopt it. Sadly, there doesn't
seem to be a decent alternative just yet.

[Michael B. Trausch]

Steven Mocking wrote in

Post by Steven Mocking
At least you were able to find the sourcecode, which is quite a a feat
in itself. Do you help old ladies cross the street as well? Major kudos
for making the effort to look into it anway.

LOL... I'm not out and about often enough between taking care of my son and
distance learning stuff to do that, though I've been known to help people
randomly with things IRL, as well. :-)

Post by Steven Mocking
If there was another properly documented filesystem which would allow
cooperation with
the-operating-system-from-redmond-oregon-which-starts-with-a-w-and-ends
-with-indows I'd be more than happy to adopt it. Sadly, there doesn't
seem to be a decent alternative just yet.

You should be able to use ext2 to store things and then read it with
Windows. While the people in Redmond don't support that filesystem
directly, Windows NT based systems use an IFS layer, much like Linux's VFS
layer, to read and write filesystems. There is a filesystem driver
available that reads and write ext2 filesystems:

http://ext2fsd.sourceforge.net/

You should be able to install that and gain access to ext[23] formatted
filesystems.

HTH,
Mike