Hello -hackers
Some time ago, on -arch, phk proposed that the nodump flag should be
inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000).
This was generally considered a good idea, however, the patch to the
kernel he proposed was thought an ugly hack. In addition, jeroen
pointed
In message [EMAIL PROTECTED], Julian Elischer writes:
I still think that in such a case it should be possible to
'test the commitment' by touching all the allocated memory
while trapping page faults.
And what do you do if you get one? There's no undo button for SIGSEGV.
Traditionally, you
In message [EMAIL PROTECTED], Matt Dillon writes:
The problem is a whole lot more complex then you think. Dealing with
overcommit is not simply counting mapped pages, there are all sorts
of issues involved. But the biggest gotcha is that putting in
overcommit protection will not
On Wed, Feb 21, 2001 at 10:44:42AM -0800, Peter Wemm wrote:
There's a problem here. I tried to configure an SMP kernel but when it
booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and
wouldn't work. I went back and did the config/make on the GENERIC
kernel and booted
On Mon, Feb 26, 2001 at 08:28:56AM +0100, Soren Schmidt wrote:
No its not safe at all, you risk trashing an already running command...
Thanks for the feedback; that's exactly what I was concerned about.
Anyhow, I have an atacontrol thingy in the works for attach/detach,
raid control etc,
I won't have a chance to look at the patch below until later this week,
but had two comments--
1) This method of handling recursive nodump is far superior to any actual
inheritence of the flag as part of file system operations, as currently
no other file flags are inherited from the
On Sat, 24 Feb 2001, Peter Seebach wrote:
In message 9820.983050024@critter, Poul-Henning Kamp writes:
I think there is a language thing you don't understand here.
No, I just disagree. It is useful for the OS to provide a hook for
memory which is *known to work* - and that is the
In message [EMAIL PROTECTED],
Rik van Riel writes:
No, I just disagree. It is useful for the OS to provide a hook for
memory which is *known to work* - and that is the environment C specifies.
Send patches.
I may some day. It's not very high on my priority list; I'd probably try to
fix UVM
A couple of us on the questions list have asked for a way to spin down ide
disks when idle. Is there any chance that this utility could lead to
something useful there?
Steve Rose
It seems Scott Renfro wrote:
As I promised on -mobile earlier this week, I've cleaned up my patches
to port the
[ Memory overcommit ]
One important way to gain confidence that you're little box won't
silently crash at the worst possible time for the customer is to
be able to *prove* to yourself that it can't happen, given certain
assumptions. Those assumptions usually include things like "the
In message [EMAIL PROTECTED], Nate Williams writes
:
Even in this case, there's no way to prove your code is not going to
crash.
Sure. But you can at least prove that all crashes are the result of bugs,
not merely design "features". From the point of view of proving that a
system is designed
Even in this case, there's no way to prove your code is not going to
crash.
Sure. But you can at least prove that all crashes are the result of bugs,
not merely design "features".
'Proving' something is correct is left as an excercise for the folks who
have way too much time on their
In message [EMAIL PROTECTED], Nate Williams writes
:
Again, memory overcommit is only *one* class of bugs that is avoided.
The phrase "can't see the forest for the trees" jumps to mind. :)
Sure, and likewise, bugs in libc are only one *class* of bugs we can avoid,
but that doesn't mean we don't
:Matt Dillon wrote:
:
:..
: the system runs out of memory, even *with* overcommit protection.
: In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right. Go through any piece of significant code and just see how
much goes flying
I still think that in such a case it should be possible to
'test the commitment' by touching all the allocated memory
while trapping page faults. and fault all your memory from
'potential' to 'allocated'. As someone said. it is not sure which program
when you run out of swap, but I think
In message [EMAIL PROTECTED], Matt Dillon writes:
This has nothing to do with overcommit in the context it is being
discussed. In fact, this has nothing to do with OS memory management
at all -- all garbage collected languages have their own infrastructure
to determine when memory
A colleague of mine has reported the necessity of adding this patch to
if_fxp.c to support 802.1q vlans. I must admit that I am not familiar
enough with the vlan code to understand what good this does. This patch
is against 4.1-RELEASE. If it is a good thing, I would like to add it to
Peter Seebach wrote:
It's odd that I see lots of people arguing for segfaults killing the process
accessing memory that has been "successfully" allocated, but no one arguing
for the process getting killed when it exceeds a disk quota.
Disk quote is an artificial limit. If you remind each
Matt Dillon wrote:
:Matt Dillon wrote:
:
:..
: the system runs out of memory, even *with* overcommit protection.
: In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right. Go through any piece of significant code and just
: :...
: :
: :That's an assumption.
:
: Ha. Right. Go through any piece of significant code and just see how
: much goes flying out the window because the code wants to simply assume
: things work. Then try coding conditionals all the way through to fix
: it... and don't
In message [EMAIL PROTECTED], "Daniel C. Sobral" writes:
Anyway, these are two very different situations, and comparing them is
silly.
They are situations in which an application can be killed and has no way
to detect that it is about to do something wrong, and in which there *was*
a correct way
On Sun, 25 Feb 2001, Matt Dillon wrote:
The problem is a whole lot more complex then you think. Dealing with
overcommit is not simply counting mapped pages, there are all sorts
of issues involved. But the biggest gotcha is that putting in
overcommit protection will not
Greetings,
I'm interested in using mmap() with MAP_STACK. After writing a couple of
test programs and looking at vm_map_insert() and vm_map_stack(), it
appears that vm_map_stack() behaves as if MAP_FIXED were set.
Why is this? I would like to allocate stack space without having to
search for
On Tue, 27 Feb 2001, Daniel C. Sobral wrote:
Matt Dillon wrote:
:Matt Dillon wrote:
:
:..
: the system runs out of memory, even *with* overcommit protection.
: In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right.
In message [EMAIL PROTECTED],
And maybe, just maybe, they'll succeed in getting their
idea of non-overcommit working with a patch which doesn't
change dozens of places in the kernel and doesn't add
any measurable overhead.
If it adds overhead, fine, make it a kernel option. :)
Anyway, no, I'm
hi!
i can never really tell if this alias is for discussions concerning
development OF the FreeBSD OS or development ON the FreeBSD OS (or
both), but I figure i'll risk the wrath of the anti-social and ask a
coupla programming questions :-)
is mkdir(3) guaranteed to be atomic? Thus,
hello!
I've got a program that creates a named pipe, and then spawns a
thread
which sits in a loop:
// error checking snipped.
//
while (1) {
int fifo = open(fifoPath, O_RDONLY); // this blocks
fprintf(stderr, "somebody opened the other end!\n");
[Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by
peer: getsockname
[Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file
descriptor: flock: LOCK_EX: Error getting accept lock. Exiting!
[Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a Fatal error...
Apache is exiting!
httpd in
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
"Matt" == Matt Dillon [EMAIL PROTECTED] writes:
[... my newfw bomb deleted ...]
Matt Heh heh. Yes, newfs has some overflows inside it when you
Matt get that big. Also, you'll probably run out of swap just
Matt newfs'ing the metadata, you need to use a larger block size,
Matt large -c
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes
:
is mkdir(3) guaranteed to be atomic?
Yes.
Are there filesystem type cases where this might not be the case
(NFS being my main concern )
No.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in
is mkdir(3) guaranteed to be atomic?
Yes.
Are there filesystem type cases where this might not be the case
(NFS being my main concern )
No.
Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir
call returns, you have no guarantee that the remote directory
-
From: Nate Williams [EMAIL PROTECTED]
Are there filesystem type cases where this might not be the case
(NFS being my main concern )
No.
Yes. NFS doesn't guarantee atomicity, because it can't. If the
mkdir
call returns, you have no guarantee
Are there filesystem type cases where this might not be the case
(NFS being my main concern )
No.
Yes. NFS doesn't guarantee atomicity, because it can't. If the
mkdir
call returns, you have no guarantee that the remote directory has
been
created (caching, errors,
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes
:
is mkdir(3) guaranteed to be atomic?
Yes.
Um. mkdir(2) is atomic. Note that mkdir(1) with the -p argument is
*not* atomic.
Are there filesystem type cases where this might not be the case
(NFS being my main concern )
In message [EMAIL PROTECTED], Mike Smith writes:
How would it *not* be atomic?
Well, imagine a hypothetical broken system in which two simultaneous calls
to mkdir, on some hypothetical broken filesystem, can each think that it
"succeeded". After all, at the end of the operation, the directory
I can handle it if there is a case where both fail, but is
there a
case where both can SUCCEED ??
What do you mean 'both succeed'?
My understanding is that, on non-broken filesystems, calls to
mkdir(2) either succeed by creating a new directory, or fail and return
EEXIST
I can handle it if there is a case where both fail, but is
there a
case where both can SUCCEED ??
What do you mean 'both succeed'?
My understanding is that, on non-broken filesystems, calls to
mkdir(2) either succeed by creating a new directory, or fail and return
EEXIST
Well, for me it's the noise and heat that I'm trying to minimize. That
and we're out of power here in California. :-)
Steve Rose
On Mon, 26 Feb 2001, Soren Schmidt wrote:
It seems Stephen Rose wrote:
A couple of us on the questions list have asked for a way to spin down ide
disks when
"Daniel" == Daniel C Sobral [EMAIL PROTECTED] writes:
Daniel 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
In message [EMAIL PROTECTED], Mike Smith writes:
How would it *not* be atomic?
Well, imagine a hypothetical broken system in which two simultaneous calls
to mkdir, on some hypothetical broken filesystem, can each think that it
"succeeded". After all, at the end of the operation, the
"Peter" == Peter Seebach [EMAIL PROTECTED] writes:
Peter Well, imagine a hypothetical broken system in which two
Peter simultaneous calls to mkdir, on some hypothetical broken
Peter filesystem, can each think that it "succeeded". After all,
Peter at the end of the operation,
On Mon, 26 Feb 2001, Peter Seebach wrote:
In message [EMAIL PROTECTED],
And maybe, just maybe, they'll succeed in getting their
idea of non-overcommit working with a patch which doesn't
change dozens of places in the kernel and doesn't add
any measurable overhead.
If it adds overhead,
In message [EMAIL PROTECTED],
Rik van Riel writes:
I don't think a failed kernel-level allocation after overcommit
should generate a segfault.
IMHO it should send a bus error (or a sigkill if the process
doesn't exit after the SIGBUS).
Same difference, so far as the language is concerned.
In message [EMAIL PROTECTED],
Rik van Riel writes:
Rationale:
SIGSEGV for _user_ mistakes (process accesses wrong stuff)
SIGBUS for _system_ errors (ECC error, kernel messes up, ...)
Actually, this is not canonically the distinction made. On a Unix PC,
{
int *a, c[2];
(owner-freebsd-hackers removed from list)
:You're implying that you are making two calls to create the same
:directory. Am I correct?
:
:The answer is 'maybe'? Depends on the remote NFS server. Matt or one
:of the other NFS gurus may know more, but I wouldn't count on *anything*
:over
No, there isn't. They have a CVS to Perforce script, not Perforce to CVS
(please don't ask who in their right mind would want to go from Perforce to
CVS :)
Well, if Anton doesn't respond, I guess I'll just have to write one
myself...
John
On Sun, 25 Feb 2001 22:00:31 -0600, Michael C . Wu
:
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive
Soren Schmidt [EMAIL PROTECTED], said on Mon Feb 26, 2001 [09:10:43 PM]:
} It seems Stephen Rose wrote:
} A couple of us on the questions list have asked for a way to spin down ide
} disks when idle. Is there any chance that this utility could lead to
} something useful there?
}
} Well, of
Exact same config on other webservers wtih really low cpu.
Memory checks out fine. Mysql connection to db checks out fine.
IO is fine...running out of ideas.
tcpdump returns alot of these
15:19:53.383597 elrond.sf.bravenet.com.shivahose
drago.sf.bravenet.com.telnet: . ack 6212 win
hello!
I'm running into a problem with some threading using pthreads in an
application i'm writing for FreeBSD.
The application basically
1. initializes some UI goo (but doesn't start any of it UP) using a
GUI framework (Qt)
2. creates a FIFO, and then spawns a thread
On Mon, 26 Feb 2001, Dan Phoenix wrote:
[Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by
peer: getsockname
[Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file
descriptor: flock: LOCK_EX: Error getting accept lock. Exiting!
[Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a
In message [EMAIL PROTECTED], Tony Finch writes:
fork() with big data segments that cause swap to be reserved in case
of a copy-on-write. The 2GB of swap is never actually used, but you
still have to have it.
That's a good point. So, we should warn people that asking for memory
committments,
I did not specify a lock directive in httpd.conf.
Default my httpd is in /usr/local/apache
i would assume lock file is going there which is an ide drive.
Date: Mon, 26 Feb 2001 17:57:03 -0800 (PST)
From: Doug White [EMAIL PROTECTED]
To: Dan Phoenix [EMAIL PROTECTED]
Cc: [EMAIL
If the first program calls open(2) before the second one calls
close(2) the former will not block because there's already a writer on
the pipe. A possible workaround would be to unlink and recreate the
fifo in program one, like so:
for (;;)
{
int fifo;
Dan Phoenix wrote:
httpd in free(): warning: recursive call.
What FreeBSD/apache versions is this with? I've seen the same on
FreeBSD-3.4 and an older apache build from ports. Haven't (yet) seen it
under 4.2 and the latest apache from ports.
--
Lars Eggert [EMAIL PROTECTED]
On 26 Feb 2001 18:56:18 +0100, Matt Dillon [EMAIL PROTECTED] wrote:
Ha. Right. Go through any piece of significant code and just see how
much goes flying out the window because the code wants to simply assume
things work. Then try coding conditionals all the way through to fix
Chris Shenton wrote:
In message [EMAIL PROTECTED] Wes Peters writes:
We have several NIC's around here (the New Internet Computer, see
http://www.thinknic.com/ for details) and will be adding a couple of these
so we can boot FreeBSD or NetBSD on them in the next little while. A NIC
1) This method of handling recursive nodump is far superior to any actual
inheritence of the flag as part of file system operations, as currently
no other file flags are inherited from the parent directory -- the only
property that is inherited is the group. With ACLs, the parent's
59 matches
Mail list logo
