Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE could address more than 4GB of Ram.
That's >4G of memory in the system. 32-bit processors are still limited to 4G processor address space, which means <3G per process (allowing some memory for kernel operations). You can't get around that unless you either go for a 64-bit processor or do some complex coding to break your application storage across multiple processes.
I used to work with systems where the processor address space was smaller than the physical memory. We worked out a lot of different strategies for breaking applications into multiple processes to take advantage of more physical memory. But remarkably few apps ever did utilize such tricks. In the end, it was cheaper to buy a wider processor than to retool the applications. I would be surprised if anyone went to the considerable effort of rewriting fsck just for PAE.
Even worse, as physical memory grows, so do kernel requirements. At some point, increasing the physical memory will actually reduce the memory available per process. Simply put, PAE is a band-aid that is only useful on systems that run a lot of small processes.
If fsck requires 700K for each 1GB of Disk, we are talking about 7GB of Ram for 10TB of disk. Is this correct? Will PAE not function correctly to give me 8GB of Ram? To check 10TB of disk?
You can check 10TB of disk, just not a 10TB file system.
Is there anyway to bypass this requirement and split fsck into smaller chunks? Being able to fsck my disk is kinda important.
You can split fsck into smaller chunks by splitting your filesystem into smaller chunks. Having smaller filesystems also helps if you do have a disk problem, since the problem is likely to only affect a single filesystem. (A full fsck is time-consuming; you'd like to limit it's scope as far as possible.)
There are also filesystems that claim to not require fsck. You might look into XFS, EXT3FS, or JFS and see if any of those fill the bill.
Tim
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
