UFS Disk partitions
Does anyone have any information regarding recovering diskpartitions as the machine crash in heavy I/O to that disk i've lost being able to fsck the drive and of course be able to mount it which means I'm quite lost in the way of how to recover the data. Any help apprieciated Bri, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UFS Disk partitions
On 12:54+0300, Nov 11, 2002, Bri wrote: Does anyone have any information regarding recovering diskpartitions as the machine crash in heavy I/O to that disk i've lost being able to fsck the drive and of course be able to mount it which means I'm quite lost in the way of how to recover the data. Any help apprieciated Take a look at src/tools/tools/find-sb/ and OpenBSD's scan_ffs: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/scan_ffs/?cvsroot=openbsd -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim;macomnet.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[hackers] Re: Netgraph could be a router also.
Terry == Terry Lambert [EMAIL PROTECTED] writes: Terry By it, I guess you mean FreeBSD? Terry What are your performance goals? Right now, I'd like to see 500 to 600 kpps. Terry Where is FreeBSD relative to those goals, right now, without Terry you doing anything to it? Without any work, we got 75 kpps. Terry Where is FreeBSD relative to those goals, right now, if you Terry tune it very carefully, but don't hack any code? With a few patches, including polling and some tuning, we got 150 to 200 kpps. Note that we've been focusing on pps, not Mbs. With 100M cards (what we're currently using) we want to focus on getting the routing speed up. One of the largest problems we've found with GigE adapters on FreeBSD is that their pps ability (never mind the volume of data) is less than half that of the fxp driver. But we havn't tested every driver. The Intel GigE cards were especially disapointing. Terry What data rate do you need to support? How much are you Terry willing to modify FreeBSD? How much are you willing to modify Terry your hardware design? 64 Bit PCI-X has a burst rate of about Terry 8Gbit, which means that it's average operation is going to be Terry about 1/3 that, and then you have to add memory latency on top Terry of that, if you DMA data from the network card into main Terry memory, instead of just between network cards. Terry If you are willing to significantly modify FreeBSD, and address Terry all of the latency issues, a multiport Gigabit router is Terry doable, but you haven't even mentioned the most important Terry aspect of any high speed networking system, so it's not likely Terry that you're going to be able to do this effectively, just Terry approaching it blind. We've been looking at the click stuff... and it seems interesting. I like some aspects of the netgraph interface better and may be paying for an ng_route to be created shortly. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Socket so_linger setting
Matthew Dillon wrote: I think your patch is fine as is, Mike! Good find! Even though so_linger cannot be negative, it is often convenient to use a signed integer to store the value to avoid unexpected arithmatic results when mixing with signed operations. My quick perusal does not show any cases of this for so_linger, so we could make it unsigned, but I don't see any pressing need to do so. The range check would need to be in there in either case. Can I go ahead and commit it? What is the status with this? As far as I can tell, the fix is correct and needed for some Java/JCK issues (the issue can be worked around in the JVM but that is the incorrect place to deal with it) -Matt Matthew Dillon [EMAIL PROTECTED] :During some parameter limit checking work, I ran into what I believe to :be an error in FreeBSD. (Albeit unlikely to be hit) : :A setsockopt of the SO_LINGER field will cause strange results if :the value is set above 32767. : :This is due to the fact that in struct socket, the so_linger field :is a signed short and the parameter passed to setsockopt for linger :is a signed long. : :What happens is that any value between 32768 and 65535 will cause :so_linger to be negative. And then getsockopt will return a sign :extended negative value in the signed long field for linger. : :The trivial fix is to do the following: : :-- :--- uipc_socket.c Wed May 1 01:13:02 2002 :+++ /tmp/uipc_socket.c Fri Nov 1 06:55:10 2002 :@@ -1139,7 +1139,8 @@ : if (error) : goto bad; : :- so-so_linger = l.l_linger; :+ /* Limit the value to what fits in so_linger */ :+ so-so_linger = (l.l_linger SHRT_MAX ? SHRT_MAX : l.linger); : if (l.l_onoff) : so-so_options |= SO_LINGER; : else :-- : :What this does is limit the value to no more than 32767 (SHRT_MAX) :However, I believe the more correct answer is that so_linger should :not be a signed value to begin with. : :The reasoning is that what does a negative so_linger mean? To :close the socket before the user does ;^)? : :It is somewhat obvious that so_linger does not need to be a long. : :It is not possible to change the API to make the input a short. : :Limiting the value to 32767 is reasonable (and that is a *vary* :long linger time) : :However, given that negative linger values really don't exist :(logically) it would be reasonable to not that field be signed. :That would naturally limit the values to being within a valid :range and prevent some strange results, specifically when :looking at the tsleep() call where the so_linger field is :just blindly multiplied by the hz of the system. (around line :312 of uipc_socket.c) A segative so_linger will get sign extended :into a negative int (32-bit) (times hz) and then passed to tsleep :which just checks for zero, passed on to timeout which then :passes it to callout_reset. It turns out that callout_reset will :take negative values and make them a single tick... (whew! lucky :thing that was there :-) : :The question I have is: should put together a patch that changes :so_linger (and xso_linger) to unsigned? (And make sure there are :no bad side effects) or is the trivial fix above what is wanted? : :[ My personal feeling is that since so_linger has no valid negative : value that the field should be unsigned. Not that it matters : about improving the range as 32767 is over 9 hours. It is more : a matter of correctness in the code/representation since the : code assumes the value is not negative already. ] : :-- :Michael Sinz -- Director, Systems Engineering -- Worldgate Communications :A master's secrets are only as good as : the master's ability to explain them to others. 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
sio howto
Hi I just followed the recent sio thread, but it did not answer my questions. I have a program that needs to set RTS and DTR and then later set them again and again.. I could go for the open /dev/io and then the IO adr of the serial port.. but as far as i've seen it would lock up the kernel, but is there a good way to this? Best regards Soren Straarup. [EMAIL PROTECTED] (__)(__) (,''/// Why use M$ when you can get FreeBSD for the download.. \\\'',) ^ / \/ \/ \ ^ (_\_./\._/_) \ / X ASCII ribbon campaign-- / \ against HTML mail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Question!
Hi there. I just want to know if you can help me to know the password from a yahoo account. If you cant help me, dont worry, its ok. Adrian. _ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Socket so_linger setting
I was going to wait till 5.0 released first but I could do it now if you want. -Matt : :Matthew Dillon wrote: : I think your patch is fine as is, Mike! Good find! Even though : so_linger cannot be negative, it is often convenient to use a signed : integer to store the value to avoid unexpected arithmatic results : when mixing with signed operations. My quick perusal does not show : any cases of this for so_linger, so we could make it unsigned, but I : don't see any pressing need to do so. The range check would need : to be in there in either case. : : Can I go ahead and commit it? : :What is the status with this? As far as I can tell, the fix is correct :and needed for some Java/JCK issues (the issue can be worked around in :the JVM but that is the incorrect place to deal with it) : : -Matt : Matthew Dillon : [EMAIL PROTECTED] : : :During some parameter limit checking work, I ran into what I believe to : :be an error in FreeBSD. (Albeit unlikely to be hit) : : : :A setsockopt of the SO_LINGER field will cause strange results if : :the value is set above 32767. : : : :This is due to the fact that in struct socket, the so_linger field : :is a signed short and the parameter passed to setsockopt for linger : :is a signed long. : : : :What happens is that any value between 32768 and 65535 will cause : :so_linger to be negative. And then getsockopt will return a sign : :extended negative value in the signed long field for linger. : : : :The trivial fix is to do the following: : : : :-- : :--- uipc_socket.c Wed May 1 01:13:02 2002 : :+++ /tmp/uipc_socket.c Fri Nov 1 06:55:10 2002 : :@@ -1139,7 +1139,8 @@ : : if (error) : : goto bad; : : : :- so-so_linger = l.l_linger; : :+ /* Limit the value to what fits in so_linger */ : :+ so-so_linger = (l.l_linger SHRT_MAX ? SHRT_MAX : :l.linger); : : if (l.l_onoff) : : so-so_options |= SO_LINGER; : : else : :-- : : : :What this does is limit the value to no more than 32767 (SHRT_MAX) : :However, I believe the more correct answer is that so_linger should : :not be a signed value to begin with. : : : :The reasoning is that what does a negative so_linger mean? To : :close the socket before the user does ;^)? : : : :It is somewhat obvious that so_linger does not need to be a long. : : : :It is not possible to change the API to make the input a short. : : : :Limiting the value to 32767 is reasonable (and that is a *vary* : :long linger time) : : : :However, given that negative linger values really don't exist : :(logically) it would be reasonable to not that field be signed. : :That would naturally limit the values to being within a valid : :range and prevent some strange results, specifically when : :looking at the tsleep() call where the so_linger field is : :just blindly multiplied by the hz of the system. (around line : :312 of uipc_socket.c) A segative so_linger will get sign extended : :into a negative int (32-bit) (times hz) and then passed to tsleep : :which just checks for zero, passed on to timeout which then : :passes it to callout_reset. It turns out that callout_reset will : :take negative values and make them a single tick... (whew! lucky : :thing that was there :-) : : : :The question I have is: should put together a patch that changes : :so_linger (and xso_linger) to unsigned? (And make sure there are : :no bad side effects) or is the trivial fix above what is wanted? : : : :[ My personal feeling is that since so_linger has no valid negative : : value that the field should be unsigned. Not that it matters : : about improving the range as 32767 is over 9 hours. It is more : : a matter of correctness in the code/representation since the : : code assumes the value is not negative already. ] : : : :-- : :Michael Sinz -- Director, Systems Engineering -- Worldgate Communications : :A master's secrets are only as good as : :the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question!
eeh.. This is the freebsd-hackers list.. Best regards Soren Straarup. [EMAIL PROTECTED] (__)(__) (,''/// Why use M$ when you can get FreeBSD for the download.. \\\'',) ^ / \/ \/ \ ^ (_\_./\._/_) \ / X ASCII ribbon campaign-- / \ against HTML mail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question!
hey this is the freebsd-hackers list Best regards Soren Straarup. [EMAIL PROTECTED] (__)(__) (,''/// Why use M$ when you can get FreeBSD for the download.. \\\'',) ^ / \/ \/ \ ^ (_\_./\._/_) \ / X ASCII ribbon campaign-- / \ against HTML mail On Mon, 11 Nov 2002, [iso-8859-1] adrian reyes wrote: Hi there. I just want to know if you can help me to know the password from a yahoo account. If you cant help me, dont worry, its ok. Adrian. _ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx 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: [hackers] Re: Netgraph could be a router also.
On Mon, 11 Nov 2002, David Gilbert wrote: Terry == Terry Lambert [EMAIL PROTECTED] writes: Terry By it, I guess you mean FreeBSD? Terry What are your performance goals? Right now, I'd like to see 500 to 600 kpps. Terry Where is FreeBSD relative to those goals, right now, without Terry you doing anything to it? Without any work, we got 75 kpps. Terry Where is FreeBSD relative to those goals, right now, if you Terry tune it very carefully, but don't hack any code? With a few patches, including polling and some tuning, we got 150 to 200 kpps. Note that we've been focusing on pps, not Mbs. With 100M cards (what we're currently using) we want to focus on getting the routing speed up. One of the largest problems we've found with GigE adapters on FreeBSD is that their pps ability (never mind the volume of data) is less than half that of the fxp driver. This is intriguing. I have found with Samba that I am able to achieve approx 100MB/s read from cache with 1500B frame sizes (ie, no jumbo frames) over a BCM5701 on an 850 MHz PIII with FreeBSD 4.3 and similar rates from em0 on a 2GHz P4 with 4.6. Both results were with 1500B frames and considerable free CPU (50% on the 850MHz PIII). However, given that they were full 1500B frames (99%), at least in one direction, perhaps that does not count. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], http://www.richardsharpe.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Socket so_linger setting
Matthew Dillon wrote: I was going to wait till 5.0 released first but I could do it now if you want. It would help the Java work but I don't know if it is critical to be done today vs some short time in the future. (Depends on the timing of the Java project and the wish to get JCK cert) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Cigarettes from £9.59 for 200
Duty free, delivered direct to your door. We've been supplying airports and Duty Free shops since 1997 and NOW we're doing it online! Forget the hassle of travelling to get your duty free, you can have it dedlivered direct to your home at unbeatable prices. Coronas International £9.59 Lambert Butler £17.28 Superkings £18.84 Silk Cut £21.64 Embassy £18.84 Why are we the best? - You can try us out by ordering just ONE carton. - We have a guaranteed replacement or instant money back policy in the event of non-delivery. - Delivery takes just 7 days (allow an extra seven days for processing). - Our best advert is a satisfied customer. And we supply hand rolling, pipe tobacco and cigars, too! Welcome to hassle free, Duty Free! Send us an email if you are interested in learning more about where you can shop online. [EMAIL PROTECTED] If you don't want to receive any more mails from us, just reply with REMOVE in the subject title. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sio howto
On Mon, 11 Nov 2002, the evil toor wrote: I just followed the recent sio thread, but it did not answer my questions. I have a program that needs to set RTS and DTR and then later set them again and again.. I could go for the open /dev/io and then the IO adr of the serial port.. but as far as i've seen it would lock up the kernel, but is there a good way to this? Don't access the port directly, use /usr/include/sys/ttycom.h, see TIOCSDTR -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hackers] Re: Netgraph could be a router also.
Richard == Richard Sharpe [EMAIL PROTECTED] writes: Richard However, given that they were full 1500B frames (99%), at Richard least in one direction, perhaps that does not count. That's exactly the point. With large frames, you can get high rates of traffic. With smaller frames, rates drop quickly. We're using FreeBSD (with Zebra) as core routers for about 80Mbit of traffic to 3 main providers and about 25 local peers. We're facing the point where we have to decide to invest a little in the platform or ditch it for some name-brand gear. Much of the recent hacking on FreeBSD has been done in house and we recently hired another coder with kernel expertise to hack on the code. Of particular embarrasment is that FreeBSD produces source quench packets when acting as a router. Aparently an RFC made this a bad thing(tm) some time ago. Anyways... the average packet size at the core router is much smaller than 1500 with much of the traffic being in the tiny 100 byte category. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
forwarded message on Source Quench Packets.
I normally wouldn't forward something to such a big list, but this has real implications (and was part of a nast DOS against dsl.ca last week). The patch for FreeBSD (netbsd code is quoted) is trivial: --- /sys/netinet/ip_input.c Thu Oct 17 08:29:53 2002 +++ ip_input.c Mon Nov 11 15:15:31 2002 @@ -1822,9 +1822,7 @@ break; case ENOBUFS: - type = ICMP_SOURCEQUENCH; - code = 0; - break; + return; case EACCES:/* ipfw denied packet */ m_freem(mcopy); I'm submitting a PR now. For discussion: source quenches probably shouldn't be generated anyways, but this patch also doesn't generate the source quench if we're the target machine. It's probably good to go straight ahead with this. IIRC, tcp_input.c also can generate a source quench ... ---BeginMessage--- On Mon, Nov 11, 2002 at 02:11:42PM -0400, richard's all... Maybe a bit late... But. --snip- #if 1 /* * a router should not generate ICMP_SOURCEQUENCH as * required in RFC1812 Requirements for IP Version 4 Routers. * source quench could be a big problem under DoS attacks, * or if the underlying interface is rate-limited. */ 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. As specified in Section [4.3.2], a router that does originate Source Quench messages MUST be able to limit the rate at which they are generated. DISCUSSION Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. A router MAY ignore any ICMP Source Quench messages it receives. DISCUSSION A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([INTERNET:11], [INTERNET:12]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended. INTERNET:9. A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder, and R. Zahavi, Evaluation of Internet Performance - FY89, Technical Report MTR-89W00216, MITRE Corporation, February, 1990. INTERNET:10. G. Finn, A Connectionless Congestion Control Algorithm, Computer Communications Review, volume 19, number 5, Association for Computing Machinery, October 1989. /kc if (mcopy) m_freem(mcopy); return; #else type = ICMP_SOURCEQUENCH; code = 0; break; #endif - - - - - - - - - - - - - Jonathan Richards Tel:+1-416-876-5219 Fax:+1-708-575-1680 Email:[EMAIL PROTECTED] -- Ken Chase, [EMAIL PROTECTED] * Velocet Communications Inc. * Toronto, CANADA ---End Message--- Dave.
Re: vmstat to detect memory leaks?
On Sun, 10 Nov 2002, Chuck Tuffli wrote: I'm developing a loadable module and was wondering if I can use the output of vmstat to figure out if there is memory leak over the course of some testing. For example, vmstat -m is probably what you want. That lists the kernel memory allocations. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sio howto
the evil toor wrote: I just followed the recent sio thread, but it did not answer my questions. I have a program that needs to set RTS and DTR and then later set them again and again.. I could go for the open /dev/io and then the IO adr of the serial port.. but as far as i've seen it would lock up the kernel, but is there a good way to this? DTR is set when you open the port. It is reset on last close. RTS is set when the low receive buffer is empty/below the low watermark, and reset when it is full/above the high watermark; RTS follows DTR on open/close (i.e. it is not asserted unless th port is open). To directly control RTS, you must disable CTS/RTS flow control, which is on by defaults (see the XXX comment at ~ line 2286 in /sys/isa/sio.c). Assuming you have done this, you may control it using TIOCMSET, a Terminal I/O Control, using ioctl(). Assuming the port is open, you can control DTR via TIOCSDTR; this assumes you can live with DTR coming high between the time you open the port, and the time you disable it. The same is true of RTS, which follow DTR at initial open, as the default state of the device. There are no protections against RTS state changes when input hardware flow control is enabled: that is, if you have input flow control enabled, and are above the low watermark, and you disable RTS, when the pending data causes the buffer to drop below the low watermark, RTS will be reasserted automatically (this is analogous to trying to use the loop control variable for temporary storage in a for.. loop). See the serial driver source code for details. If you want to be useful, you can force an interlock on the CTS/RTS behaviour, and hardware flow control state, and add device flags which may be specified on the device in the kernel to control the initial state of these attributes on the device, if it is not open or initialized (e.g. so that they don't go high the moment you open the device, by default). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Shrinking /(s)bin: A Proposal
The possibility of dynamically linking /(s)bin seems to recur pretty regularly. As libc continues to grow, this idea seems worth revisiting. However, I've come up with an alternative that might be worth considering. For concreteness, consider /bin/mv, whose 400k (!!) breaks down approximately as follows: 20k - core functionality 60k - stdio 320k - user_from_uid/group_from_gid (used _only_ for the Override perm user/group prompt!) The last item here includes yp* overhead, which of course pulls in the resolver. Uck. I'd guess that /bin and /sbin have at least 4MB of yp/resolver duplication that could be trimmed (out of almost 30MB total), probably more. I see several ways to address this: 1) make /bin/mv dynamic. Personally, I have misgivings, but I understand NetBSD has done this. 2) Implement the resolver in the kernel. 3) Implement a daemon. Same idea as (2), but in user space. Unlike (1), this can be made pretty robust (e.g., 'mv' could print Override r-xr-xr-x for 1002/1002? if the daemon was unavailable). Response caching could actually make this faster than (1). 4) Implement a command-line helper. A user_from_uid binary could be run by /bin/mv as needed. This could povide most of the benefits of a daemon with the added advantage of on-demand loading; no memory is required unless the service is actually needed. 5) Dump the corresponding functionality. In the case of /bin/mv, this is worth considering (the warning message becomes more cryptic, but no real functionality is lost). It doesn't help much with /bin/ls, though. I've started experimenting with the helper binary approach (#4 above), and it seems pretty workable. Of course, a single helper should handle user, group, and DNS lookups and do so in a way that does not require re-running it for every lookup. I can manage all of that without too much trouble. This approach is robust (the client program can easily handle service failure), reduces disk requirements significantly, and potentially reduces memory requirements as well. It should ultimately be possible to combine #3 and #4 in one executable, so that crippled systems could run the from-disk binary to get access to the service, while fully-functional systems would use the already-running daemon. I suspect I can trim /bin/mv down to 40k or so using this approach, with similar savings for many other utilities. As I mentioned above, the total disk-space savings could be considerable. This might also open the door to nsswitch support for statically-linked binaries, though I'm no expert on nsswitch. Thoughts? As I said, I've started experimenting with this approach, but my current efforts are hardly commit-quality. If this is worth pursuing, I'm willing to do a lot of the work to make it happen. (Specifically, I'm willing to implement the helper binary and the glue logic and make the necessary modifications to a half-dozen common utilities.) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
