I'm in the process of (re)writing an rc.d script for kadmind
(security/krb5). Unlike the main Kerberos daemon, kadmind needs to
have a separate instance for each realm on the server -- it can't
support multiple realms in a single process. What I need to be able
to do:
1) Have different flags and
<
said:
> I've attached the patch drc3.patch (it assumes drc2.patch has already been
> applied) that replaces the single mutex with one for each hash list
> for tcp. It also increases the size of NFSRVCACHE_HASHSIZE to 200.
I haven't tested this at all, but I think putting all of the mutexes
in
<
said:
> And, although this experiment seems useful for testing patches that try
> and reduce DRC CPU overheads, most "real" NFS servers will be doing disk
> I/O.
We don't always have control over what the user does. I think the
worst-case for my users involves a third-party program (that they
<
said:
>> Simple: just use a sepatate mutex for each list that a cache entry
>> is on, rather than a global lock for everything. This would reduce
>> the mutex contention, but I'm not sure how significantly since I
>> don't have the means to measure it yet.
>>
> Well, since the cache trimming i
[Adding freebsd-fs@ to the Cc list, which I neglected the first time
around...]
<
said:
> I can't remember (I am early retired now;-) if I mentioned this patch before:
> http://people.freebsd.org/~rmacklem/drc.patch
> It adds tunables vfs.nfsd.tcphighwater and vfs.nfsd.udphighwater that can
>
I had an email conversation with Rick Macklem about six months ago
about NFS server bottlenecks. I'm now in a position to observe my
large-scale NFS server under an actual production load, so I thought I
would update folks on what it looks like. This is a 9.1 prerelease
kernel (I hope 9.1 will be
< said:
> I could care less about the resolver daemon itself, I agree with what
> you're saying and I don't think most end users will care about that.
> But getting rid of dig and host in base would be bad.
I don't think it's as bad as you suggest, although I do think they we
would likely get a f
< said:
> Neither of which has any relevance to the actual root zone ZSK, which
> could require an emergency roll tomorrow.
Surely that's why there's a separate KSK. The ZSK can be rolled at
any time.
-GAWollman
___
freebsd-hackers@freebsd.org mailing
< said:
> BIND in the base today comes with a full-featured local resolver
> configuration, which I'm confident that Dag-Erling can do for unbound
> (and which I would be glad to assist with if needed). Other than that,
> what integration are you concerned about?
The utilities (specifically host(
If you have a moment, please take a look at the following patch. It
contains some very minor fixes to various parts of libc which were
found by the clang static analyzer. They fall into a few categories:
1) Bug fixes in very rare situations (mostly error-handling code that
has probably never bee
< said:
> Can you find any evidence that it's acceptable to interleave multiple
> writers that are doing O_APPEND? At best, to do what you're asking,
> they could be kept from being interleaved from the context of one
> specific NFS client host...
As far as POSIX goes, the standard says that ap
< POSIX == SUSv3 these days.
Not quite. POSIX and SUSv3 use the same specification, but don't
require the same things. (Specifically, SUSv3 requires the XSI option
to be implemented.)
-GAWollman
___
freebsd-hackers@freebsd.org mailing list
http://lis
< said:
> I think the first is more useful behavior than the last. Supporting it
> should be exactly the same as supporting what happens if the actual
> filesystem fills up. In this case, the filesystem is being requested to
> write more "than there is room for."
Returning a short write for ope
< said:
> Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short
> writes on regular files... ?
I believe it is the intent of the Standard to prohibit this (a
paragraph in the rationale says that short writes can only happen if
O_NONBLOCK is set, but this is clearly wrong becaus
[Cc list trimmed]
< said:
> The lack of speed in some apps can be blamed mostly on the toolkits.
I'll second that.
> GTK+ 1.2 was a speed demon, GTK+ 2.x is a lot slower.
And either one is an enormous hog compared to Athena widgets. (This
is something of an accomplishment, since people have b
< said:
> This sounds very close to OpenAFS. I don't know what distinguishes a SAN
> from other types of NAS. OpenAFS does everything you mentioned in the
> above paragraph. OpenAFS _almost_ works on FreeBSD right now.
AFS's consistency model is wholly unsuitable for clustering.
-GAWollman
< said:
> I was advised by Terry Lambert to use:
> #ifdef _POSIX_REALTIME_SIGNALS
Terry was wrong. If _POSIX_REALTIME_SIGNALS is undefined, it means
one of two things:
- The RTS option is not supported, or
- You can't tell whether or not the RTS option is supported.
The section of XBD you quo
<
said:
> The semaphore remains active until it is destroyed. If you don't
> want to track its page, can you hook it into ipcrm(1)?
A simple way of implementing process-shared anonymous semaphores,
using the kernel support, is to simply create a temporary semaphore,
and (important part) store
< said:
>> From IEEE P1003.1 Draft 7:
You're looking at the wrong document. FreeBSD is very far from being
ready to implement POSIX 2001 header files. POSIX 1990, which we do
implement, requires almost everywhere.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
< said:
> Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
> There is code obviously taken from if_loop.c and used in some
> drivers, which tries to do something with the third argument "data"
> of the if_ioctl() driver method if "data" isn't NULL.
The historic implementation pas
< said:
> basically i am thinking of something like
> generic_syscall("fdcloseall", );
No less clear than
ret = syscall(SYS_FDCLOSEALL, ...);
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
< said:
> ok, sorry for the confusion then (though, how does one tell from
> the manpage for pipe(2) what is going on there!)
You're not supposed to -- it's an implementation detail.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of t
< said:
> but there is a problem with syscall() in that according to
> the manpages it cannot handle in/out parameters as instead
> it is supported by ioctl/fcntl
Of course it can, and the manual page doesn't even suggest what you
say. It says:
There is no way to simulate system calls tha
< said:
> And, this mechanism would be explicitly used for "non portable" or
> experimental functions (such as the closeall() which started the
> thread, or next time someone comes up with a start_http_server_thread())
> and avoiding overloading an existing syscall or having to modify
> libc
Thi
< said:
> kind-of, though the function name should be a string and not
> an integer (easier to extend/allocate), and it should allow
> return values in user-supplied buffers, same as ioctl/fcntl
> calls do.
dlsym()
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe f
< said:
> Do you mean something like this?
Yes, exactly like that!
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|
< said:
> make "extra" and "missing" attributes in the output
> rather than prefixes which can be confused with filenames.
> Don't do the "run-in" of the first attribute with a short
> filename
This looks like a good change, but while you're there:
> size
- Standards relevant to printing, such as IPP.
- Support for foreign printing protocols in FreeBSD using
tools like `CAP' and `samba'.
This list is maintained and retroactively moderated by Garrett
Wollman, wollman@{{FreeBSD,bostonradio,decalcomania}.org,lcs.mit.edu
< said:
> if ((u_quad_t)cc > (u_quad_t)sb_max * MCLBYTES / (MSIZE + MCLBYTES))
> return (0);
I think the code here should clip the requested size into range rather
than failing the allocation. That way, a program could just specify a
ridiculously-large buffer size and get wh
< said:
> Hmm, this has me thinking again about suspend/resume. In the current
> context, can we expect a suspend veto from some function to actually
> DTRT? (ie. drivers that have been suspended get a resume call).
That's how I originally implemented it, but I'm not sure whether that
has bee
< said:
>> current process? Is it safe if I use proc0 to pass the proc structure to
>> call socreate() and sobind()? How safe it is to use curproc
>> structure? Somebody mentioned that it will not work in interrupt
>> handlers.
proc0 is passed because I didn't think things completely through whe
< said:
> i know that :) i guess my questions were
> 1) why the same piece of code duplicated in all ``mount_xxx'' utilities?
Because the original loadable module system held strongly to the
religion that the kernel should never load anything of its own
accord. The designers of the current load
< said:
> can you clarify this ? Looong ago i used the '586 on a bridge and it did let
> me write the MAC header...
The 82586 has a mode bit which selects one of two possibilities:
1) The transmit command specifies the destination address and
length/ethertype field; the source address is insert
CC's trimmed!
< said:
> this looks more and more like STREAMS
Which is part of the reason why Netgraph will always remain an
optional add-on, rather than the way the protocol stack is normally
constructed.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all th
<
said:
> although I actually live near Amherst, Massachusetts much of the
> time.
Anyone up for a Southern New England FreeBSD ftf gtg? I can host. If
you think you might be interested, please reply privately.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're
< said:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to [EMAIL PROTECTED] for more info.
It would be preferable if text were sent as text, since MIME-encoded
patches requir
<
said:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to m...@docserver.cac.washington.edu for more info.
It would be preferable if text were sent as text, since MIME-encode
< said:
> Correct. I suppose it's worth discussing what the default should be.
> Should they get EAGAIN or block? Obviously you'd want a way of
> specifying which, but there would have to be a default for
> non-lock-aware programs. I think I'd go for blocking; it's less error
> prone.
I'd be s
< said:
> Correct. I suppose it's worth discussing what the default should be.
> Should they get EAGAIN or block? Obviously you'd want a way of
> specifying which, but there would have to be a default for
> non-lock-aware programs. I think I'd go for blocking; it's less error
> prone.
I'd be
<
said:
> Remember, the question was, "Do we need to spend the effort making all
> of our programs support the use of - to denote std{in,out}?"
No, because most of them (for which such an option might be relevant)
already do, or else don't need it (because they default to stdin).
-GAWollman
-
< said:
> Remember, the question was, "Do we need to spend the effort making all
> of our programs support the use of - to denote std{in,out}?"
No, because most of them (for which such an option might be relevant)
already do, or else don't need it (because they default to stdin).
-GAWollman
--
< said:
> logonserver. Since than almost every day we find timeconsuming processes
> running while the user isn't even logged in (anymore). These programs are
> mostly tin and lynx and such interactive programs. We are sure that they
Some broken interactive programs don't bother to check whether
42 matches
Mail list logo
