Re: Quota reporting is inaccurate.
On Fri, Apr 13, 2001 at 03:48:28PM -0600, Matt Simerson wrote: Another thought is that this user may have had files still open. Even if you "remove" a file, it really does not go away until the last open handle is closed. That seems like the most likely possibility. However, only one daemon can add or delete files and that's FreeBSD's built in FTP daemon. If the deamon isn't running (and it wasn't) then the file shouldn't be open (in theory). I just installed lsof and we'll see if that doesn't reveal anything next time I see this crop up. If the streaming is done by something other than the FTP daemon, then the file *can* still be open, if someone was listening to it at the time the user deleted it via FTP. G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recent RPC changes to -current
Hi, Can you check if this solves the drac problem in CURRENT ? Does drac work the way it should ? There were some flags actived in rpcgen, which shouldn't have been. I also modified your port a bit to use tirpc code and to not include netdir.h http://home.teleport.ch/freebsd/rpcgen.diff http://home.teleport.ch/freebsd/drac.diff Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recent RPC changes to -current
Hi Anders, As I have seen, drac can only handle IPv4 requests at the moment. If you do like to see IPv6 support, I can make a patch for you. We can now support Ipv6 with rpc ports, since tirpc supports ipv6 also. 9001011udp6 :::0.0.0.0.3.225 - superuser 9001011tcp6 :::0.0.0.0.2.197 - superuser 9001011udp 0.0.0.0.3.224 - superuser 9001011tcp 0.0.0.0.2.196 - superuser Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Thu, Apr 12, 2001 at 02:24:36PM -0700, a little birdie told me that Matt Dillon remarked Without vmiodirenable turned on, any directory exceeding vfs.maxmallocbufspace becomes extremely expensive to work with O(N * diskIO). With vmiodirenable turned on huge directories are O(N), but have 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. Speaking of vmiodirenable, what are the issues with it that it's not enabled by default? ISTR that it's been in a while, and most people pointed at it have reported success with it, and it seems to have solved problems here and there for a number of people. What's keeping it from the general case? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Sat, Apr 14, 2001 at 09:34:26AM -0500, Matthew D. Fuller wrote: On Thu, Apr 12, 2001 at 02:24:36PM -0700, a little birdie told me that Matt Dillon remarked Without vmiodirenable turned on, any directory exceeding vfs.maxmallocbufspace becomes extremely expensive to work with O(N * diskIO). With vmiodirenable turned on huge directories are O(N), but have 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. Speaking of vmiodirenable, what are the issues with it that it's not enabled by default? ISTR that it's been in a while, and most people pointed at it have reported success with it, and it seems to have solved problems here and there for a number of people. What's keeping it from the general case? Attached is a message from Matt Dillon from an earlier -hackers discussion. G'luck, Peter -- The rest of this sentence is written in Thailand, on From [EMAIL PROTECTED] Fri Mar 23 02:15:39 2001 Date: Thu, 22 Mar 2001 16:14:11 -0800 (PST) From: Matt Dillon [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: "Michael C . Wu" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: tuning a VERY heavily (30.0) loaded s cerver :(Why is vfs.vmiodirenable=1 not enabled by default?) : The only reason it isn't enabled by default is some unresolved filesystem corruption that occurs very rarely (with or without it) that Kirk and I are still trying to nail down. I want to get that figured out first. It is true that some people have brought up memory use issues, but I don't consider memory use to really be that much of an issue. This is a cache, after all, so the blocks can be reused at just about any time. And directory blocks do not get cached well at all with vmiodirenable 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:Speaking of vmiodirenable, what are the issues with it that it's not :enabled by default? ISTR that it's been in a while, and most people :pointed at it have reported success with it, and it seems to have solved :problems here and there for a number of people. What's keeping it from :the general case? : :-- :Matthew Fuller (MF4839) |[EMAIL PROTECTED] I'll probably turn it on after the 4.3 release. Insofar as Kirk and I can tell there are no (hah!) filesystem corruption bugs left in the filesystem or VM code. I am guessing that what corruption still occurs occassionally is either due to something elsewhere in the kernel, or motherboard issues (e.g. like the VIA chipset IDE DMA corruption bug). I have just four words to say about IDE DMA: It's a f**ked standard. Neither Kirk nor I have been able to reproduce reported problems at all, but with help from others we have fixed a number of bugs which seem to have had a positive effect on Yahoo's test machines. At the moment one of Yahoo's 8 IDE test systems may crash once after a few hours, but then after reboot will never crash again. This hopefully means that fsck is fixing corruption generated from earlier buggy kernels that is caught later on. I've been exchanging email with three other people with corruption issues. One turned out to be hardware (fsck after newfs was failing, so obviously not a filesystem issue!), another is indeterminant, the third was working fine until late February and then new kernels started to result in corruption (while old kernels still worked) and he is now trying to narrow down the date range where the problem was introduced. Either way it 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
Fwd: file cache (on nfs)
Sorry, posted it to -questions and -stable and no answer yet. Maybe someone of you can help me Hi there, can someone tell me how/if file caching is done on freebsd over nfs? are the parameters to modify the behaviour (e.g. memory usage)? are there parameters for "normal" local disk cache also? thanks regards Sven Huster Senior IT Systems Administrator *BSD, Linux, Solaris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
stupid pet tricks (using ifconfig)
Wierdness in 4.2. Scenario: interface fxp0 has address 100.1.1.1. Use it with this address for awhile. decide to change it to 100.1.1.5. do: ifconfig fxp0 delete 100.1.1.1 ifconfig fxp0 100.1.1.5 netmask 255.255.255.0 viewing ifconfig shows the new address. HOWEVER, pinging 100.1.1.99, the freebsd machine sends out 100.1.1.1, the OLD address. Is this cached/saved somewhere and not getting cleaned up? Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stupid pet tricks (using ifconfig)
viewing ifconfig shows the new address. HOWEVER, pinging 100.1.1.99, the freebsd machine sends out 100.1.1.1, the OLD address. Is this cached/saved somewhere and not getting cleaned up? in the routing table, apparently. If you do a "route -n get" for the destination address you see the old one. Manually flushing the relevant entries in the routing table does the job (yes it is a bug, it should happen automatically, and it is not 4.2 specific, it has been there forever) cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting article.
Bakul Shah wrote: From the top level page I read hotmail handles 550,000 change requests a day. Later in the article they say they have a 5000 server farm. That translates to 110 change requests a day on average per server. If the peak rate is 10 times the average, that is still only about 1100 requests/server/day or about 78 seconds on average. This rate seems quite low even when you account for multiple web page servings per change request Am I missing something obvious? You neglected to deduct the number of servers that are down/rebooting from the 5k. :) http://www.microsoft.com/backstage/column_T2_1.htm You just can't make this stuff up Doug -- Perhaps the greatest damage the American system of education has done to its children is to teach them that their opinions are relevant simply because they are their opinions. Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
