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 <[EMAIL PROTECTED]> wrote:
Hi!
On Mon, May 12, 2008 at 05:49:57PM +0200, Otto Moerbeek wro
On 2008-05-19, Hannah Schroeter <[EMAIL PROTECTED]> wrote:
> Who does still use sbrk() after OpenBSD's malloc uses mmap only?
grepping an unpacked ports tree picks up at least emacs, spice,
boehm-gc, erlang, and some Mozilla software. Some of these are
known to use sbrk for sure, some are possible
On Mon, May 19, 2008 at 03:12:22PM +0200, Hannah Schroeter wrote:
> Hi!
>
> On Mon, May 19, 2008 at 03:00:08PM +0200, Otto Moerbeek wrote:
> >On Mon, May 19, 2008 at 02:38:35PM +0200, Hannah Schroeter wrote:
> >> On Mon, May 12, 2008 at 05:49:57PM +0200, Otto Moerbeek wrote:
> >> >[...]
>
> >> A
Hi!
On Mon, May 19, 2008 at 03:00:08PM +0200, Otto Moerbeek wrote:
>On Mon, May 19, 2008 at 02:38:35PM +0200, Hannah Schroeter wrote:
>> On Mon, May 12, 2008 at 05:49:57PM +0200, Otto Moerbeek wrote:
>> >[...]
>> Any chance to get rid of that 1G limit that seems more and more
>> arbitrary nowaday
On Mon, May 19, 2008 at 02:38:35PM +0200, Hannah Schroeter wrote:
> 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
> >
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 cha
Thanks for taking a look.
I will play with larger fragment/block sizes unless anyone suggests otherwise.
-William
On Mon, May 12, 2008 at 11:49 AM, Otto Moerbeek <[EMAIL PROTECTED]> wrote:
> On Fri, May 09, 2008 at 11:16:28AM -0400, Will wrote:
>
> > Here are the requested outputs.
>
> OK, you
On Fri, May 09, 2008 at 11:16:28AM -0400, Will wrote:
> Here are the requested outputs.
OK, your filesystem indeed uses default block and fragment sizes. The
# of inodes is about 238M.
De fsck_ffs code allocates a number of arrays directly depending on
the # of indodes in setup(), totalling 4 by
Here are the requested outputs.
output of `df -i`:
Filesystem 512-blocks Used Avail Capacity iused ifree %iused
Mounted on
/dev/sd0a 31448010115219760434%2189 23409 9%
/
/dev/sd0h 826419692 7850896 0% 20 545642 0%
/home
/dev/sd
On Thu, May 08, 2008 at 05:18:26PM -0400, Will wrote:
> I did see that, but did not realize that the 1GB limit is not a
> user-configurable feature.
>
> Even so, the FAQ implies that a 2TB filesystem is possible with
> default options, which is what I have.
It might be the 2TB limit is a little
I did see that, but did not realize that the 1GB limit is not a
user-configurable feature.
Even so, the FAQ implies that a 2TB filesystem is possible with
default options, which is what I have.
relevant output of df:
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/sd0i 375
Isn't this the 1GB application limit mentioned in FAQ 14.7 - " By the
time one gets to a 2TB file system with default fragment and block
sizes, fsck will require 1GB RAM to run, which is the application limit
under OpenBSD. Larger fragments and/or blocks will reduce the number of
inodes, and al
Hello all,
I just upgraded to 4.3, and I would like to congratulate the devs on
another wonderful release! shutdown -p works and the wbng sensor
support was a nice surprise. However, the most useful feature to me
was the support for ffs2.
I upgraded without a hitch, and repartitioned from a 1tb f
13 matches
Mail list logo
