Matt Dillon wrote:
>
> But its all a crock. It simply isn't possible to gracefully handle
> an out of memory condition. All sorts of side effects occur when
> the system runs out of memory, even *with* overcommit protection.
> In fact, all sorts of side effects occur even when t
It seems Scott Renfro wrote:
> As I promised on -mobile earlier this week, I've cleaned up my patches
> to port the {Net,Open}BSD atactl utility, including a simplistic
> ata-disk ioctl. They apply cleanly against this afternoon's -stable
> (including Soren's latest commit bringing -stable up to
:In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
:>OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
:>*wants* that feature to sit down and code it. It won't happen otherwise.
:
:So, out of idle curiousity: If, somewhere down the road, I know the kernel
:well en
:...
:> : merging such a feature?
:>
:> Assuming that it doesn't break anything, that it doesn't introduce a
:> severe performance penalty and works, there would be interest. There
:> are times that this is a desirable feature.
:
:This thread reminds me of what happened when I brought up the sam
Archie Cobbs wrote:
>
> Warner Losh writes:
> > : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
> > : >*wants* that feature to sit down and code it. It won't happen otherwise.
> > :
> > : So, out of idle curiousity: If, somewhere down the road, I know the kernel
> > :
Warner Losh writes:
> : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
> : >*wants* that feature to sit down and code it. It won't happen otherwise.
> :
> : So, out of idle curiousity: If, somewhere down the road, I know the kernel
> : well enough to attempt such a thi
In message <[EMAIL PROTECTED]>, David Gilbert write
s:
>IIRC, Digital-UNIX or OSF-1 ... or whatever it's called now. I seem
>to remember the first Alphas that arrived to a company I worked for
>had this set globally in the OS by default. Due to the bloat of the
>OS and Motif and other such thing
On Sun, Feb 25, 2001 at 09:17:38AM -0800, John Wilson scribbled:
| If you still have the Perforce->CVS conversion script, I would be very
| grateful if you could e-mail it to me.
Such a script is available for download on www.perforce.com.
| On Tue, 9 Jan 2001 09:13:39 +0100, Anton Berezin wrote
As I promised on -mobile earlier this week, I've cleaned up my patches
to port the {Net,Open}BSD atactl utility, including a simplistic
ata-disk ioctl. They apply cleanly against this afternoon's -stable
(including Soren's latest commit bringing -stable up to date with
-current). I've been runni
:With 512 Byte blocksizes you are limited to 1T because the physical
:block number is a signed 32bit.
:FFS uses 32bit (I wouldn't count on the high bit) frag numbers.
:A fragment defaults to 1k so even with 1k fragments the limit is
:at least 2T.
Yes, the FFS limit is essentially the frag siz
:Making the run for larger block sizes puts us in the same league as
:DOS. While it will stave off the wolves, it will only work for so
:long give Moore's law.
:
:Dave.
:
:--
:
:|David Gilbert, Velocet Communications.
On Sun, Feb 25, 2001 at 05:44:13PM -0500, David Gilbert wrote:
> > "Matt" == Matt Dillon <[EMAIL PROTECTED]> writes:
>
> [... my newfw bomb deleted ...]
>
> Matt> I had a set of patches for newfs a year or two ago but never
> Matt> incorporated them. We'd have to do a run-through on new
In message <[EMAIL PROTECTED]> Peter Seebach writes:
: In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
: >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
: >*wants* that feature to sit down and code it. It won't happen otherwise.
:
: So, out of idle curiousity:
:Hmmm... I was just having a little fun, and I think that someone's
:using the wrong type of integer somewhere:
:
:[1:23:323]root@news:~> vnconfig -e -s labels -S 1t vn0
:[1:24:324]root@news:~> disklabel -r -w vn0 auto
:[1:25:325]root@news:~> newfs /dev/vn0c
:preposterous size -2147483648
:
:Dave
> "Matt" == Matt Dillon <[EMAIL PROTECTED]> writes:
Matt> Use the vn device to create a swap-backed filesystem. 'man
Matt> vnconfig'. (In current VN functionality has been merged into MD
Matt> and MD in swap-backed mode should be used instead ). If you
Matt> turn softupdates on on the
Dear Anton,
If you still have the Perforce->CVS conversion script, I would be very
grateful if you could e-mail it to me.
Thanks in advance
John Wilson
On Tue, 9 Jan 2001 09:13:39 +0100, Anton Berezin wrote:
> On Sat, Jan 06, 2001 at 03:06:20PM -0800, John Wilson wrote:
> > I apologize
What I was saying is that cardbus only works on current.
=
| Kenneth Culver | FreeBSD: The best NT upgrade|
| Unix Systems Administrator | ICQ #: 24767726 |
| and student at The | AIM: muyt
In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
>OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
>*wants* that feature to sit down and code it. It won't happen otherwise.
So, out of idle curiousity: If, somewhere down the road, I know the kernel
well enough to
NFS experts out there, I have a question about synchronisation:
Imagine two hosts A (NFS server), host B (NFS client).
Process on A modifies a file. When does process on B get
notification about the change? Does it depend on
the time set on the different hosts? Is it a caching issue or what?
W
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> It doesn't work. The application killed by reason of insufficient
> resources is not (necessarily) the one that causes the page fault
> leading to that.
This is arguably a bug which needs to be fixed.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED
I think my commit to md yesterday torpedoed your patch, because one
part of it rej'ected. I applied the .rej by hand and found a
few nits here and there.
I change the list function extensively, because the "512" size of
the array were not picked from where it should come, ,
because it is under
Julian Elischer wrote:
>
> to not be caught by surprise,
> simply touch every page after you allocate it.
It doesn't work. The application killed by reason of insufficient
resources is not (necessarily) the one that causes the page fault
leading to that.
Id est, if my application allocates all
Dag-Erling Smorgrav wrote:
>
> > > None of these solutions are portable, however;
> > Well, no, but the sole available definition of "portable" says that it is
> > "portable" to assume that all the memory malloc can return is really
> > available.
>
> Show me a modern OS (excluding real-time and
Dag-Erling Smorgrav wrote:
>
> [EMAIL PROTECTED] (Peter Seebach) writes:
> > Is there any hope that, some day, a setting could be provided where a program
> > could request that malloc *NOT* overcommit? There are programs which would
> > rather know in advance, and clean up, than be killed abrup
hi all,
I've made some changes to libstand/bootp.c and they are available
for evaluation/comments/critics at:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot
short desc.:
o the bootp request now does a vendor-specific-request FreeBSDc
instead of
Kenneth Wayne Culver <[EMAIL PROTECTED]> writes:
> On 24 Feb 2001, Dag-Erling Smorgrav wrote:
> > Kenneth Wayne Culver <[EMAIL PROTECTED]> writes:
> > > FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever
> > > support cardbus in 4.x. If you are daring you can get -CURRENT, but
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>It says can, not must.
But if it "can be used", and no one says "undefined behavior", then we're
done; no undefined behavior is allowed.
>I disagree with you that you can't overcommit.
>Also, access is ill defined.
It's defined better in C99
In message <[EMAIL PROTECTED]> Peter Seebach writes:
: >I searched through the standard extensively to see if "allocates
: >space" is defined and couldn't find anything other than 'the poitner
: >can be used to access the space allocated.'
:
: EXACTLY!
:
: If it can't actually be used, then some
28 matches
Mail list logo
