Re: AIO was Re: Kernel threads
With respect to AIO... we run a data server which multiplexes
on the select() function, and uses AIO to do all it's I/O. This
has been a very stable system.
system : 4.0-19990827-SNAP
start time : 1999/12/24 11:14:44
up time (days hh:mm:ss): 12 13:32:53
Current/Max/Total connections: 0 / 2 / 244
Total requests:6228
Total aio bytes written: 573499989 (546.9M)
Current/Max stat daemons: 0 / 1
Current/Max Queued for stat: 0 / 0
Current/Maxcp daemons: 0 / 2
Current/Max Queued for cp: 0 / 0
Current/Max aio_write daemons: 0 / 2
Current/Max Queued for write: 0 / 0
Current/Max/ telnets: 1 / 1
The above is a sample of the stats kept by the daemon. The numbers
are very low due to the holidays. Basically, this thing hands raw data
to applications running on NT, where the data is kept on Network
Appliance fileservers attached to FreeBSD boxes. Direct CIFS attachment
to the data from the NT system does not come close to the through-put
we attain using this process.
I would very much like to see these patches applied also. At a
minimum, it means that the following type of code loop can be
removed since we would know immediately which aio operation completed.
The marked loop below becomes relatively hot as the max number of
outstanding aio processes is increased and the number of simultanious
hits on the server grows.
/*--+
| ST_AIO |
| |
| A task in the ST_AIO state means that one of our |
| aio_writes has finished. we will loop thru all |
| outstanding aio_writes to see which one completed. |
| |
*--*/
case ST_AIO:
... code deleled ...
/*-+
| we know we have a completed process. let's find out |
| which one it is.|
*-*/
--- for (j=0; jMAX_WRITERS; j++) {
---if (aio[j].task aio_error(aio[j].iocb) != EINPROGRESS)
--- break;
}
... code deleted ...
/*-+
| Get the actual return code, check length, decrement |
| active count, send message |
+-*/
t = aio[j].task;
rc = aio_return(aio[j].iocb);
Since we are getting ready to bring this process forward and integrate
the new signal handling code, now would be a great time for these
patches to be applied and have some heavy testing done on them.
Thanks!
John
In article [EMAIL PROTECTED] you
write:
The best fix I've thought of thus far (other than async I/O, which I
understand isn't ready for prime time) would be to have a number of kernel
Speaking of AIO, which I would really like to use if possible, how
actively maintained is it? The copyright on vfs_aio.c is 1997, suggesting
to me that John Dyson has moved onto other things.
Yep, that's right.
Quite recently Christopher Sedore has done some work on vfs_aio.c, to
make it work better with sockets and he also added a very useful
aio_waitcomplete system call which returns the first aiocb (AIO control
block) from the 'completed' queue. I would be nice if these patches
could be added to FreeBSD-current.
About AIO not ready for prime time: I did some experiments recently by
throwing up to 256 aio requests on one fd (a raw disk device) into the
system and it worked without any problems. The only time I got a panic
was when (I think) I had a negative aiocb-offset (I still need to
reproduce this). See http://www.iae.nl/users/devet/freebsd/aio/ for my
aiotest.c program.
I'm thinking about using AIO for a faster Squid file system by using raw
disk devices instead of UFS which has too much overhead for Squid.
Arjan
- --
Arjan de Vet, Eindhoven, The Netherlands [EMAIL PROTECTED]
URL: http://www.iae.nl/users/devet/ for PGP key: finger [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of
PCMCIA-ATA/USB support for SanDisk/Digital Cameras
Hi, I'm thinking about buying a digital camera, but of course it has to be usable from my FreeBSD box (-current). In looking at the Kodak series, they seem to support the PCMCIA-ATA standard. So, instead of communicating directly with the camera, I was thinking about purchasing a reader from SanDisk: http://www.sandisk.com/cons/imagemate-USB.htm referenced from: http://www.kodak.com/US/en/digital/accessories/memory/usbReader.shtml Basically, it appears to be a combination of PCMCIA-ATA support melded together with USB. Does anyone have any experience with this unit? Am I correct that with USB support coming onboard in -current that it would be feasible to get a driver working? Thanks! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Wine: What am I missing (lseek/write)
Hi,
I'm working on wine on a 4.0-19990827-SNAP system.
The application I have calls WriteFile(), in files/file.c, line
1145. The write() call is failing with:
WriteFile: File too large[27]
Note: I added the fprintf() to show the above...
Well, this is happenning on filedesc 14, so for grins I added
the following just above the write call:
if (unix_handle == 14) {
off_t x = lseek(unix_handle, 0, SEEK_CUR);
if (x == -1)
fprintf(stderr,"WriteFile lseek %s[%d]\n",strerror(errno),errno);
else
fprintf(stderr,"WriteFile fd:14 SEEK_CUR,0 == %ld\n",x);
}
It shows:
WriteFile lseek No such file or directory[2]
Somewhere, somehow, I'm missing something... I've run wine with
-debugmsg and I can't find any errors... I've ktraced wine to make
sure the syscall parameters are correct...
Any pointers or ideas on where to take this would be appreciated.
Thanks!
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13075 (was: Re: aio_*)
Well, another code fragment might be useful: /*--+ | Set up iocb for aio_write() call | +--*/ memset(iocb, 0, sizeof(struct aiocb)); iocb-aio_fildes = atask-tfd; iocb-aio_offset = 0; iocb-aio_buf= fileaddr; iocb-aio_nbytes = (int)cb.st_size; iocb-aio_sigevent.sigev_notify = SIGEV_SIGNAL; iocb-aio_sigevent.sigev_signo = SIGAIO; /* currently USR1 */ *** iocb-aio_sigevent.sigev_value.sigval_ptr = atask; Note the last line above where we would like to signal value to the address of the task which started the io operation. At io completion/signal delivery time the signal value can then be recovered from the 'code' parameter of the signal handler (since this is a soft interupt code is not required to hold a hardware indication/value). void handler(sig, code, scp) int sig, code; struct sigcontext *scp; Unfortunately, the 'psignal' function used called from vfs_aio.c only takes a signo parameter, and kern_sig.c wouldn't understand how to hold onto the new code value anyways if the signal recipient isn't curproc. ie: the difference between psignal() and trapsignal(). Anyways, it the above worked, then you could always tell which aio request had completed. Thus, no looping would be required in the userland app nor in the kernel with a 'find the next completed aio request' syscall. Comments welcome! -John And now for a wish: [ST_AIO stuff cut] If I understand what you are trying to say, then when real time signals are added, this will be unnecessary. You can get the completion of an aio_* call from the signal queue. -jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: seek to negative offset? kern/6184
Hi,
I've been running the following patch (which uses discreet
tests vs a common temp off_t variable). Would someone please
consider committing either this patch or the one given in
the pr? It doesn't really matter to me, but I would like to
see this bug put to rest.
Comments welcome!
Thanks,
John
ps: The following patch differs from the one given in the pr for
the simple reason that I don't like making assumptions about
overflow handling during math operations. In the patch below,
L_XTND nolonger depends on overflow assumptions, but L_INCR
still does. L_INCR really needs to be something like:
if ((MAXFILESIZE - fp-f_offset) SCARG(uap, offset))
return (EINVAL);
but, I am not aware of a MAXFILESIZE definition unless I
try to construct one using operations based on the sizeof()
an off_t. Comments?
patch by [EMAIL PROTECTED]
Index: vfs_syscalls.c
===
RCS file: /mirror/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.135
diff -u -r1.135 vfs_syscalls.c
--- vfs_syscalls.c 1999/09/11 00:45:58 1.135
+++ vfs_syscalls.c 1999/09/19 02:48:59
@@ -1433,15 +1433,22 @@
return (ESPIPE);
switch (SCARG(uap, whence)) {
case L_INCR:
+ if ((fp-f_offset + SCARG(uap, offset)) 0)
+ return (EINVAL);
fp-f_offset += SCARG(uap, offset);
break;
case L_XTND:
error=VOP_GETATTR((struct vnode *)fp-f_data, vattr, cred, p);
if (error)
return (error);
+ if ((SCARG(uap, offset) 0)
+ ((-SCARG(uap, offset)) vattr.va_size))
+ return (EINVAL);
fp-f_offset = SCARG(uap, offset) + vattr.va_size;
break;
case L_SET:
+ if (SCARG(uap, offset) 0)
+ return (EINVAL);
fp-f_offset = SCARG(uap, offset);
break;
default:
On Tue, Aug 24, 1999 at 04:25:26PM -0400, John W. DeBoskey wrote:
The subject says it all... We have some code that scans files
backwards...
In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see
where we do any validation on the resulting seek location... Do the
appropriate folks think this is a bug? How about posix? Should I
go ahead and submit a pr with a patch?
I've just discovered kern/6184 (from Mar 1998, state: open). Seems like
patch which fixes it was never commited.
V.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
seek to negative offset?
Hi,
The subject says it all... We have some code that scans files
backwards... On the systems we've been running this program on, the
lseek man page typically lists:
[EINVAL] The resulting file offset would be negative.
The following program run under freebsd-current shows the problem:
#include stdio.h
#include errno.h
#include unistd.h
#include fcntl.h
main()
{
int offset, myerrno;
int myfd;
myfd = open("/etc/passwd", O_RDONLY);
printf("Seeking to byte 512...\n");
offset = lseek(myfd, 512, SEEK_SET);
myerrno = errno;
printf("offset after first lseek: %d\nerrno=%d\n\n",offset,myerrno);
printf("Seeking relative -1024 bytes...\n");
offset = lseek(myfd, -1024, SEEK_CUR);
myerrno = errno;
printf("offset after second lseek: %d\nerrno=%d\n\n",offset,myerrno);
printf("Current offset location: %d\n",lseek(myfd, 0, SEEK_CUR));
close(myfd);
}
sample output:
Seeking to byte 512...
offset after first lseek: 512
errno=0
Seeking relative -1024 bytes...
offset after second lseek: -512
errno=0
Current offset location: -512
In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see
where we do any validation on the resulting seek location... Do the
appropriate folks think this is a bug? How about posix? Should I
go ahead and submit a pr with a patch?
Thanks!
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
seek to negative offset?
Hi,
The subject says it all... We have some code that scans files
backwards... On the systems we've been running this program on, the
lseek man page typically lists:
[EINVAL] The resulting file offset would be negative.
The following program run under freebsd-current shows the problem:
#include stdio.h
#include errno.h
#include unistd.h
#include fcntl.h
main()
{
int offset, myerrno;
int myfd;
myfd = open(/etc/passwd, O_RDONLY);
printf(Seeking to byte 512...\n);
offset = lseek(myfd, 512, SEEK_SET);
myerrno = errno;
printf(offset after first lseek: %d\nerrno=%d\n\n,offset,myerrno);
printf(Seeking relative -1024 bytes...\n);
offset = lseek(myfd, -1024, SEEK_CUR);
myerrno = errno;
printf(offset after second lseek: %d\nerrno=%d\n\n,offset,myerrno);
printf(Current offset location: %d\n,lseek(myfd, 0, SEEK_CUR));
close(myfd);
}
sample output:
Seeking to byte 512...
offset after first lseek: 512
errno=0
Seeking relative -1024 bytes...
offset after second lseek: -512
errno=0
Current offset location: -512
In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see
where we do any validation on the resulting seek location... Do the
appropriate folks think this is a bug? How about posix? Should I
go ahead and submit a pr with a patch?
Thanks!
John
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Proposal for new syscall to close files
Hi,
I like this approach. I have a number of often spawned daemon
processes that could benefit from this. One of the last process
we debugged where we had unwanted open filedescriptors was in
programs invoked by the cvs loginfo script.
For naming convention considerations, I might suggest 'closeall'
or 'closefdset' or something similar... at least have 'close' in
name... :-)
Good Work,
John
It's fairly common, when spawning new processes, to want to make sure
all unwanted FDs are closed. Currently, the options for doing this are:
1) Use fcntl(fd, F_SETFD, FD_CLOEXEC) to set the close-on-exec flag
when the file is opened/cloned. This may not be practical if the
FD must remain open across some exec's, but not others. It is not
possible to ensure that FDs implicitly opened within library
functions have the close-on-exec flag set. It may be inefficient if
there are lots of opens and few execs.
2) Explicitly close unwanted FDs in the child, before the exec().
This suffers from the usual resource tracking problems (ie it's
easy to forget to close one - especially in a maze of pipe()/
dup()/dup2() calls designed to join the child's stdin/out/err
to the parent). It also requires that the FD's be visible to the
function - which may be difficult (the FD may be hidden within
another function somewhere).
3) Close all FDs except the ones you explicitly want to keep. This
is normally something like:
for (i = getdtablesize(); --i 2; )
close(i);
The advantage is that you are sure you don't miss any. The
disadvantage is that it requires a system call for each potentially
open FD - 600 on my system - whereas maybe only 4 or 5 are
actually open.
In the case of option 3, you only really need to attempt to close file
descriptors less then curproc-p_fd-fd_lastfile or even
curproc-p_fd-fd_nfiles, but these values aren't readily accessible
from userland. (And this still suffers the overhead of a userland
to kernel transition for each FD).
I'd therefore like to propose a new syscall that closes _all_ file
descriptors associated with a process, except for those passed as
1 bits in an fd_set. The proposed API is:
int cleanup_files(int nfds, const fd_set *leavefds);
where nfds specifies the number of fds in *leavefds to potentially
keep open (ie all fds = nfds will be closed).
The function would return the number of FDs closed.
The implementation would be along the lines of:
struct cleanup_files_args {
int nd;
fd_set *leave;
};
int
cleanup_files(p, uap)
register struct proc *p;
register struct cleanup_files_args *uap;
{
fd_set s_fdset;
fd_set *lset;
int error, nclosed = 0;
u_int i, ncpbytes, nfdbits;
struct filedesc *fdp = p-p_fd;
struct file **fpp;
char *fdfp;
if (uap-nd 0 || uap-leave = NULL)
return (EINVAL);
/* some daemons mught not have any file descriptors */
if (fdp == NULL) {
p-p_retval[0] = 0;
return (0);
}
if (uap-nd fdp-fd_lastfile)
uap-nd = fdp-fd_lastfile + 1;
/*
* Allocate just enough bits for the passed fd_set. Use the
* preallocated auto buffer if possible.
*/
nfdbits = roundup(uap-nd, NFDBITS);
ncpbytes = nfdbits / NBBY;
if (ncpbytes = sizeof s_fdset)
lset = s_fdset;
else
lset = malloc(ncpbytes, M_SELECT, M_WAITOK);
error = copyin(uap-leave, lbits, ncpbytes);
if (error != 0)
goto done;
fpp = fdp-fd_ofiles;
fdfp = fdp-fd_ofileflags;
for (i = 0; i uap-nd; i++, fpp++, fdfp++) {
if (!FD_ISSET(i, lset) *fpp != NULL) {
if (*fdfp UF_MAPPED)
(void) munmapfd(p, i);
error = closef(*fpp, p);
if (error != 0)
goto done;
nclosed++;
*fpp = NULL;
*fdfp = 0;
if (i fdp-fd_freefile)
fdp-fd_freefile = i;
}
}
for (; i = fdp-fd_lastfile; i++, fpp++, fdfp++)
if (*fpp != NULL) {
if (*fdfp UF_MAPPED)
(void) munmapfd(p, i);
error = closef(*fpp, p);
if (error != 0)
goto done;
nclosed++;
*fpp = NULL;
*fdfp = 0;
if (i fdp-fd_freefile)
fdp-fd_freefile = i;
}
}
while (fdp-fd_lastfile 0 fdp-fd_ofiles[fdp-fd_lastfile] == NULL)
fdp-fd_lastfile--;
done:
Re: Proposal for new syscall to close files
Hi,
I like this approach. I have a number of often spawned daemon
processes that could benefit from this. One of the last process
we debugged where we had unwanted open filedescriptors was in
programs invoked by the cvs loginfo script.
For naming convention considerations, I might suggest 'closeall'
or 'closefdset' or something similar... at least have 'close' in
name... :-)
Good Work,
John
It's fairly common, when spawning new processes, to want to make sure
all unwanted FDs are closed. Currently, the options for doing this are:
1) Use fcntl(fd, F_SETFD, FD_CLOEXEC) to set the close-on-exec flag
when the file is opened/cloned. This may not be practical if the
FD must remain open across some exec's, but not others. It is not
possible to ensure that FDs implicitly opened within library
functions have the close-on-exec flag set. It may be inefficient if
there are lots of opens and few execs.
2) Explicitly close unwanted FDs in the child, before the exec().
This suffers from the usual resource tracking problems (ie it's
easy to forget to close one - especially in a maze of pipe()/
dup()/dup2() calls designed to join the child's stdin/out/err
to the parent). It also requires that the FD's be visible to the
function - which may be difficult (the FD may be hidden within
another function somewhere).
3) Close all FDs except the ones you explicitly want to keep. This
is normally something like:
for (i = getdtablesize(); --i 2; )
close(i);
The advantage is that you are sure you don't miss any. The
disadvantage is that it requires a system call for each potentially
open FD - 600 on my system - whereas maybe only 4 or 5 are
actually open.
In the case of option 3, you only really need to attempt to close file
descriptors less then curproc-p_fd-fd_lastfile or even
curproc-p_fd-fd_nfiles, but these values aren't readily accessible
from userland. (And this still suffers the overhead of a userland
to kernel transition for each FD).
I'd therefore like to propose a new syscall that closes _all_ file
descriptors associated with a process, except for those passed as
1 bits in an fd_set. The proposed API is:
int cleanup_files(int nfds, const fd_set *leavefds);
where nfds specifies the number of fds in *leavefds to potentially
keep open (ie all fds = nfds will be closed).
The function would return the number of FDs closed.
The implementation would be along the lines of:
struct cleanup_files_args {
int nd;
fd_set *leave;
};
int
cleanup_files(p, uap)
register struct proc *p;
register struct cleanup_files_args *uap;
{
fd_set s_fdset;
fd_set *lset;
int error, nclosed = 0;
u_int i, ncpbytes, nfdbits;
struct filedesc *fdp = p-p_fd;
struct file **fpp;
char *fdfp;
if (uap-nd 0 || uap-leave = NULL)
return (EINVAL);
/* some daemons mught not have any file descriptors */
if (fdp == NULL) {
p-p_retval[0] = 0;
return (0);
}
if (uap-nd fdp-fd_lastfile)
uap-nd = fdp-fd_lastfile + 1;
/*
* Allocate just enough bits for the passed fd_set. Use the
* preallocated auto buffer if possible.
*/
nfdbits = roundup(uap-nd, NFDBITS);
ncpbytes = nfdbits / NBBY;
if (ncpbytes = sizeof s_fdset)
lset = s_fdset;
else
lset = malloc(ncpbytes, M_SELECT, M_WAITOK);
error = copyin(uap-leave, lbits, ncpbytes);
if (error != 0)
goto done;
fpp = fdp-fd_ofiles;
fdfp = fdp-fd_ofileflags;
for (i = 0; i uap-nd; i++, fpp++, fdfp++) {
if (!FD_ISSET(i, lset) *fpp != NULL) {
if (*fdfp UF_MAPPED)
(void) munmapfd(p, i);
error = closef(*fpp, p);
if (error != 0)
goto done;
nclosed++;
*fpp = NULL;
*fdfp = 0;
if (i fdp-fd_freefile)
fdp-fd_freefile = i;
}
}
for (; i = fdp-fd_lastfile; i++, fpp++, fdfp++)
if (*fpp != NULL) {
if (*fdfp UF_MAPPED)
(void) munmapfd(p, i);
error = closef(*fpp, p);
if (error != 0)
goto done;
nclosed++;
*fpp = NULL;
*fdfp = 0;
if (i fdp-fd_freefile)
fdp-fd_freefile = i;
}
}
while (fdp-fd_lastfile 0 fdp-fd_ofiles[fdp-fd_lastfile] == NULL)
fdp-fd_lastfile--;
done:
Re: tcp windowsize query?
Hi, Thanks for the reply(s)... If I understand you correctly, then: %route -n get netapp01 route to: 192.168.21.52 destination: 192.168.21.52 interface: fxp1 flags: UP,HOST,DONE,LLINFO,WASCLONED recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 150010 says that I have a specific interface route to get to the fileserver... The recv/send values being 0 means that we are using the default memory/window sizes. I'm not sure what the 3rd 4th columns are... (possibly what I'm looking for below)... From SunOS, I can get the following values: tcp_cwnd_max == 262144-- same as recv/send sizes, or windowsize ?? tcp_xmit_hiwat == 8192 tcp_recv_hiwat == 8192 udp_xmit_hiwat == 8192 udp_recv_hiwat == 8192 I'm now trying to determine how to get the hi lo water marks from FreeBSD... net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384-- SunOS uses 260k... net.inet.tcp.recvspace: 16384-- are these small? net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.pcbcount: 155 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 41600 net.inet.udp.log_in_vain: 0 If I may re-phrase.. How do I determine if the send/recv spaces are large enough, and if not, how many times I bumped into the wall? Thanks! John : net.inet.tcp.recvspace: 16384 :... :send/recv space might be what I'm looking for... : :They're the default send/receive window sizes, yes. You can tweak them :with socket ioctls on a per-socket basis. : :delayed ack sounds interesting : :Turning that off disables TCP slow-start. It's a huge performance :booster for things like SMB service, where you have lots of short-lived :TCP connections on a local net. Note that you can also tweak TCP send/receive window sizes on a per-route basis. The recvpipe and sendpipe parameters in route table entries can be changed. This will override the sysctl defaults. However, it may be a little complex for some people to grasp. The route table is a radix tree. In order to set the send/receive pipes for particular ip addresses you may have to create a route to that IP address in order to effect it rather then a more global route. For example, if I am getting the route to some host that runs through my default gateway, I get my default route entry. If I were to change this route entry I would be changing it for default, not just for idiom.com: route -n get idiom.com # route -n get idiom.com route to: 209.157.64.1 destination: default mask: default - this is not a host route! gateway: 209.157.86.1 - this is not a host route! interface: de0 flags: UP,GATEWAY,DONE,STATIC,PRCLONING recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 On the other hand, a route to another host on the same ethernet is usually specific: # route -n get lander route to: 209.157.86.6 destination: 209.157.86.6 interface: de0 flags: UP,HOST,DONE,LLINFO,WASCLONED recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 10411044 172 219 0 1500 1131 To change the pipes associated with a route, I would do the following. But in this example if I were to try to change the pipe size to idiom.com, I would actually wind up changing the pipe size for my default route. route -n change idiom.com -sendpipe BYTES -recvpipe BYTES route -n change 209.157.86.6 -sendpipe BYTES -recvpipe BYTES If I really want to change the pipe size just to idiom.com, I would have to first create a specific route to idiom.com, then change that. route add idiom.com default route -n change idiom.com -sendpipe BYTES -recvpipe BYTES -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
tcp windowsize query?
Hi, I'm trying to dynamically determine the tcp windowsize. Sysctl has the following to say, but the name/value pairs are not documented. net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.pcbcount: 156 net.inet.tcp.always_keepalive: 1 The rfc values are self-explanatory... send/recv space might be what I'm looking for... delayed ack sounds interesting Any comments, documentation, or pointers are much appreciated. I'm now off to dig through the kernel... Thanks, john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tcp windowsize query?
Hi, I'm trying to dynamically determine the tcp windowsize. Sysctl has the following to say, but the name/value pairs are not documented. net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.pcbcount: 156 net.inet.tcp.always_keepalive: 1 The rfc values are self-explanatory... send/recv space might be what I'm looking for... delayed ack sounds interesting Any comments, documentation, or pointers are much appreciated. I'm now off to dig through the kernel... Thanks, john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Strange select/poll behaviour [EBADF inconsistancy]
Hi,
The following program returns an inconsistant rc/errno value.
Setting a bit corresponding to filedescriptor which is not open
is only found when it is less than 20. ie:
Some example output follows along with the program. This is being
run on a -current system. If I open a file on fd 1023 then I receive
EBADF all the way through which is what I expect. Our product depends
on this behaviour (no, don't ask)...
The man page specfies:
The first nfds descriptors are
checked in each set; i.e., the descriptors from 0 through nfds-1 in the
descriptor sets are examined.
I've seen that select seems to call poll, but I haven't trace
all the way through poll yet.
Any comments, critiques, or stupid user pointers are appreciated.
Thanks!
John
[3] : Bad file descriptor
[4] : Bad file descriptor
[5] : Bad file descriptor
[6] : Bad file descriptor
[7] : Bad file descriptor
[8] : Bad file descriptor
[9] : Bad file descriptor
[ 10] : Bad file descriptor
[ 11] : Bad file descriptor
[ 12] : Bad file descriptor
[ 13] : Bad file descriptor
[ 14] : Bad file descriptor
[ 15] : Bad file descriptor
[ 16] : Bad file descriptor
[ 17] : Bad file descriptor
[ 18] : Bad file descriptor
[ 19] : Bad file descriptor
[ 20] Timeout
[ 21] Timeout
[ 22] Timeout
[ 23] Timeout
[ 24] Timeout
[ 25] Timeout
#include stdio.h
#include unistd.h
#include errno.h
#include fcntl.h
#include sys/time.h
#include sys/stat.h
static struct timeval nowait_s = {0, 0}; /* poll, no wait */
static struct timeval wait_s = {0, 100}; /* poll, wait 1 sec*/
fd_set local_rfd;
fd_set local_wfd;
main()
{
intn;
struct timeval *tp;
intmax_fd = -1;
intcount;
intbytes;
intwait_time;
int i;
char * p;
char buffer[256];
fprintf(stderr,"FD_SETSIZE = %d\n",FD_SETSIZE);
for(i=3;i40;++i)
close(i);
for(i=3;i40;i++)
{
bzero(local_rfd,sizeof(local_rfd));
bzero(local_wfd,sizeof(local_wfd));
FD_SET(i,local_rfd);
tp = wait_s;
n = select (200,local_rfd, 0, 0, tp);
if (n 0 )
{
sprintf(buffer,"[%5d] ",i);
perror(buffer);
continue;
}
if (n == 0 )
{
printf("[%5d] Timeout\n",i);
}
if (n 0)
{
if ( FD_ISSET(0, local_rfd) )
{
printf("[0] READ\n");
}
if ( FD_ISSET(i, local_rfd) )
{
printf("[%5d] READ\n",i);
}
}
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
sigaction inconsistancy (here I go again)
Hi,
Running -current...
I'm trying to verify SIGFPE handling and am finding some
interesting issues. In the following test program, a divide
by zero is done and the SIGFPE delivered.
$ ./fp
sig == 8
code== 0
z has the value 1.00
It seems that from machine/trap.h the value of code should
have been:
/* codes for SIGFPE/ARITHTRAP */
#define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */
ie: 3 and not 0.
Also, I haven't gone into the code yet, but the floating point
registers are not saved into the sigcontext so that they can be
inspected and modified as appropriate.
Thanks,
John
ps: I also noted that SA_RESTART is not documented in the man page
with the other mask bits, but instead is mentioned in a follow-on
statement. Just slightly misleading.
--
#include stdio.h
#include floatingpoint.h
#include signal.h
void fphand(int sig, int code, struct sigcontext *scp)
{
fprintf(stderr,"sig == %d\n",sig);
fprintf(stderr,"code== %d\n",code);
return;
}
void
setup()
{
int rc;
struct sigaction act, oact;
act.sa_handler = fphand;
act.sa_mask= 0;
act.sa_flags = SA_RESTART; /* not doc'd in man page */
rc = sigaction(SIGFPE, act, oact);
if (rc) {
perror("sigaction");
exit(1);
}
return;
}
double
doit(double x, double y)
{
return(x / y);
}
int
main()
{
double x,y,z;
fp_except_t mask = FP_X_DZ;
setup();
fpsetmask(mask);
x = 1.0;
y = 0.0;
z = doit(x,y);
printf("z has the value %f\n",z);
return((int) z);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Strange select/poll behaviour [EBADF inconsistancy]
Hi,
The following program returns an inconsistant rc/errno value.
Setting a bit corresponding to filedescriptor which is not open
is only found when it is less than 20. ie:
Some example output follows along with the program. This is being
run on a -current system. If I open a file on fd 1023 then I receive
EBADF all the way through which is what I expect. Our product depends
on this behaviour (no, don't ask)...
The man page specfies:
The first nfds descriptors are
checked in each set; i.e., the descriptors from 0 through nfds-1 in the
descriptor sets are examined.
I've seen that select seems to call poll, but I haven't trace
all the way through poll yet.
Any comments, critiques, or stupid user pointers are appreciated.
Thanks!
John
[3] : Bad file descriptor
[4] : Bad file descriptor
[5] : Bad file descriptor
[6] : Bad file descriptor
[7] : Bad file descriptor
[8] : Bad file descriptor
[9] : Bad file descriptor
[ 10] : Bad file descriptor
[ 11] : Bad file descriptor
[ 12] : Bad file descriptor
[ 13] : Bad file descriptor
[ 14] : Bad file descriptor
[ 15] : Bad file descriptor
[ 16] : Bad file descriptor
[ 17] : Bad file descriptor
[ 18] : Bad file descriptor
[ 19] : Bad file descriptor
[ 20] Timeout
[ 21] Timeout
[ 22] Timeout
[ 23] Timeout
[ 24] Timeout
[ 25] Timeout
#include stdio.h
#include unistd.h
#include errno.h
#include fcntl.h
#include sys/time.h
#include sys/stat.h
static struct timeval nowait_s = {0, 0}; /* poll, no wait */
static struct timeval wait_s = {0, 100}; /* poll, wait 1 sec*/
fd_set local_rfd;
fd_set local_wfd;
main()
{
intn;
struct timeval *tp;
intmax_fd = -1;
intcount;
intbytes;
intwait_time;
int i;
char * p;
char buffer[256];
fprintf(stderr,FD_SETSIZE = %d\n,FD_SETSIZE);
for(i=3;i40;++i)
close(i);
for(i=3;i40;i++)
{
bzero(local_rfd,sizeof(local_rfd));
bzero(local_wfd,sizeof(local_wfd));
FD_SET(i,local_rfd);
tp = wait_s;
n = select (200,local_rfd, 0, 0, tp);
if (n 0 )
{
sprintf(buffer,[%5d] ,i);
perror(buffer);
continue;
}
if (n == 0 )
{
printf([%5d] Timeout\n,i);
}
if (n 0)
{
if ( FD_ISSET(0, local_rfd) )
{
printf([0] READ\n);
}
if ( FD_ISSET(i, local_rfd) )
{
printf([%5d] READ\n,i);
}
}
}
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
sigaction inconsistancy (here I go again)
Hi,
Running -current...
I'm trying to verify SIGFPE handling and am finding some
interesting issues. In the following test program, a divide
by zero is done and the SIGFPE delivered.
$ ./fp
sig == 8
code== 0
z has the value 1.00
It seems that from machine/trap.h the value of code should
have been:
/* codes for SIGFPE/ARITHTRAP */
#define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */
ie: 3 and not 0.
Also, I haven't gone into the code yet, but the floating point
registers are not saved into the sigcontext so that they can be
inspected and modified as appropriate.
Thanks,
John
ps: I also noted that SA_RESTART is not documented in the man page
with the other mask bits, but instead is mentioned in a follow-on
statement. Just slightly misleading.
--
#include stdio.h
#include floatingpoint.h
#include signal.h
void fphand(int sig, int code, struct sigcontext *scp)
{
fprintf(stderr,sig == %d\n,sig);
fprintf(stderr,code== %d\n,code);
return;
}
void
setup()
{
int rc;
struct sigaction act, oact;
act.sa_handler = fphand;
act.sa_mask= 0;
act.sa_flags = SA_RESTART; /* not doc'd in man page */
rc = sigaction(SIGFPE, act, oact);
if (rc) {
perror(sigaction);
exit(1);
}
return;
}
double
doit(double x, double y)
{
return(x / y);
}
int
main()
{
double x,y,z;
fp_except_t mask = FP_X_DZ;
setup();
fpsetmask(mask);
x = 1.0;
y = 0.0;
z = doit(x,y);
printf(z has the value %f\n,z);
return((int) z);
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Connect and so on..
Ahhh.. RACF... MVS... Music to my ears...
And speaking of resource managers... don't forget
the ESM on CMS for SFS... :-)
I would have spared the bandwidth.. but it's worth noting
that we run a production system that installs user exits into
the Shared File System on CMS via the Callable Services Libraries
(CSL). ie: We take over the CSL entry points.
Whenever accessing files within a given Filepool, we
dynamically redirect the I/O to our FreeBSD systems where the
data actually resides. No modifications are then required to the
application running on the mainframe, and they have no idea the
data isn't local.
Never underestimate the power of good user exits and the
ability to implement your own External Security Manager...
Just my 0.02 :-)
John
ps: I've always pronounced it 'RACK-F' (as in the letter F).
Date: Tue, 06 Jul 1999 09:52:12 -0700
From: Mike Smith m...@smith.net.au
Could you point me to more about this (RAGF) scheme?
[ML] I don't know if I have spelled it out correctly, but this
is the authentication scheme used on mainframes (IBM at least) where all
syscalls are routed through the authentication subsystem before
proceeding. However, the subsystem seems to reside in kernel, and is
(possibly precompiled) table driven so that it does not cause gross
inefficiency.
RACF IIRC, often pronounced Rack Off.
Mike's pronunciation notwithstanding :-)
From 1982 - 1992, I was involved in (among other things) installing and
implementing RACF in IBM MVS{,/{X,ES}A} (mainframe) systems. During the
bulk of that time, I also wrote system exits (packaged as usermods) to
make use of RACF capabilities to control various aspects of the system's
operation -- for example, to control which disk drives were used for
creating files. (This latter was intended to allow one set of drives to
be used for the files that were necessary for bringing MVS up, a different
(non-intersecting) set that was used (only) for production files, and
another set that was for normal user files. Worked reasonably well,
too -- despite some of the uglier interfaces available to folks who
wanted to try to implement something like this.)
Assuming that the product with which I retain some familiarity is the
one in question, characterizing it as where all syscalls are routed
through the authentication subsystem before proceeding is somewhat of
an over-simplification (since only a few resource managers (as they
were (are?) called) were present in the system -- OPEN/CLOSE/EOV was one
of the first ones).
However, I don't expect that additional details of RACF are likely to be
of general interest to -hackers, so I'll spare further bandwidth on
that... but I'm available as a resource for out-of-band discussions of
RACF(-like) facilities.
Cheers,
david
- --
David Wolfskill d...@whistle.comUNIX System
Administrator
voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
--
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Login validation by home directory location (PAM?)
Hi, I have an administration problem that I'm trying to solve and I'm looking for comments and ideas. I have about 6000 users in the passwd file. We have a number of compute servers available to these users which (the boss) wants to have allocated according to where the users home directory is located. All the home directories are mounted via amd on a /nfs/machine.name.domain/ mount point. user1:/nfs/m1/usr/home/user1 user2:/nfs/m1/usr/home/user2 user3:/nfs/m1/usr/home/user3 For example, I want to allow user2 access to host server2, but not hosts server1 or server3. I don't want to have alot of passwd file maintenance, so I thought about modifing login to validate on the users home directory. So, in auth_traditional(), I check to see where the home directory is, and if it is valid for the current machine I authorize the login, otherwise I output an access denied msg and return failure. There must be a better way of doing this, but I don't see how. I've looked at PAM, but I don't understand how I could make this type of facility work except maybe in the pam_authenticate() routine. However, this seems complicated compared to simply modifying auth_traditional(). I'd appreciate any comments from folks who have done anything similar or used PAM to solve a related type of management issue. Thanks! John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sgmlformat making release
Hi,
I too see this type of failure until I can download the appropriate
distfiles into /usr/ports/distfiles...
The file /etc/resolv.conf is copied from /etc to the chroot
area and is probably ok. I typically find that my upstream
domain name server is not responding correctly when this happens.
From /usr/src/release/Makefile:
if [ -f /etc/resolv.conf ]; then \
cp -p /etc/resolv.conf ${CHROOTDIR}/etc; \
fi
Again, From /usr/src/release/Makefile, this should copy any ports
from /usr/ports/distfiles into the associated chroot area:
if [ -d ${DISTFILES}/ ]; then \
cp -rp ${DISTFILES} ${CHROOTDIR}/usr/ports/distfiles; \
fi
Hope this helps.
-John
Wilko Bulte wi...@yedi.iaf.nl writes:
sgmlformat-1.7.tar.gz doesn't seem to exist on this system.
Attempting to fetch from
http://fallout.campusview.indiana.edu/ports/distfiles/.
fetch: reading reply from fallout.campusview.indiana.edu: Operation timed
out
Attempting to fetch from
ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/.
fetch: ftp.freebsd.org: Host name lookup failure
Couldn't fetch it - please try to retrieve this
port manually into /usr/ports/distfiles/ and try again.
*** Error code 1
Stop.
*** Error code 1
The build is running in a chroot tree which does not have a valid
/etc/resolv.conf.
yedi#ls /usr/ports/distfiles
docbk241.tar.Z isoENTS.zip linuxdoc-1.1.tar.gz
docbk30.tar.Z jade-1.2.1.tar.gz sgmlformat-1.7.tar.gz
This is outside the chroot tree.
DES
- --
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
--
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
ECC drive data recovery?
Hi, We're seeing the following message on one of the drives we have mounted in a server system. (da23:ahc1:0:14:0): READ(10). CDB: 28 0 0 46 aa 50 0 0 40 0 (da23:ahc1:0:14:0): RECOVERED ERROR info:46aa77 asc:18,7 (da23:ahc1:0:14:0): Recovered data with ECC - data rewritten sks:80,1a I've already got a replacement coming, but I was curious to know if anyone knows if the above means the existing data was recovered and written to the same, or different(spare) location? Thanks, John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
