Re: numbers don't lie ...
Dmitry Morozovsky <[EMAIL PROTECTED]> writes: > Kris Kennaway <[EMAIL PROTECTED]> wrote: > > Dmitry Morozovsky <[EMAIL PROTECTED]> writes: > > > My experiments show that if you have enough memory to host radmdrive for > > > /usr/src you'd better leave it for caching - there were no statistically > > > meaningful performance difference, at least on machines with 1G+ RAM. > > Really? My measurements show the opposite (on a system with 16GB of > > RAM). > My last test on amd64/dualcore with 4G of RAM and -j4 shows > (buildworld+buildkernel): > > ==> /tmp/buildlog <== > 1996.45 real 3032.94 user 624.83 sys > Script done on Tue Sep 19 14:44:54 2006 > > ==> /tmp/buildlog.md <== > 1957.45 real 3033.93 user 585.78 sys > Script done on Tue Sep 19 15:20:42 2006 > > Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on > the > gmirror'ed pair of SATAs. Seems to me that your own numbers contradict you. You saved about 40 seconds (2%) by keeping /usr/src in a ram disk. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
network stack problem in sparc64?
Hello, I saw this some time ago but always forgot to report it. I'm running a pair of machines with FreeBSD/sparc64 (various versions, one of them is running -STABLE now), and I've seen a problem with the network stack. Looking at buffer and window sizes, earendil# sysctl net.inet.tcp|fgrep space net.inet.tcp.sendspace: 0 net.inet.tcp.recvspace: 0 earendil# sysctl net.inet.udp net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 0 net.inet.udp.recvspace: 0 When I try to modify them, it doesn't work at all. For example, trying to run nfcapd/nfsen in a sparc64 box, I get an error for a setsockopt() call earendil# /usr/local/etc/rc.d/nfsen start Starting nfsenStarting nfcpad: upstream1setsockopt(SO_RCVBUF,20): Invalid argument Terminated due to errors. nfcapd exec error: exit: 255, signal: 0, coredump: 0 For x86 machines the values are correctly reported and they work as expected. I have been poking Google for this but I haven't seen any mention of this. Best regards, Borja. P.S: The example machine is running earendil# uname -a FreeBSD earendil.arnor.es 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Fri Sep 22 12:04:44 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/ src/sys/EARENDIL sparc64 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: network stack problem in sparc64?
Borja Marcos wrote: Hello, I saw this some time ago but always forgot to report it. I'm running a pair of machines with FreeBSD/sparc64 (various versions, one of them is running -STABLE now), and I've seen a problem with the network stack. Looking at buffer and window sizes, earendil# sysctl net.inet.tcp|fgrep space net.inet.tcp.sendspace: 0 net.inet.tcp.recvspace: 0 earendil# sysctl net.inet.udp net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 0 net.inet.udp.recvspace: 0 When I try to modify them, it doesn't work at all. For example, trying to run nfcapd/nfsen in a sparc64 box, I get an error for a setsockopt() call earendil# /usr/local/etc/rc.d/nfsen start Starting nfsenStarting nfcpad: upstream1setsockopt(SO_RCVBUF,20): Invalid argument Terminated due to errors. nfcapd exec error: exit: 255, signal: 0, coredump: 0 For x86 machines the values are correctly reported and they work as expected. I have been poking Google for this but I haven't seen any mention of this. hmmm... how about this (untested) patch? --- tcp_usrreq.c.orig Fri Nov 4 12:26:14 2005 +++ tcp_usrreq.cMon Sep 25 09:31:42 2006 @@ -1161,10 +1161,10 @@ * sizes, respectively. These are obsolescent (this information should * be set by the route). */ -u_long tcp_sendspace = 1024*32; +inttcp_sendspace = 1024*32; SYSCTL_INT(_net_inet_tcp, TCPCTL_SENDSPACE, sendspace, CTLFLAG_RW, &tcp_sendspace , 0, "Maximum outgoing TCP datagram size"); -u_long tcp_recvspace = 1024*64; +inttcp_recvspace = 1024*64; SYSCTL_INT(_net_inet_tcp, TCPCTL_RECVSPACE, recvspace, CTLFLAG_RW, &tcp_recvspace , 0, "Maximum incoming TCP datagram size"); --- udp_usrreq.c.orig Wed Sep 13 11:19:26 2006 +++ udp_usrreq.cMon Sep 25 09:32:00 2006 @@ -923,12 +923,12 @@ return (error); } -u_long udp_sendspace = 9216; /* really max datagram size */ +intudp_sendspace = 9216; /* really max datagram size */ /* 40 1K datagrams */ SYSCTL_INT(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW, &udp_sendspace, 0, "Maximum outgoing UDP datagram size"); -u_long udp_recvspace = 40 * (1024 + +intudp_recvspace = 40 * (1024 + #ifdef INET6 sizeof(struct sockaddr_in6) #else thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fsck
I've got a /usr partition with some problems. During boot it fails and I'm prompted to run fsck manually. I do so and when fsck has finished it asks me to run it again, and again, and again...it seems to find the same errors each time. It never seems to repair anything. It worked fine on errors it found on the /var partition... I checked the man pages and didn't see anything pertinent. How can I fix this partition? And now for something completely different If I can't get the /usr partition to work is there any way to recreate the user directories from the password file? The contents will be lost but nobody uses their folder anyway, I just need all the /usr/home folders created... I could write a script, but I thought I'd check first to see if something already exists... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck
On Mon, 2006-Sep-25 12:38:47 -0600, [EMAIL PROTECTED] wrote: >I've got a /usr partition with some problems. During boot it fails and I'm >prompted to run fsck manually. I do so and when fsck has finished it asks >me to run it again, and again, and again...it seems to find the same errors >each time. Can you give some more details please. What version of FreeBSD is this? What are the errors? What options are you giving fsck? What happened between the last time /usr fsck'd correctly and now? I don't have a script to re-create directories but it would be fairly easy to write one. -- Peter Jeremy pgpzWBVLHKZT7.pgp Description: PGP signature
Re: fsck
I've got a /usr partition with some problems. During boot it fails and I'm prompted to run fsck manually. I do so and when fsck has finished it asks me to run it again, and again, and again...it seems to find the same errors each time. It never seems to repair anything. It worked fine on errors it found on the /var partition... I checked the man pages and didn't see anything pertinent. How can I fix this partition? Have your tried to run fsck in single-user mode -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) http://www.maslanlab.org http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
Oliver Fromme wrote: > Eric Anderson wrote: > > Oliver Fromme wrote: > > > Reading /usr/src from a physical disk certainly requires > > > quite some I/O that takes more than zero time. > > > > But, in order to populate the ram disk, you must read /usr/src also from > > something, and that also takes time, which you should include in the > > full scope. > > But when you perform the buildworld several times (as you > should do when you're benchmarking properly), everything > is already in the RAM disk. If you instead rely on caching > but you don't have enough RAM to hold all of src + obj + > toolchain in RAM, then src (or at least parts of it) will > have to be read from the physical disk again upon each > buildworld. .. which makes no difference for the test case presented here. You're missing the point here: they benchmark with '-j8'. If you'd benchmark a -j1 build of md(4) vs. real disks, then you should get drastically different results (provided you start with a cold cache). But on these dual (quad?) CPU machines, with a -j8 build, 6 threads/processes are free to wait for disk I/O a very long time till they are finally scheduled. Thus, specifying high -jN values will mask any disk I/O latency (for reasonable combinations of CPUs and HDDs). Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck
Hi Peter, The hard drive is in the fridge right now, in case it's a heat problem. It's FreeBSD version 4.x. It's getting hard read errors, and I'm using -y with fsck so it will continue on to the next error without prompting from me. The same thing happens whether I use the -y flag or not. It says that certain sectors are bad, moves on to the next bad sectors, and eventually says I need to rerun fsck. It's like "Groundhog Day", I get the same thing over and over and over... Nothing happened since the last boot, I was gzipping up the home folders to transfer to a new server (just in time I guess...) and it started getting really slowly. So I rebooted it from the command line and when it came back up it had problems. It has been restarted a few times in the past week and showed no errors at all before yesterday. It found the same type of errors on the /var partition and dealt with those without problems. So I'm wondering what the difference might be... The /var partition found errors, fixed them, and marked the partition as clean. Maybe I can mount a dirty partition. I just need the data off it... At 01:07 PM 9/25/2006, you wrote: On Mon, 2006-Sep-25 12:38:47 -0600, [EMAIL PROTECTED] wrote: >I've got a /usr partition with some problems. During boot it fails and I'm >prompted to run fsck manually. I do so and when fsck has finished it asks >me to run it again, and again, and again...it seems to find the same errors >each time. Can you give some more details please. What version of FreeBSD is this? What are the errors? What options are you giving fsck? What happened between the last time /usr fsck'd correctly and now? I don't have a script to re-create directories but it would be fairly easy to write one. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck
On Mon, Sep 25, 2006 at 02:41:18PM -0600, [EMAIL PROTECTED] wrote: > > Maybe I can mount a dirty partition. I just need the data off it... Mount it read-only and get the data off it IMMEDIATELY. I wouldn't try fsck-ing on any disk with even a single read or write error. Fsck will fail if it can't find a real sector to allocate, and I don't think it deals well with bad sectors anyway. Point is: don't let it. "dd" the drive ASAP and cut your losses... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck
Thanks At 02:53 PM 9/25/2006, you wrote: On Mon, Sep 25, 2006 at 02:41:18PM -0600, [EMAIL PROTECTED] wrote: > > Maybe I can mount a dirty partition. I just need the data off it... Mount it read-only and get the data off it IMMEDIATELY. I wouldn't try fsck-ing on any disk with even a single read or write error. Fsck will fail if it can't find a real sector to allocate, and I don't think it deals well with bad sectors anyway. Point is: don't let it. "dd" the drive ASAP and cut your losses... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
distinguishing inode block-list from symlink text
Can someone point me to a fairly detailed description of how softdep handles "rm", in particular how it determines whether a particular inode (e.g. a symlink) contains text instead of a list of block numbers? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck
> > Maybe I can mount a dirty partition. I just need the data off it... > Mount it read-only and get the data off it IMMEDIATELY. I wouldn't try > fsck-ing on any disk with even a single read or write error. Fsck will > fail if it can't find a real sector to allocate, and I don't think it deals > well with bad sectors anyway. Point is: don't let it. "dd" the drive > ASAP and cut your losses... also, just beware that the OS may panic when reading a corrupt FS (this happened to me at least once). umount all other slices. in case it panicks, use verbose cp (`cp -v`) to see which files are being copied, note those which cause panic, and skip them i would also suggest to dd the drive's contents, and then and then fool around with it for some time (in order of a week) to get the most data off of it. First, determine the cause of the failure (use smartmontools); if it's electronics, you'll see smth like: SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error [...] # 4 Short offline Completed: electrical failure 90% 13469 127 There's a good chance that the thing might heal itself somewhat (black magic!). One of the ATA drives I'm using now had this failure, and it persisted for a few days while I was subjecting the HDD to various stresses (heat/cold, vibration, intense workout, manufacturer's test program, etc). Then suddenly, after about a week, it started working, and still works! (of course, all the data was long rewritten million times :/) If the cause is a media defect, I don't believe there's any chance of recovering anymore data. If it failed because of a 'mild' head-crash, you'd want to be very careful with the drive, and make a copy ASAP; don't move it around too much. [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: numbers don't lie ...
On Mon, 25 Sep 2006, Dag-Erling Sm?rgrav wrote: DS> > > > My experiments show that if you have enough memory to host radmdrive for DS> > > > /usr/src you'd better leave it for caching - there were no statistically DS> > > > meaningful performance difference, at least on machines with 1G+ RAM. DS> > > Really? My measurements show the opposite (on a system with 16GB of DS> > > RAM). DS> > My last test on amd64/dualcore with 4G of RAM and -j4 shows DS> > (buildworld+buildkernel): DS> > DS> > ==> /tmp/buildlog <== DS> > 1996.45 real 3032.94 user 624.83 sys DS> > Script done on Tue Sep 19 14:44:54 2006 DS> > DS> > ==> /tmp/buildlog.md <== DS> > 1957.45 real 3033.93 user 585.78 sys DS> > Script done on Tue Sep 19 15:20:42 2006 DS> > DS> > Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the DS> > gmirror'ed pair of SATAs. DS> DS> Seems to me that your own numbers contradict you. You saved about 40 DS> seconds (2%) by keeping /usr/src in a ram disk. Well, maybe I did used wrong wording (2% is statistically meaningful), but for me 2% is not worth all the efforts needed to organize ram disk infrastructure... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
