It is very arbitrary. But its not so easy to fix. Ok, the diff is only  
about 8 lines, but its the other things like testing and compat that  
make it hard.

On May 19, 2008, at 8:38 AM, Hannah Schroeter <hannah@schlund.de> wrote:

quoted text
> Hi!
>
> On Mon, May 12, 2008 at 05:49:57PM +0200, Otto Moerbeek wrote:
>> [...]
>
>> De fsck_ffs code allocates a number of arrays directly depending on
>> the # of indodes in setup(), totalling 4 bytes per inode. Some other
>> data is also needed, so it's not surprise you hit the 1G data space  
>> limit.
>
> Any chance to get rid of that 1G limit that seems more and more
> arbitrary nowadays? I remember reading that just upping that define in
> /usr/src/sys/arch/i386/include/vmparam.h doesn't help, i.e. that
> something else interacts with that parameter too. I know that on
> processors that have neither PAE nor non-PAE NX support one might  
> not be
> able to protect all writable data from execution eventually, if a
> program should in fact allocate more than 1G (once the kernel should
> need to allocate it with lower virtual addresses). However, the kernel
> could be made to prefer high addresses for writable, non-executable  
> data
> (mmap without PROT_EXEC), and the super-user is to decide on how she
> sets up the data size resource limits, so if that's <= 1G the  
> protection
> should remain to be fine.
>
>> [...]
>
> Kind regards,
>
> Hannah.