Running out of bufferspace
Hi,
First of all happy new year, etc. =)
My problem: I'm writing a device driver kernel module that uses kernel
level sosend() from the d_write write() function. But it runs out of
bufferspace (error 55) when I really stress it (sending 15 megs in 3-4 secs
over UDP with 32 or 60K packets).
Thing is, my mbufs are fine, peak is 1/3rd of max. I also use sowriteable()
to check if it's safe to send, and sbspace() tells me I have the full 128K
sndbuf that I configured available.
So I have 2 questions...
1) which buffers are there that I can run out of here and where can I check
their status?
2) Should I free() the uio I get from userspace after I have passed it to
the sosend?
Side note on 1): after I run out of bufferspace with my little driver the
box continues to function fine as far as I can tell, except that
mount_smbfs has trouble:
[ root@hera:~ ] # truss mount -t smbfs //drwilco@ceres/D$ /ceres/d_drive/
readlink("/etc/malloc.conf",0xbfbffa94,63) ERR#2 'No such file or
directory'
mmap(0x0,4096,0x3,0x1002,-1,0x0) = 671551488 (0x28071000)
break(0x807c000) = 0 (0x0)
break(0x807d000) = 0 (0x0)
open(".",0,00) = 3 (0x3)
chdir(0xbfbff090)= 0 (0x0)
sigaction(SIGSYS,0xbfbfeaac,0xbfbfea94) = 0 (0x0)
__getcwd(0xbfbff090,0x400) = 0 (0x0)
sigaction(SIGSYS,0xbfbfea94,0x0) = 0 (0x0)
fchdir(0x3) = 0 (0x0)
close(3) = 0 (0x0)
stat("/ceres/d_drive",0xbfbfeff4)= 0 (0x0)
fork() = 3331 (0xd03)
smbfs: can't get server address: syserr = No buffer space available
SIGNAL 20
wait4(0xd03,0xbfbff088,0x0,0x0) = 3331 (0xd03)
exit(0x1) process exit, rval = 256
A different tactic could be that I pull a m_devget() or some other mbuf
creation stunt and copy the data from the uio into the mbuf. Do I have to
clear the mbuf and/or uio after passing that mbuf to sosend?
Any pointers (even to some docs, though I've done heavy googling) or hints
would be greatly appreciated.
DocWilco
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Running out of bufferspace
>[ root@hera:~ ] # truss mount -t smbfs //drwilco@ceres/D$ /ceres/d_drive/
>readlink("/etc/malloc.conf",0xbfbffa94,63) ERR#2 'No such file or
>directory'
--SNIP--
>fork() = 3331 (0xd03)
>smbfs: can't get server address: syserr = No buffer space available
>SIGNAL 20
>wait4(0xd03,0xbfbff088,0x0,0x0) = 3331 (0xd03)
>exit(0x1) process exit, rval = 256
This of course is useless, since mount fork()s and mount_smbfs does the
real stuff which isn't visible
So here's the real deal. (After using my device once and not running out of
bufferspace on that run)
[ root@hera:~ ] # truss mount_smbfs //drwilco@ceres/C$ /ceres/c_drive/
---SNIP---
ioctl(3,SIOCGIFADDR,0x8051440) = 0 (0x0)
ioctl(3,SIOCGIFNETMASK,0x8051440)= 0 (0x0)
ioctl(3,SIOCGIFFLAGS,0x8051460) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x8051480) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x80514a0) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x80514c0) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x80514e0) ERR#6 'Device not configured'
close(3) = 0 (0x0)
socket(0x2,0x2,0x0) = 3 (0x3)
setsockopt(0x3,0x,0x20,0xbfbfeef8,0x4) = 0 (0x0)
bind(0x3,{ AF_INET 192.168.0.1:0 },16) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
close(3) = 0 (0x0)
socket(0x2,0x2,0x0) = 3 (0x3)
setsockopt(0x3,0x,0x20,0xbfbfeef8,0x4) = 0 (0x0)
bind(0x3,{ AF_INET 192.168.0.1:0 },16) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)ERR#55 'No buffer space
available'
close(3) = 0 (0x0)
mount_smbfs: write(2,0xbfbfe884,13) = 13 (0xd)
can't get server addresswrite(2,0xbfbfe8a4,24) =
24 (0x18)
: syserr = No buffer space available
write(2,0xbfbfe874,37) = 37 (0x25)
sigprocmask(0x1,0x2805cbe0,0xbfbff0ac) = 0 (0x0)
sigprocmask(0x3,0x2805cbf0,0x0) = 0 (0x0)
exit(0x1) process exit, rval = 256
So again... which buffer(s) could this be, and how do I check its/their status?
Doc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Running out of bufferspace
At 11:42 1-1-2002 -0500, [EMAIL PROTECTED] wrote: >Just note that "no buffers" often means that the queue is full, not that you >are out of system buffers. You may be chasing a ghost. Well a queue should be cleaned shouldn't it? The mount_smbfs fails even hours after I run the stresstest on my device. And which queue exactly are we talking about, and where/how do I check its status? Thanx, Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running out of bufferspace
>I think that fact that you still see the problem "hours later" indicates that >some internal device doesnt have a process to "revisit" the queue once you've >filled it. You can do the same thing fairly easily with a trafic generator >that uses raw socketscheck the ifp->if_snd.ifq_len for the device you are >sending on Well turns out my problem was two-fold. I'm indeed running out of ifp->if_snd on my xl0 interface, but I was also running out of space on my vmnet1 interface, but since I don't always run vmware it wasn't being emptied. Guess mount_smbfs needs a little patch.. I'll work on that =) Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
>I suppose we'll always get a couple hundred bytes in edgewise anyway, but >it all makes for an interesting exercise. I wonder about the robustness >of other operating systems to such an attack... I think malicious people will point their ears at this line here ^^ Maybe make the minimum size a sysctl? Set default at the current number and put it in a "how to make your FreeBSD more robust" document that this might be raised to a higher number? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
>I suppose so, but then you won't be able to connect to machines with >miniscule path MTU's, and that should definately be a warning. But then >it beats Linux which allows the path MTU to be reduced to 69 bytes (ouch!). Ouch indeed. Well default would be what we have now, but you'd be able to tune it. The way I see it is that the attack would be most common on the internet, and minuscule MTUs would most probably occur in specialistic environments. Admins of potential targets would raise the minimum to a nice value (say 512 or 1024), and print a message when something requests something below this minimum, for troubleshooting ease. Or maybe a soft limit and a hard limit. Soft limit triggers a message, hard limit is enforced. Out of curiosity, where do MTUs < ~512 occur? >The best solution is to try and make sure that the mustfrag messages are >coming from real connections we have open, and perhaps even, make sure >that the host on the remote end hasn't already ACK'ed a packet whose >header shows up in the ICMP mustfrag. (It would be kind of silly to get >an ACK and a mustfrag.) Although, then it is just a race to see who gets >their packet to us first. What about a mustfrag flood? Wouldn't this be a tad much to process? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
>I don't have the RFC handy, but aren't all Internet connected hosts >required to support a minimum MTU of 576 from end to end with no >fragmentation? Thus if we ever got an MTU less than 576 we should >ignore it. Right? If we're on the internet yes. If you're in an environment other than one connected to the internet (do those even exist ) no. Hence my tuneable sysctl idea. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Oh my god, Google has a USENET archive going back to 1981!
>Does that just have LAN support, or does it support internet play too? I >forgot when they made that transition... If it even has LAN support, you should be able to play it over the internet. Just get creative with vtun, tap and ng_bridge =) DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Very High Speed TCP Session ... How I can achieve ?
At 22:50 8-1-2002 -0800, you wrote: >I would like to have a very High Throughput TCP session Between two Free-BSD >but I'm unable to get Socket buffer larger than 256 Kbytes. > >My test scenario is a bulk FTP in a (totally empty) test Pipe of >1 Gbit/s and 170 ms of delay so my pipe size over 2 Mbytes. > >Thanks for any suggestion or reference you can give. I recall a thread on [EMAIL PROTECTED] about testing of very high speeds over WAN. I recall it being quite extensive. I suggest you browse the archives for it. Try searching for "internet2", since I recall that being mentioned in the thread. I don't recall using the word recall so often in so small a space. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [nicole@unixgirl.com: What is biord?]
> > Hello > I have a mysql database that seems slow and when looking at it in top it >always seems to be in a state of biord > What the heck is biord I can't find this anywere > > Thanks Block I/O ReaD (if I'm not terribly mistaken. I'm thinking it could be Buf IO too, but that would be confusing to the layman =) ) Basically it's doing a lot of read IO or your disks are very slow. Which is not a big surprise because databases normally spend a lot of time in disk IO. I'm not up to speed on MySQL tuning, but I've done a fair amount of Oracle tuning, and there's two approaches that can be taken: 1) lessen the amount of IO. 2) make the IO faster. Making it faster can be the most expensive in money (buying SCSI RAID arrays), and not always as effective. Lessening the IO is usually a little more costly in the time department, but can be a LOT more effective. When lessening the IO, again there are mainly 2 things to be done. 1) have more blocks buffered. 2) make queries use less blocks More buffering is an easy fix on a machine with lots of memory. I am not familiar with MySQL's internals, but Oracle uses its own buffercache (optimized for RDBMS usage) and you can specify how big that should be. When a machine has 512megs of RAM and the database is the only thing on the machine, making the buffers take up half of that is not a silly thing at all. (You wont believe how often I come across machines that are ill configured that way. HUGE amount of RAM, and only 5% is used...) Making queries use less blocks is the hardest part, but a lot of the times placing indexes on columns that are used in joins or in WHERE clauses can make a huge difference. Also not using too many tables in a single query helps (eliminate wannahave columns in favor of faster musthave results). You could always find some MySQl guru's of course =) I hope this sheds a little light on the subject, DocWilco P.S.: this really belongs on [EMAIL PROTECTED] so I'm cross posting this answer there To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about some defines
At 22:45 24-1-2002 +0100, Aleksander Rozman - Andy wrote: >Hi ! > >I came accross some weird define in mbuf.h > >#if 0 >#define MT_SOOPTS 10 >#endif > >When will this define work? I need this value in my code, and I can't make >it work. For now I used value 10 directly, but this shouldn't be done this >way. Is this type of define, defining value that we shouldn't use or why >is this writen in such way. > >Andy Stuff between #if 0 and #endif is ignored by the compiler, since 0 equals false. Doc >** >* Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * >* [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * >*[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * >* Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* >* ICQ-UIC: 4911125 * >* PGP key available *http://www.atechnet.dhs.org/~andy/ * >** > > >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
Re: Again Softupdates on 4.5
>It sounds as if the default five seconds isn't always enough time for >your disk to do its job. (I've only done poweroff on an idle system so >I haven't run into such a problem myself.) > >I don't see it would hurt anything for this default to be increased to >help out this problem. But what value would be good? Wouldn't the Right Thing (tm) be to ask the controllers/disk whether or not their caches are clean? Assuming such a thing is even possible. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A question about make install
At 14:25 31-1-2002 -0500, Chris Faulhaber wrote: >On Thu, Jan 31, 2002 at 01:19:21PM -0500, Zhihui Zhang wrote: > > > > Each time I modify some kernel source, I have to do the following two > > steps: > > > > (1) make > > (2) make install > > > > The second step also re-installs ALL modules even if I only modifies the > > kernel code (not any of the module code). Is there a better way to do > > this? Thanks, > > > >You can set NO_MODULES on the command line (-DNO_MODULES) or in >/etc/make.conf (NO_MODULES=yes) to prevent modules from being >built/installed. Or use 'make kernel' and 'make kernel-install' (and there's a 'make kernel-depend' too) Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: natd UDP errors with PPP demand dial
>Natd is already running when a ppp session is set up each time. So is >ipfw. Ipfw is configured thourgh its own configuration file. So, it >seems I shouldn't have to set anything extra up in the ppp.linkup. 1) Have you told natd the interface is dynamic and might change IPs? 2) If you're using ppp, why even bother with natd? The NAT in ppp uses the exact same libalias and gives you less headaches with ipfw because the translation on incoming packets is done before they hit ipfw, and outgoing after ipfw let them go. I can tell you this helps a lot when trying to use dynamic rules. Or am I missing some part of the picture? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re[4]: natd UDP errors with PPP demand dial
> I think I have to stick with the conventional setup, and go back to > trying to answer my original questions: > > 1. Why is the machine trying to send packets to its own previous IP? > 2. How do I stop that? 1) Maybe the IP change isn't getting through to natd like it should. 2) Have ppp kill -9 natd on link down and start natd on linkup. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lsof and listening processes on 4.5
> >4.3: >inetd 157 root4 IPv4 0xeee7f720 0t0 TCP *:ftp (LISTEN) >inetd 157 root5 IPv4 0xeee7f500 0t0 TCP *:telnet (LISTEN) >inetd 157 root6 IPv6 0xeee7f2e0 0t0 TCP *:telnet (LISTEN) > >4.5: >inetd 180 root4 IPv4 0xeb159cc0 0t0 TCP *:* >inetd 180 root5 IPv4 0xeb15adc0 0t0 TCP *:5611->*:49308 >inetd 180 root6 IPv4 0xeb15aba0 0t0 TCP *:5611->*:49325 Did you recompile lsof after upgrading from 4.3 to 4.5? If not, I'd suggest doing that since this looks like kernel/userland desynch to me. If you did recompile, maybe we broke lsof =) Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AWK/perl hacker needed to assist the Sparc64 port
At 08:49 12-2-2002 -0800, David O'Brien wrote: >In rev 1.20 of sys/kern/vnode_if.pl Eivind converted this from a >Bourne+AWK script into a Perl script. Well that just makes porting to >new architectures VERY difficult as the boot strapping of Perl 5 is quite >difficult. > >A shell hacker could really help out the FreeBSD/sparc64 porting effort >by updating vnode_if.pl rev 1.19 to have all the functionality the perl >version has today. I'll have a stab at it. No guarantees though.. =) Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
At 14:59 17-2-2002 +, Dominic Marks wrote: >On Sun, Feb 17, 2002 at 06:33:43AM -0800, Hiten Pandya wrote: > > Is there any In-Kernel HTTP Server for FreeBSD, like there is > > kHTTPD for Linux? > >Ive never seen or heard of one, at least not one available to the >general public. Services should be executed in the user space, thats >what its for. Cross-polluting these user/kernel environments is to be >discouraged. I've heard of a netgraph module that does HTTP, but I'm not sure where unfortunately. Also this sort of thing can be useful for embedded devices. My EUR0.02 DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Posix question
At 16:32 20-2-2002 -0600, Lane, Frank L wrote: >Hi List, > >I'm facing a serial write problem. Posix provides a function tcdrain () >that blocks until all serial data has been written from the card. Is there >an analogous function in the gnu c compiler for windows platforms? Does the >gnu c compiler try to give you posix functionality within the windows >environment? Thank you for any help you'll offer. A few things. 1) the GNU C Compiler doesn't provide the tcdrain() function, but libc does this. 2) if you're looking for UNIX like behavior on windows system (like GCC) I suggest you check out www.cygwin.com. I'm sure they can answer your question much better than the FreeBSD community. 3) why not use FreeBSD instead of windows? (not trying to be zealous, just curious, and you did post to a FreeBSD mailing list) Hope that helps you out, Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD, SMP and Performance Speeds?
>I have RTFM'd, with little luck. Can some enlightened soul impart knowledge >upon me, thus letting me know why any kernels compiled with SMP enabled seem >to be slowing the whole system down? Throughput goes down by 40%. Tasks >take twice as long to run, etc, etc... What sort of throughput? What sort of processes are you running? Do you actually have multiple processes fighting for CPU? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: oracle 8.1.7.0.1 installation successful, anyone?
At 09:46 28-2-2002 -0600, Theodore Hope wrote: >We've tried installing Oracle 8.1.7.0.1 (for Linux) under >FreeBSD 4.5-release and end up with two "jre" processes >eating all the CPU and the infamous >"kernel trap 9 with interrupts disabled" message scrolling on >the console. This has been reported before by others, and >I'm wondering if anyone has successfully installed Oracle >(8.1.x or 9.x) under 4.5-Release. We can't tell if the >main problem is with the Linux emulation, or what; thus >my cross-posting. I didn't succeed in installing 8.1.7 either, but I've been semi-succesful with 9.0.1 lately. I had to pull a few tricks but I got it to install. However, the relinking of several binaries (like the RDBMS one) failed with some glibc errors, so there's something not completely right with my linux libs. 9.0.1's installer uses a JDK on the CD, but I ran it with the linux-jdk1.3.1 too. The Universal Installer is just very sensitive pacakge =( I used the RedHat7.1 port and added some devel rpms, made the oracle user's shell /compat/linux/bin/bash (try a 'uname -a' when logged in with a user setup like that, it's freaky) and I had to make a /compat/linux/etc/mtab file to keep the installer from bombing when it tries to figure out which filesystems you have. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FreeBSD, SMP and Performance Speeds?
>Regarding my SMP query, Doc asks: > > What sort of throughput? What sort of processes are you > > running? Do you > > actually have multiple processes fighting for CPU? > >Yes, I'm using netperf, iperf or nttcp to measure TCP throughput using the >server (the box in question) in response to ten simultaneous clients. >Chariot allegedly did not show the performance hit. But then, even >measuring the process time to run a single simple script shows ~half the >speed with SMP enabled. I'm no expert but I'm going to have a shot at this anyways. Comments are welcome. =) When you run a benchmark or a process where network performance is the bottleneck instead of CPU time, you're not going to have SMP help you at all. Currently in the 4.X kernels the kernel can run on only one CPU at a given time. That means that when raw network performance is the bottleneck only one CPU is actually doing the work, and running in SMP mode gives you a lot of overhead. The same is true for a situation where a single single-threaded process is involved. A single-threaded process can only run on one CPU at a given time, so having a 2nd CPU only adds overhead. Have you tried running 4 jobs simultaneously and timing that? So what sort of application are you using exactly, is it multi-process, multithreaded, CPU intensive, network intensive? Where do you think the bottleneck in the performance lies at this moment? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how do I see the current number of PTYs in use ?
At 00:33 2-3-2002 -0500, Joe Abley wrote: >On Saturday, March 2, 2002, at 12:23 , Paul Halliday wrote: >>[00:12am]-root@dissent~# pstat -t | grep 'tty[pqrsPQRS]' | grep OCc | wc -l > >Oh, and > > pstat -t | egrep -ic 'tty[pqrs].* OCc ' > >saves two forks. And forks aren't cheap at all! See: http://www.pricepoint.com/AllForks.html Are we done being silly? =) Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A weird disk behaviour
At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: >On Tue, 5 Mar 2002, Julian Elischer wrote: > > > > > more writes fit in the disk's write cache? > >For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * >4096 bytes in all (assuming the random number distributes evenly between 0 >and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc >-Zhihui > > > On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > > > > > > > I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > > > This situation is like this: > > > > > > +-++++++++++---+-- > > > | |||||||||| | > > > +-++++++++++---+-- > > > > > > Each block is of fixed size, say 8192 bytes. Now I have a user program > > > writing each contiguously laid out block sequentially using /dev/daxxx > > > interface. There are a lot of them, say 15000. I write the blocks in two > > > ways (the data used in writing are garbage): > > > > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > write part of it. Exactly how many bytes are written inside each > block is > > > determinted by a random number between 512 .. 8192 bytes (rounded up a > > > to multiple of 512 bytes). > > > > > > I find out the the performance of (2) is several times better than the > > > performance of (1). Can anyone explain to me why this is the case? > > > > > > Thanks for any suggestions or hints. > > > > > > -Zhihui > > > > > > > > > > > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A weird disk behaviour
Wait a minute, you are saying that it takes longer to write the incomplete blocks? Doc At 18:19 5-3-2002 -0500, Zhihui Zhang wrote: >Several times slower! The point is that writing less data performs >worse. So I call it weird. > >-Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Swapping performance
>Once Dimitar posts his test program, we'll be able to generate a more
>clear picture about what's really happening. Until then, please control
>the ranting.
Am I the only one who saw that he attached it to his 1st mail?
Here you go:
#include
#include
#include
#define MALLOC_SIZE 1024*1024*256
int main(int argc, char **argv) {
char *ptr;
int i, i_count;
int j;
ptr = (char *) malloc(MALLOC_SIZE);
bzero(ptr, MALLOC_SIZE);
i_count = MALLOC_SIZE / 16;
fprintf(stderr, "*");
for (i = 0; i < i_count; i ++) {
ptr[i >> 4] = ptr[(i >> 3) + 1]++;
}
fprintf(stderr, "#");
for (j = 0; j < i_count; j ++) {
ptr[j << 4] = ptr[(j >> 3) + 1]++;
}
free(ptr);
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: logging securelevel violations
>I think this would be useful, but I would be concerned about the rate at >which these messages could come when someone is actively attacking a system. >Perhaps such messages could go through a rate limiter mechanism similar to >that now used by the network interfaces. syslogd already has a "last message repeated N times" Also most things you do that are negated by securelevel you can only do as root, so I don't see how someone without elevated privileges could fill up your logs with these messages anyway. These audit messages could be a nice way of finding out that someone has root when they shouldn't. And if root is compromised you have bigger things to worry about then overflowing log files. I personally think this would be very useful. Maybe supply a sysctl for turning on and off. And for the newbies in the house turn it on by default. That way the "Why can't I get this to work?" caused by securelevel settings would be answered a lot quicker. I'm still a junior kernel hacker myself, but I'd say this would be a perfect junior kernel hacker project. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: logging securelevel violations
At 02:36 12-3-2002 +0200, Giorgos Keramidas wrote: >On 2002-03-11 22:00, Rogier R. Mulhuijzen wrote: > > > > >I think this would be useful, but I would be concerned about the rate at > > >which these messages could come when someone is actively attacking a > > >system. > > >Perhaps such messages could go through a rate limiter mechanism similar to > > >that now used by the network interfaces. > > > > syslogd already has a "last message repeated N times" > >Rate limiting is still needed: > > while true ;do > echo "" > /dev/ad0 > echo "" > /dev/ad1 > done > >This would cause syslogd to go nuts! crw-r- 2 root operator 116, 0x00010002 Jan 20 03:13 /dev/ad0 Only if you're root. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: logging securelevel violations
At 16:07 12-3-2002 +0200, Giorgos Keramidas wrote: >On 2002-03-12 08:29, Rogier R. Mulhuijzen wrote: > > At 02:36 12-3-2002 +0200, Giorgos Keramidas wrote: > > >Rate limiting is still needed: > > > > > >while true ;do > > >echo "" > /dev/ad0 > > >echo "" > /dev/ad1 > > >done > > > > > >This would cause syslogd to go nuts! > > > > crw-r- 2 root operator 116, 0x00010002 Jan 20 03:13 /dev/ad0 > > > > Only if you're root. > >Well, you get the idea. I meant that syslog will catch the repetitive >messages, only if no other messages are sent between the two or more lines >that match :-( What I meant is, the file permissions on /dev/ad0 stop ordinary users from even reaching the point where the secure level denies the attempt. And so only root can actually trigger the secure level violation log message. So it cannot be used to maliously fill the logs. Unless someone has root, and then you have bigger problems. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel newbie.
At 04:40 14-3-2002 -0600, Abdul Basit wrote: >Hi >can anyone give me some url / book name for >FreeBSD kernel internals ? > >thanks >- basit The Design and Implementation of the 4.4BSD Operating System http://www.amazon.com/exec/obidos/ASIN/0201549794/qid=1016123716/sr=8-4/ref=sr_8_67_4/002-8148438-7702402 It discusses in depth the 4.4BSD kernel, just about the direct ancestor of FreeBSD Doc P.S.: It's been on my Amazon wish-list for a while -> http://www.amazon.com/exec/obidos/wishlist/JVESPRQND4OJ/ref=wl_s_3/002-8148438-7702402 (nudge nudge wink wink) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: logging securelevel violations
At 09:23 16-3-2002 -0500, Robert Watson wrote: > Second, these >warnings would be generated during normal operations, as a number of >applications attempt to load kernel modules when they need them, including >ppp. Generating spurious warnings as part of normal system activity isn't >necessarily a useful activity, and tends to result in more calls for help >on questions@. I don't know. Today I had someone who had trouble installing a new kernel. I asked him what secure level he used and he didn't know. Turned out he had selected the SECURE profile in the installer and had securelevel 2. If the kernel had spewed a message at him saying something like "Cannot remove file with current securelevel" or likewise he would have been able to figure it out on his own. When you try to write to a file and normal file permissions deny you this action don't you get a "permission denied"? It's just an error message informing the user something can't be done because of a specific reason. If a user can't load kernel modules that he needs for ppp, wouldn't you rather have him ask "I get this message about securelevel when I try to use ppp and it doesn't work" instead of "ppp doesn't work and I don't know why"? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipcrm/shmctl failure
At 22:06 8-4-2002 -0700, Terry Lambert wrote: >All you are doing is marking the segment as removed. The segment >remains attached by the processes which have it open, and those >references don't go awaya until the processes in question detach >the segments, and the reference count goes to zero. >It turns out that these segments are not proerly reference >counted and tracked, so they are not deleted when the client >"goes away". > >This is a bug in the MIT shared memory extension for X design, >and can't be fixed for long running programs with lots of >bitmaps. I'd like to take a step further and say it's in SYSVSHM design. All a program has to do is forget to do a shm_detach() and you're f#$%ed. Be glad it's just a few bitmaps, and not a 250 meg segment like I had with a certain version of Oracle. >It's an X11 question, and it's been that way since at least 1994, >so it's a long standing X11 FAQ. You could say that X11 shouldn't use SHMs the way it does now yeah. =) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
> I have attached a patch for the 'rm' untility, which strips the trailing >slash(es) from the path (according to Posix.2). But I think there are many >other utilities which need to be patched (e.g. cp, mv). Can you point out how the behavior violates POSIX.2? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is natd the right tool?
Two tips 1) did you set up the divert to natd in your ipfw rules? 2) if you do the dig on the machine where natd is running and the external IP is routed over lo0 locally, ipfw will not see the packets as incoming on the interface where the IP is bound. So that means they will not match the ipfw rules that divert the packets to natd. I suggest trying the dig from a different host. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: updated install files for 4.5-R after security patches?
At 07:15 19-4-2002 -0500, D J Hawkey Jr wrote: >In article <[EMAIL PROTECTED]>, >Sections 9 and 19. In a nutshell, one uses the 'cvsup' tool to freshen >your source code, then one rebuilds and installs the OS and/or kernel. >It's not as daunting a task as it sounds. > >As it turns out, there's a very recent thread in freebsd-security about >this very topic, if you want to know the ups and downs about it. I actually know David and I know he's familiar with cvsupping and rebuilding from source. I guess what his question should be read as "if the ISO images and distributions are not updated after the -SECURE branch has been updated, why isn't this the case?" And I must agree, we know there are bugs in 4.5-RELEASE, yet we don't update the images for 4.5-RELEASE. Yes of course people can use cvsup and upgrade that way. But what about people who are about to install from scratch? Do we REALLY want them to install a faulty version and then upgrade with cvsup? I can't see any good reasons to not update them, or replace 4.5-RELEASE with 4.5-RELEASE-pN at the very least. And also, cvsup is a beautiful thing, but I can't see someone with a 500MB harddrive doing a make buildworld. And yes I sometimes am forced to run FreeBSD on such a small system. >BTW, freebsd-hackers is not the appropriate venue for questions like this. >Neither is freebsd-security, actually. Try freebsd-questions next time. Since he was aware of cvsup I don't think -questions was the right place. He just should have elaborated a little more. Greets, Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: errors after cvsup
First thing to do when a buildworld fails after you cvsup, is to do another cvsup and retry buildworld. On 18 Jul 2002 07:04 EDT you wrote: > After my last cvsup, I went to run make buildworld as I normally do and got the >following error. How do I fix this so that I can continue with the updates? > > > > su-2.04# make buildworld > "/usr/src/share/mk/bsd.subdir.mk", line 32: Could not find bsd.init.mk > make: fatal errors encountered -- cannot continue > *** Error code 1 > > Stop in /usr/src. > > > Emmett Reese > Administrator > www.acool.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
