I've noticed several posts in this section from people still running RH9 or RH8.0 or (like me :-) RH7.3 or earlier -- cool(*). However, I did recently encounter a problem with RH7.3 using a large (>128Gb) hard disk formatted FAT32, so thought I'd pass along this warning ... applies to anyone using a kernel older than 2.4.25, at least not without patching those kernels to support large FAT32 disks.

Problem is that once a disk fills up beyond a certain point (causing sectors above the 128Gb point on the disk to start being used ?), older Linux kernels will corrupt the file directories causing newer files to be reported as having zero byte filesize. Other symptoms can include "stale NFS file handle" error messages trying to access the problem file(s) and/or folder(s). It's easy at first to mistake this for a hardware problem (e.g., one or more bad sectors on the disk), but don't be fooled -- if the kernel is older than 2.4.25, it's likely a kernel FAT32 software issue.

When I encountered this problem I was running 2.4.20-46.7 ... It's great that RedHat still considers RH7.3 and kin to be officially supported distros and still provides regular kernel patch updates for them -- addressing security issues, but apparently these updates do not address other critical(**) kernel bugs like large FAT32 support ?! So I had to track-down and apply the appropriate kernel patches myself (starting from http://www.kernel.org), and all is well now.

Here is a link to the first kernel patch (for >128Gb disks ... submitted to linux-kernel by OGAWA Hirofumi on 2003-12-22):
http://marc.theaimsgroup.com/?l=linu...2364302795&w=2

And here is a link to a second kernel patch (for >4Gb file sizes ... submitted to linux-kernel by Erik Andersen on 2003-12-31):
http://marc.theaimsgroup.com/?l=linu...6231306919&w=2

Both of these kernel patches worked fine for me starting from the latest "Fedora Legacy" RH7.3 kernel source (2.4.20-46.7) found here:
http://download.fedoralegacy.org/red...updates/SRPMS/

...and I suspect the patches would also apply fine to other 2.4.20 kernel sources.

Cheers,

-- Jim


(*) In my case it's because one of my Linux machines is a DEC Alpha workstation, for which RH7.2 is one of the more reliable Linux options, and as a newbie, trying to remember where config files etc. are located on ONE Linux distribution is hard enough, without RedHat vs. Debian vs. SUSE etc. differences adding to my confusion ! (I've NOT yet tried to configure USB support for my DEC Alpha, let alone apply these kernel source patches).

(**) Any problem that potentially leads to loss of data is "critical" by my definition.

Thanks for the solution & the well written post. I have added some, I hope appropriate, tags.

I assume your needs preclude using smaller part. sizes & avoiding the escalating inefficiencies of the FAT method. Personally, when I set up a FAT32 data exchange part. on a dual boot system, I size it at 7.9, 15.9, or once 31.9 x2^30 B. Again, I don't know what your needs are, but others reading this might want to consider this in sizing FAT partitions.

Although I left the RH fold @ 8, I started my learning of GNU/Linux on RH 7.2. I can sympathize w/ your desire to minimize inter-distro confusion.

For those too young, new, etc. to know: The 128GB above is 128x2^30 B, often called the "137GB limit". (128x2^30 ~= 137x10^9.)

A suggestion on expressing large numbers of bytes: We lost the binary vs. decimal notation war at SI some time ago. So consider the following alternatives:

• Use the "iB" units when you mean binary based.
• Put in a disclaimer that ALL your units refer to the old-fashioned, "correct" way of counting bytes
• Refuse to acknowledge the new, "incorrect" way, but eliminate ambiguity by using "x2^n0" notation.

How I Gained Many MB by Throwing a Few Away

Once I had a 540 "MB" (decimal) (514.9 binary), which was formatted w/ FAT16 (it came to me that way). I found that if I reduced the part. size to 512 (binary) the halving of the cluster size gave me back more space, way more space, than I lost to the reduction. This happened because every file system wastes an average of half a block/cluster per file, & w/ FAT16 that waste is huge at that part. size.