nch of stuff on the list about it.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
the buffer cache management has been merged with
:the paging system in FreeBSD but I do not know if the above
:statements still hold true.
:
: Thanks
: Paolo
:
:P.S. Matt, your mentoring job is invaluable :)
Heh.
-Matt
To Unsubscribe: send
pace.
But, that aside, portalfs works just dandy for getting simple file handles
from a path.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
s worth of 'vmstat 1' output during the heavily loaded
period would be useful, plus 'sysctl -a | fgrep vm'. I might be able
to make suggestions on optimizing the VM system.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTE
total).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
never MFC'd that? After the release we should.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ou either need to tune or have already tuned in
the kernel configuration.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ing out of pmap entries.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ers are accessing
a lot of different files it might be beneficial to mount the
filesystems in question with the 'noatime' option. This
coupled with softupdates should remove any need for MFS.
-Matt
To Unsubscribe: send mail to [EMAIL PR
ically solve most of Michael's problems too
(though I'd still get rid of the MFS filesystem).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
You don't need 3G of swap, the 512M is fine as long as you scrap MFS.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
e approximately four 17GB swap partitions.
If you reduce NSWAP to 2 you would be able to create approximately
two 34GB swap partitions. If you reduce NSWAP to 1 you would be able
to create approximately one 68GB swap partition.
-Matt
r 1gb x 4 = 4gb worth of swap,
using 1/3 the memory for the bitmap. Each page of swap eats 2 bits of
memory for the bitmap so we aren't talking about a huge
amount of memory, but it's worth doing.
-Matt
To Unsubscribe: send mail to [
to process exits and
munmap()'s of large areas.
Theoretically we can remove half the structure, but at a
significant cost in performance.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Now I can see the output of the build commands and if everything looks good,
I finish it up as follows:
# make installworld
# make installkernel
# mergemaster
# reboot
Works like a charm nearly every time (on some older systems it's necessary
to build the kernel the old w
> -Original Message-
> From: David O'Brien [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 8:41 PM
> To: Matt Simerson
> Cc: [EMAIL PROTECTED]
> Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
>
> First let me say to anyone readi
odirenable turned off. So the net result
should be an increase in performance even on low-memory boxes.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ut the possible hazards of doing so but they mostly apply when
playing with -current.
Matt
>From /usr/src/UPDATING (on FreeBSD 4-STABLE):
COMMON ITEMS:
To build a kernel
-
cd /usr/src
# If you have not already done so, please buildworld here
:Matt Dillon <[EMAIL PROTECTED]> writes:
:> So you would be able to create approximately four 17GB swap partitions.
:> If you reduce NSWAP to 2 you would be able to create approximately
:> two 34GB swap partitions. If you reduce NSWAP to 1 you would be able
:
airly
straightforward since cvs already has support for branch date
ranges (for cvs update).
-Matt
Index: contrib/cvs/src/diff.c
===
RCS file: /home/ncvs/src/contrib/cvs/src/diff.c,v
retri
x27;s VM design.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ns it has to get rid of the user
mappings - a pmap*() call from vm/vm_pageout.c and vm/vm_page.c
accomplishes this. This fourth cache (the active user mappings of pages)
is also a throw away cache, though one with the side effect of making
VM PAGE cache pages available for loading i
It's randomness that will kill performance. You know the old saying
about caches: They only work if you get cache hits, otherwise
they only slow things down.
-Matt
:Which is ok if there isn't too much activity with
:
:On Tue, 10 Apr 2001, Matt Dillon wrote:
:
:>It's randomness that will kill performance. You know the old saying
:>about caches: They only work if you get cache hits, otherwise
:>they only slow things down.
:
:I wonder ... how does FreeBSD handle negative dir
27;ve never found that to be a show stopper, though.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:
:>Again, keep in mind that the namei cache is strictly throw-away, but
:>entries can often be reconstituted later by the filesystem without I/O
:>due to the VM Page cache (and/or buffer cac
c 444
back
proc
back
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
e a better chance of being in the VM page cache
so cost proportionally less even though they don't do any
better on a relative scale.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
fixed: blocks 2508870 -> 2508868
real fixed: blocks 197062 -> 197046
So, quotacheck doesn't discover or fix the discrepancy. :-(
Any ideas why this behavior would occur? Better yet, any idea how to fix
it?
Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I have to guess the former
because quotacheck's results should not vary dependent on whether the
machine is single user or not.
Matt
> -Original Message-
> From: Ken Stox [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 13, 2001 12:40 PM
> To: Matt Simerson
> Su
> -Original Message-
> From: Richard Hodges [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 13, 2001 1:23 PM
> To: Matt Simerson
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Quota reporting is inaccurate.
>
>
> On Fri, 13 Apr 2001, Matt Simerson
t should be fairly obvious if turning on vmiodirenable makes
it worse or not. My guess is: not, and it's just my paranoia that is
holding up turning on vmiodirenable.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ng at all for writes.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
rst that
should happen is that NFS might need to do a LOOKUP. I haven't had a
chance to look at the namei/vnode patch set yet but as long as a
reasonable number of vnodes remain cached NFS shouldn't be effected
too much.
-Ma
naged by vfs_cache.c. There's a big XXX
comment just before cache_purge() that explains it. Believe me,
NFS is the least of your worries here.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>:>I don't think NFS relies on vnodes never being freed.
:>:
:>:It does, in some case nfs stashes a vnode pointer and the v_id
:>:value away, and some time later tries to use that pair to try to
:>:refind
:In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
:
:>I thought vnodes were in stable storage?
:
:They are, that's the point Matt is not seeing yet.
I know vnodes are in stable storage. I'm just saying that NFS
is the least of your worries in tr
:>Note that I really don't care for using stable storeage as a hack
:>to deal with this sort of thing.
:
:Well, I have to admit that it is a pretty smart way of dealing with
:it for remote operations, but the trouble is that it prevents us from
:ever lowering their number again.
:
:
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>
:>:In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
:>:
:>:>I thought vnodes were in stable storage?
:>:
:>:They are, that's the point Matt is not seeing yet.
:>
:>I know vnodes are
vpid load needs to occur before
the VOP_ACCESS call rather then after.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
If this will get rid of or clean up the specfs garbage, then I'm all
for it. I would love to see a 'clean' fileops based device interface.
-Matt
:I have not examined the full details of doing the shift yet, but it is
:my
X -
EXTATTRCTL- - X -
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
backing device is mmapable and thus
would have a VM Object layer, so you get the bitmap caching for free).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ference in the vnode (assuming we don't
merge them), but it would be opaque to the rest of the system.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
(*fo_kqfilter) (fp, knote);
int (*fo_stat) (fp, stat, p);
int (*fo_close) (fp, p);
int (*fo_mmap) (fp, mmap_args);
int (*fo_dump) ( ? )
... others ...
} *f_ops;
-Matt
To Unsubsc
(oops, I forgot to add fo_truncate() to the fileops)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I've accepted the job of MFCing the dirpref stuff to -stable ... after
the 4.3 release.
If fsck is clobbering consistently we can probably make the kernel
avoid a panic. I'll look at the issue carefully when I do the MFC.
securelevel other then -1. Combined with the first idea this
would allow the system admin (outside the jail) to manipulate the
jail parameters of jailed users running inside jails on the system.
-Matt
To Unsubscribe: send mail to [EMAIL PRO
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>I just had an idea... allow the kernel security level to be specified
:>for a jailed environment. Add a 'securelevel' field to the jail
:>structure and bump the API rev.
:
:That would be trivial
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>I just had an idea... allow the kernel security level to be specified
:>for a jailed environment. Add a 'securelevel' field to the jail
:>structure and bump the API rev.
:
:That would be trivial
pend a lot of effort creating
the environment.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
and a 'file and forget'
type of setup.
If you are using NAT, your internal network should be in the 10.x.x.x
space, and your external network should of course be in your
internet-visible space.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I fleshed it out a long time
ago to explain all of this.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ith a MrCoffee
bolted to the back, hrm).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
tested it in any way. We use a similar trick for the vnode ref count.
I would be happy to review and test your final solution.
-Matt
:...
:There's a certain issue that when several processes sharing a vmspace are
:exiting at the same
It is possible for the vm_refcnt check in exit1() to *NEVER* be 1
if all the processes sharing the address space exit simultaniously
and block anywhere between that check and the vmspace_free(). The
result: shmexit() is never called.
-Ma
me an empty function right now. Nothing very
:MD in it at the moment.
:
:> -Matt
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
Yah, I'm sure there are a lot of MI/MD cleanups that could be done.
-Mat
:
:On Mon, May 21, 2001 at 12:35:17PM -0700, Matt Dillon wrote:
:
:> It's important to release resources as early as possible, so zombied
:> processes don't run the machine out of memory if a parent forgets to
:> reap its children.
:
:I've found one ot
ht be nice as well.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
:PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
It's not really good programming practice. Someone might trip over
it later on.
-Matt
To Unsu
over a F5 BigIP box in our lab, it was NOT running FreeBSD.
It runs a tweaked version of BSDI's kernel.
Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:
:On 22-May-01 Matt Dillon wrote:
:>:Ok, then why not let the current shmexit() stay in exit1() as a hack to help
:>:free memory, but add in a check in vmspace_free() as well to catch any race
:>:conditions that may fall through the cracks? As long as we clear the shm
:>:point
*will*
happen rather then what *might* happen.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
the confusion could
have been introduced. We might also want to add the shmexit to the
vmspace_free() code for completeness, but that would require more
research to determine whether it's safe to do there or not.
-Matt
To Unsubs
ith commit priv's thinks this is worth including, be
:my guest.
:
:--lyndon
Hey great! I love it. I'll commit it, but could we change the -/ option
to -u or -U or something like that? Any preferences?
-Matt
To Unsubscribe:
mit it right now as soon as I get an OK for
turning -/ into -u.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ice one! I'm going to be using this all over the place myself.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
l, not just absolute ones.
:
:--
:[ Joseph Mallett<[EMAIL PROTECTED]> ] [ http://srcsys.org ]
'maybe'. Generaly speaking, to ensure that we do not break
some existing use of telnet it is best to be conservative. You
can always do 'telnet -u relative_path'
:
:On Wed, 23 May 2001, Matt Dillon wrote:
:
:> Nice one! I'm going to be using this all over the place myself.
:
:I am missing something here. Is there a practical use for this? :)
:
:Jamie
Many programs these days use unix-domain sockets as a rendezvous
for IPC between p
em all over the place. Being able
to telnet to one is natural. Over the years I've probably
written the 'connect to unix domain socket' program 50 times because
it wasn't standard in a system. Now it is. Yahhh.
-Matt
h the O_DIRECT stuff this week).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:Matt> But unix-domain sockets are
: Matt> extremely useful in all manner of applications
:
:They're also anywhere from 10-400% faster than PF_INET for connections
:to the localhost (it varies a lot between different UNIX
:implementations).
:
:--lyndon
What, you don't
ant).
I suppose I could do a 'performance' man page.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
l commit it.
I think I'll do a 'firewall' manual page as well. I'm tired of people
not configuring firewalls properly and then whining about it.
-Matt
.\" Copyright (c) 2001, Matthew Dillon. Terms and conditions are those
lly require lots of files.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ting tools years to get as good as
it is for production purposes. It has taken EXT2FS a number of years
to reach where it is. ReiserFS is new, and it is going to be a while.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
d first appeared
:> in
:> .Fx 4.3 ,
:> May 2001.
:
:Should be .Fx 4.4. :)
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
Sticky issue, but from the point of view of the release CD's I'll go
with your suggestion.
ml generated using)
groff -mandoc -Thtml tuning.man > tuning.html
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
#x27; man page. Right now it only
covers IPFW based firewalls and NAT. Please feel free to email me
suggestions, corrections, etc... I will commit tuning and security
tonight and commit the firewall page tomorrow.
-Matt
To Uns
ll just put together
a list of additional doc changes over this week and update the man
pages next weekend!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Not sure who to notify here... I tried twice, this looks like a
real error.
-Matt
/usr/local/bin/cvsup -g -r 20 -L 2 -h cvsup.freebsd.org
/usr/share/examples/cvsup/cvs-supfile
SetAttrs ports/emulators/sim6811/distinfo,v
SetAttrs ports/emulators
Oops. The I/O error is on my machine , not cvsup :-)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ve! Ah well... back to the
tried-and-true-but-run-slightly-hot seacrates.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
the hard error and never occured under normal operation, only when I
was doing the dd test.
-Matt
:If you do a search for "IBM DTLA failure rate" on google or deja (which
:would also be google, I suppose), you'll find a bun
to regularing memory use.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
tatistics is icing on the cake.
This will also greatly reduce buffer cache lock contention on
directories undergoing simultanious background I/O (aka softupdates).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
a directory grows past a few hundred thousand files, but I'm not too
worried about it. The memory use ratio is good enough that that adding a
little memory to a machine lets you pile on a whole bunch more files
in the hash solution.
t a mutex
around zone frees in -current.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ry structures).
This second approach would be a good second-round approach.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
pts.
All suggestions are welcome.
--
On another note, I am MFCing the O_DIRECT patches I did a weekend or two
ago to -stable now.
-Matt
Index: vm/vm_map.c
===
RCS fi
y with a mutex in
-current, and need not be locked at all in -stable.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
interrupted.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
x8000) ERR#60 'Operation timed out'
:
:In fact there are no signals in the whole truss output
:
:Graham.
What type of descriptor is the read being performed on? A TCP
connection or, say, a reading a file over NFS?
-Matt
To Un
:
:On Thu, Jun 07, 2001 at 10:33:50AM -0700, Matt Dillon wrote:
:>
:> :
:> :Thanks, I will try setting errno, but I don't think it is signals.
:> :I have been running truss on the process. The relevant part is
:> :
:> :gettimeofday(0xbfbffa54,0x0)
es.
Probably a more involved answer then you were looking for, but hey!
BTW, I don't use static buffers for virtually anything any more... I
use asprintf() (or in my case, safe_asprintf()), safe_strdup(),
safe_replace(), safe_replacef(), safe_free(), etc... My &#x
Here is the whole set of supporting routines.
-Matt
/*
* STRDUP.C
*
* $Backplane: backplane/src/libsupport/strdup.c,v 1.13 2001/04/03 00:03:18 dillon Exp
$
*/
#include "defs.h"
Export char *safe_strdup(const char *s);
E
obably should have cleaned the source up before posting it. I
also have a fatalmem() routine which assert(0)'s, and DBASSERT(0)
is simply assert(0)... really should be a fatalmem() call too.
Oh well. You get the picture!
-Matt
To Un
se with it.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD works both ways.
-Matt
Index: kern_sig.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.72.2.6
diff -u -r1.72.2.6 kern_sig.c
--- kern_sig.c 2001/05/10 17:54:16 1.72.2.6
+++ ker
h with
one or two options in them makes maintaining and installing machines
rather difficult. I sure hope nobody is advocating doing away with
the monolithic capabilities of /etc/rc.conf!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED
would lose fairly quickly.
I wouldn't worry about it too much. It isn't a problem unless it
becomes one.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
201 - 300 of 616 matches
Mail list logo
