Geoff Buckingham wrote:
On Thu, Sep 04, 2003 at 01:12:45AM -0700, Terry Lambert wrote:
Yes. Limit the number of CG bitmaps you examine simultaneously,
and make the operation multiple pass over the disk. This is not
that hard a modification to fsck, and it can be done fairly
quickly by
David Schultz ([EMAIL PROTECTED]) wrote:
From my brief research on the subject, the FreeBSD community
has been highly resistant to supporting third party filesystems
precisely because nobody with such needs as yours has ever
contributed the code necessary to make third party filesystem
Max Clark wrote:
Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE
could address more than 4GB of Ram.
The kernel being able to address the RAM does not meant that
the KVA+UVA space is larger than 4G. At best, you could take
the uiomove/copyin/copyout performance hit,
On Thu, Sep 04, 2003 at 01:12:45AM -0700, Terry Lambert wrote:
Yes. Limit the number of CG bitmaps you examine simultaneously,
and make the operation multiple pass over the disk. This is not
that hard a modification to fsck, and it can be done fairly
quickly by anyone who understands the
On Wed, 3 Sep 2003, Tim Kientzle wrote:
Max Clark wrote:
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
On 4 Sep 2003, at 11:53, Julian Elischer wrote:
On Wed, 3 Sep 2003, Tim Kientzle wrote:
Max Clark wrote:
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
On Thu, 4 Sep 2003, Andrew Kinney wrote:
Our experience has been that with 4GB of RAM (or more) you
really must increase your KVA to 2GB, leaving only 2GB of UVA.
So, I would concur with what Julian said.
ducks his head to avoid the rotten tomatoes that are sure to be
thrown ;-)
On Thu, Sep 04, 2003, Andrew Kinney wrote:
Our experience has been that with 4GB of RAM (or more) you
really must increase your KVA to 2GB, leaving only 2GB of UVA.
So, I would concur with what Julian said.
ducks his head to avoid the rotten tomatoes that are sure to be
thrown ;-)
Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE
could address more than 4GB of Ram.
- The PAE support allows FreeBSD machines to make use of more than 4
gigabytes of RAM. This functionality was originally written by Jake
Burkholder under contract with DARPA and Network
Max Clark wrote:
Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE
could address more than 4GB of Ram.
- The PAE support allows FreeBSD machines to make use of more than 4
gigabytes of RAM. This functionality was originally written by Jake
Burkholder under contract with
[Please, please, please fix your mailer to quote properly. It's very
difficult to read your messages.]
On Wed, Sep 03, 2003 at 11:08:28AM -0700, Max Clark wrote:
Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE
could address more than 4GB of Ram.
- The PAE support
Max Clark wrote:
Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE
could address more than 4GB of Ram.
It does. However as long as a pointer is 32 bits, your address space for
a process
is maxed out at 4G which translates to about 2.5G user after kernel and
other
Max Clark wrote:
Ohh, that's an interesting snag. I was under the impression that 5.x w/ PAE
could address more than 4GB of Ram.
It can. PAE lets the hardware address more than 4GB of RAM, but that doesn't
change how much memory you can give to any one process: a 32-bit process still
has a
Max Clark wrote:
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
14 matches
Mail list logo
