If you need to run fsck on a large FreeBSD partition, you might have a bit of trouble. fsck needs a fair bit of memory to do its work, and if you don't have enough, you'll run into difficulties getting to to complete. Here are some steps to help get fsck to run:
If fsck runs out of memory, you'll see something like
fsck_ufs: cannot alloc 30326 bytes for inoinfo
or
fsck_ufs: cannot increase directory list
You need to tell the kernel that it can use more memory for a single process than it otherwise could. This is accomplished by setting kern.maxdsiz in /boot/loader.conf. By default, this 'datasize' value is set at half the installed RAM size:
[root@bergen ~]# limits Resource limits (current): cputime infinity secs filesize infinity kB datasize 524288 kB stacksize 65536 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 1789 openfiles 3578 sbsize infinity bytes vmemoryuse infinity kB
In /boot/loader.conf, you'll want to add:
kern.maxdsiz="2684354560" # 2.5GB
What values you use are up to you, but the general rule of thumb is that you need 1GB for every 1TB of partition that is filled with data. In my experience on FreeBSD 6.3, the actual number seems to be a little less than that, as I was able to fsck a 3.5TB filesystem with 2.5GB allocated.
If you have extra RAM sitting around, install it. fsck can use swap space, but that makes it run really slowly, and it is best if it can keep its data in RAM. The more RAM you have, the better.
There is one other limit to worry about. If you're using the 32-bit i386 version of FreeBSD, your system cannot by default access more than 4GB of RAM, as that is the limit of the 32-bit address space. If you set kern.maxdsiz at, beyond, or even close to 4294967296, your system may crash on boot or during fsck. Supposedly, recompiling your kernel with PAE extensions can fix this, but I've yet to try it.
If you accidentally set the limit too high, you can unset it via the boot loader:
unset kern.maxdsizboot