Re: X11/C++ question
hi,
Does anyone (anyone, that is, who's coded X11 applications) know how you
handle X11 callbacks to C++ object methods?
Thanks,
TDR If you mean Xt (and possibly Motif) - the answer is "very carefully."
TDR The Xt callbacks are C based, so you typically can't directly call a
TDR C++ method.
TDR But, you can have an extern "C" block that declares the call back
TDR function (the extern "C" basically keeps any name mangling from going on)
TDR and then, in that function, invoke the method as appropriate.
TDR I believe you do something like:
TDR class myclass {
TDR void mymethod(void * arg1) {
TDR cout "Ha! I got to the class" '\n';
TDR };
TDR }
TDR extern "C" {
TDR void
TDR callback_function(arg1)
TDR void *arg1;
TDR {
TDR /* Call the method */
TDR myclass::mymethod(arg1);
TDR }
TDR }
Looks good except one point -- mymethod should be static, i.e.
static void mymethod (...) {
...
}
TDR Then, you register "callback_function" as the Xt/Motif callback.
TDR I've at least "heard" of doing that kind of thing before...
--
/* Alexey Zelkin[EMAIL PROTECTED]*/
/* Tavric National University [EMAIL PROTECTED] */
/* http://www.ccssu.crimea.ua/~phantom [EMAIL PROTECTED] */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
[EMAIL PROTECTED] (Chuck Robey) writes: Boy, I sure wish Java compiled and ran natively. I'd stop using C++ forever. gcc-2.95.1 + libgcj already works, at least for simple programs. On FreeBSD 3.x programs seem to work as long as you use statically linked libraries (shared libraries cause the garbage collector to dump core). There already seems to be some awt code in libgcj, I have no idea whether it's actually functional. And the speed isn't quite comparable to what you can achieve lower-level languages (pretty close to the equivalent C++ code with all methods virtual, heavy use of rtti and common-base-class-based containers), but probably good enough for a lot of things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCI bus Latency
Greetings .. When doing a pci_read_config(dev, PCI_LATENCY_TIMER, 4) I get varying values on different hardware configurations. On Machine A the value is 32 and my device driver (using DMA) works fine. On Machine B the value is 64 and my device driver doesn't work fine - there seem s to be these hickups in which the Chip writing to the PCI controller says it ha s finished transferring data but the write counters are still 0. My card works closely with two network cards in the system. Actually, I reckon I just need some pointers and things to remember when it come s to dealing with latency. Any help? Regards eT = Etienne de Bruin [EMAIL PROTECTED] http://www.geocities.com/etdebruin __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staroffice 5.1 on 3.3-RELEASE (how I ended up getting it to work)
On Thu, 21 Oct 1999 13:44:47 -0400, Robert Watson wrote: I have not yet figured out how to get rid of the two warning messages at startup, which are irritating but appear not to actually break anything. http://www.stat.duke.edu/~sto/StarOffice51a/install.html Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UNILOAD v.1.2 (boot loader/manager) is ready
On Tue, 26 Oct 1999, Andrey Simonenko wrote: I made some days ago UNILOAD v.1.2, the main feature of this version is the ability to load system from beyond 1024 cylinder mark. Here it is Woo, that feature is _very_ useful. What about incorporating this into FreeBSD's boot code ? Regarding to UNILOAD - it is possible to remove unbootable partitions from boot menu ? -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
xntpd xcdplayer
I've noticed something peculiar over the past week or so with xntpd and I think xcdplayer (from ports). I am running xntpd to keep my clock right. I have an always on DSL connection, so I almost never see any output from xntpd. However, I've noticed that the past few times I've started playing a CD with xcdplayer, I get the following out of xntpd: Oct 27 04:10:44 mpp xntpd[153]: Previous time adjustment didn't complete Which is somewhat odd, because the last message from xntpd about adjusting the time was over 13 hours ago (and it was a 0.129016 s adjustment). Right now I am running a -current kernel from 10/17. The CD drive in question is an ATAPI device. Vendor supplied generic CD drive and builtin IDE on the mother board, so I have no idea what exactly what hardware I have :-(. Usually on the first spin up of the CD after a long period of inactivity, the machine will "pause" (mouse won't move, etc...), so I'm thinking that this might be causing something in the clock code to suffer a small stutter and cause xntpd to print out its message. Normally I ignore whatever xntpd tells me, unless it reports a large time difference. But, tonight when I was checking my mail and decided to listen to a CD while doing so, I got the "Previous time adjustment..." message right away after starting to play the CD. And after thinking back, it seems to me that I see more of around the time when I'm playing CDs, so it seems like the two might be related. It isn't a big deal to me, but I thought I would ask about it. Now, if anyone wants to donate me a nice Adaptec SCSI controller and SCSI CD drive, and maybe a hard drive:-) -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
lookup() deadlock in 3.3-stable ?
Hi
I have box running 3.3-STABLE which locks up several times per day.
After system hangs, ps command in DDB displays a lot of processes
in "inode" state. I suspect deadlock occurs:
process 45676 unlink("msg/..")
holds lock to "msg"
tries to acquire lock to "msg/..", i.e. "."
process 45678 stat("msg")
holds lock to "."
tries to acquire lock to "msg"
How-To-Repeat:
1. create test directory:
mkdir t
2. run first process
perl -e 'for(;;) { stat("t") || die }'
3. run second process
perl -e 'for(;;) { unlink("t/..") || die }'
4. run disk-bound process (one or move)
find / /dev/null
I have kernel core and ready to provide additional information.
(kgdb) proc 45676
(kgdb) where
#0 mi_switch () at ../../kern/kern_synch.c:825
#1 0xc0141c91 in tsleep (ident=0xc2e02400, priority=8,
wmesg=0xc01f229b "inode", timo=0) at ../../kern/kern_synch.c:443
#2 0xc013b613 in acquire (lkp=0xc2e02400, extflags=16777216,
wanted=1536)
at ../../kern/kern_lock.c:145
#3 0xc013b8a0 in debuglockmgr (lkp=0xc2e02400, flags=16842754,
interlkp=0xd56529f0, p=0xd54dff40, name=0xc01ea7e3 "vop_stdlock",
file=0xc01eaad7 "../../kern/vfs_subr.c", line=1275)
at ../../kern/kern_lock.c:343
#4 0xc016234d in vop_stdlock (ap=0xd550cca8) at
../../kern/vfs_default.c:211
#5 0xc01a8ac9 in ufs_vnoperate (ap=0xd550cca8)
at ../../ufs/ufs/ufs_vnops.c:2299
#6 0xc016b375 in debug_vn_lock (vp=0xd5652980, flags=65538,
p=0xd54dff40,
filename=0xc01eaad7 "../../kern/vfs_subr.c", line=1275) at
vnode_if.h:811
#7 0xc0164d45 in vget (vp=0xd5652980, flags=65538, p=0xd54dff40)
at ../../kern/vfs_subr.c:1275
#8 0xc01a3307 in ufs_ihashget (dev=1048, inum=899385)
at ../../ufs/ufs/ufs_ihash.c:113
#9 0xc01a0c23 in ffs_vget (mp=0xc2d05e00, ino=899385, vpp=0xd550cdd0)
at ../../ufs/ffs/ffs_vfsops.c:1053
#10 0xc01a3cb2 in ufs_lookup (ap=0xd550ce28) at
../../ufs/ufs/ufs_lookup.c:455
#11 0xc01a8ac9 in ufs_vnoperate (ap=0xd550ce28)
at ../../ufs/ufs/ufs_vnops.c:2299
#12 0xc0160f2a in vfs_cache_lookup (ap=0xd550ce84) at vnode_if.h:55
#13 0xc01a8ac9 in ufs_vnoperate (ap=0xd550ce84)
at ../../ufs/ufs/ufs_vnops.c:2299
#14 0xc0163429 in lookup (ndp=0xd550cf1c) at vnode_if.h:31
#15 0xc0162ee4 in namei (ndp=0xd550cf1c) at ../../kern/vfs_lookup.c:152
#16 0xc0168135 in unlink (p=0xd54dff40, uap=0xd550cf94)
at ../../kern/vfs_syscalls.c:1311
#17 0xc01d1d0b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =
134537740,
tf_esi = 134781872, tf_ebp = -1077946144, tf_isp = -716124188,
tf_ebx = 672080476, tf_edx = 134718596, tf_ecx = 1, tf_eax = 10,
tf_trapno = 7, tf_err = 2, tf_eip = 672495280, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077946192, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#18 0xc01c711c in Xint0x80_syscall ()
#19 0x280882c4 in ?? ()
#20 0x28079c3d in ?? ()
#21 0x280df0be in ?? ()
#22 0x8048da8 in ?? ()
#23 0x8048cd5 in ?? ()
(kgdb) p *(struct lock*)0xc2e02400
$17 = {lk_interlock = {lock_data = 0}, lk_flags = 2098176, lk_sharecount
= 0,
lk_waitcount = 2, lk_exclusivecount = 1, lk_prio = 8,
lk_wmesg = 0xc01f229b "inode", lk_timo = 0, lk_lockholder = 45678,
^^
^^
lk_filename = 0xc01eaa0c "../../kern/vfs_lookup.c",
lk_lockername = 0xc01ea7e3 "vop_stdlock", lk_lineno = 293}
(kgdb) p *(char**)0xd550cf94
$18 = 0x8089bb0 "msg/.."
(kgdb)
(kgdb) proc 45678
(kgdb) where
#0 mi_switch () at ../../kern/kern_synch.c:825
#1 0xc0141c91 in tsleep (ident=0xc2e03e00, priority=8,
wmesg=0xc01f229b "inode", timo=0) at ../../kern/kern_synch.c:443
#2 0xc013b613 in acquire (lkp=0xc2e03e00, extflags=16777216,
wanted=1536)
at ../../kern/kern_lock.c:145
#3 0xc013b8a0 in debuglockmgr (lkp=0xc2e03e00, flags=16842754,
interlkp=0xd565d4f0, p=0xd5402b80, name=0xc01ea7e3 "vop_stdlock",
file=0xc01eaad7 "../../kern/vfs_subr.c", line=1275)
at ../../kern/kern_lock.c:343
#4 0xc016234d in vop_stdlock (ap=0xd5493d74) at
../../kern/vfs_default.c:211
#5 0xc01a8ac9 in ufs_vnoperate (ap=0xd5493d74)
at ../../ufs/ufs/ufs_vnops.c:2299
#6 0xc016b375 in debug_vn_lock (vp=0xd565d480, flags=65538,
p=0xd5402b80,
filename=0xc01eaad7 "../../kern/vfs_subr.c", line=1275) at
vnode_if.h:811
#7 0xc0164d45 in vget (vp=0xd565d480, flags=2, p=0xd5402b80)
at ../../kern/vfs_subr.c:1275
#8 0xc0160e43 in vfs_cache_lookup (ap=0xd5493e3c)
at ../../kern/vfs_cache.c:449
#9 0xc01a8ac9 in ufs_vnoperate (ap=0xd5493e3c)
at ../../ufs/ufs/ufs_vnops.c:2299
#10 0xc0163429 in lookup (ndp=0xd5493ebc) at vnode_if.h:31
#11 0xc0162ee4 in
RE: mbuf problem (panic)--possibly related to Berkeley DB 2.7.7
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] I am using FreeBSD 3.3-RELEASE, and it is running on a single processor PII 400. At first, I thought the problem was due to the network driver, so I swapped network cards. But, the problem still continues to occur. At first, I used a DEC (de0) NIC. Then, I switched to an Intel EtherExpress Pro 10/100B Ethernet (fxp0). My machine dies when it runs out of mbufs. Normally, one only associates mbufs with network usage, and network (NIC) drivers. I have tried to investigate this possibility, as mentioned, but to no avail. The problem is either a kernel problem, or is related to the Berkeley DB, and/or perl module - BerkeleyDB-0.07.pm. I have written to Paul Marquess who is the author of this perl module. He did not respond, and may not have any idea. I got your original message, but haven't had the time to investigate your problem. After reviewing it and the messages in this thread, as you suspected, I don't have any idea. Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Some modifications to natd. proposal
Hello I use natd + libalias in my test network connected to internet. From my point of view main disadvantage of this program is, that i can't see what' s going on in packet alias engine, (ipfwadm -l -M, or ipfstat -s in ipfilter) so I'm working on patches to natd and libalias which give me that possibility. Can you suggest me, which informations about link should be displayed for links. When I look on alias table, I can see, that some links have non positive expire times calculated as link-expire_time-(timeStamp-link-timestamp) I think, that is a bad idea, and is possible to reinit link, even if it should be deleted from table as expired. For now links a deleted from alias table only as a result of HouseKeeping function called when packet is putted to procesing by alias engine Do links shouldn't be also checked against expirity at least when link is found in. _FindLinkIn Sorry About my Engllsh Best Regards Damian Kuczynski To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UNILOAD v.1.2 (boot loader/manager) is ready
Boris Popov wrote: On Tue, 26 Oct 1999, Andrey Simonenko wrote: I made some days ago UNILOAD v.1.2, the main feature of this version is the ability to load system from beyond 1024 cylinder mark. Here it is Woo, that feature is _very_ useful. Unfortunately I haven't got hard disk where I can install OS on cylinder greater than 1024 and test this feature. _But_ added LBA 'packet' interface works (I think so). I tested UNILOAD on different computers and where IBM/MS INT 13 Extensions are supported, UNILOAD always uses it. What about incorporating this into FreeBSD's boot code ? FreeBSD boot code (/usr/src/sys/boot/i386/boot0) already uses LBA 'packet' interface and can boot system from beyond 1024 cylinder mark. Regarding to UNILOAD - it is possible to remove unbootable partitions from boot menu ? Here it is some lines from file README: -14 Q: I installed UNILOAD and it shows me empty, extended partitions. How to make it don't show such partitions? A: Try to use intellect regime. Press i. -15 Q: I used intellect regime and UNILOAD printed 'No bootable entry'. Why? A: UNILOAD forced intellect regime and didn't find any bootable partition. UNILOAD automatically turns off intellect regime and prints all partitions. -16 Q: How does exactly UNILOAD work in intellect regime? A: In intellect regime UNILOAD doesn't show following partitions: partitions with Empty, Extended, Linux swap, BSDI swap fs; partitions without 0xaa55 signature. --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is there anything like #ifdef BSD
In the last episode (Oct 27), Roger Hardiman said: I'm working with someone porting linux code to FreeBSD. Actually, they want to port it to all BSDs. So, rather than having #if defined (FreeBSD) || defined (NetBSD) || defined (OpenBSD || defined (bsdi) I am looking for a #if defined (BSD) or #ifdef BSD Do you know that the code you will be putting inside this #ifdef is BSD-only code (and won't be used by OSF/1, HP-UX, Solaris, etc), or should you rather be using autoconf and checking for specific functions (setproctitle() as an example)? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is there anything like #ifdef BSD
On Wed, 27 Oct 1999, Dan Nelson wrote: In the last episode (Oct 27), Roger Hardiman said: I'm working with someone porting linux code to FreeBSD. Actually, they want to port it to all BSDs. So, rather than having #if defined (FreeBSD) || defined (NetBSD) || defined (OpenBSD || defined (bsdi) I am looking for a #if defined (BSD) or #ifdef BSD Do you know that the code you will be putting inside this #ifdef is BSD-only code (and won't be used by OSF/1, HP-UX, Solaris, etc), or should you rather be using autoconf and checking for specific functions (setproctitle() as an example)? What make are you using? If it's either a BSD make or a GNU make, then it's smart enough to be able to conditionally set a variable, if a file exists. Look for sys/param.h, and include it if it's there. It has inside it, for all BSD's, the lines: #define BSD 199506 /* System version (year month). */ #define BSD4_3 1 #define BSD4_4 1 #undef __FreeBSD_version #define __FreeBSD_version 400011/* Master, propagated to newvers */ The above is from a FreeBSD-current system, but probably, you'd not want to use the __FreeBSD_version. Use the BSD4_3 or BSD4_4, depending on what you're doing. What I'd do is detect the existence of sys/param.h and use it to set HAS_SYS_PARAM_H to 1, and then use that in your files to include sys/param.h. In the sensitive sections of code, condition them against, say, BSD4_4. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UNILOAD v.1.2 (boot loader/manager) is ready
On Wed, 27 Oct 1999, Andrey Simonenko wrote: What about incorporating this into FreeBSD's boot code ? FreeBSD boot code (/usr/src/sys/boot/i386/boot0) already uses LBA 'packet' interface and can boot system from beyond 1024 cylinder mark. Hm, I was not able to do so on the IBM's 13,5Gb drive. BIOS reports that it uses CHS mode, but boot loader was unable to reach FreeBSD partition above 1023 cylinder. Unfortunately I've had only two hours to play with new hardware and can't investigate problem now. Here it is some lines from file README: -14 Q: I installed UNILOAD and it shows me empty, extended partitions. How to make it don't show such partitions? A: Try to use intellect regime. Press i. -15 Why not to made an 'intellect' mode as default ? It would be much less confusing :). In any way, thanks for a good program. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UFS ACLs
I admittedly haven't done much homework on this topic, but I was wondering if anyone has played with the idea of implementing ACLs on top of UFS. One of the weakest areas in UNIX is its lack of fine-grained access control for resources - the biggest resource being, of course, the filesystem. Chuck Youse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UFS ACLs
I admittedly haven't done much homework on this topic, but I was wondering if anyone has played with the idea of implementing ACLs on top of UFS. One of the weakest areas in UNIX is its lack of fine-grained access control for resources - the biggest resource being, of course, the filesystem. Chuck Youse Chuck -- Go do your homework. :) Check the freebsd-security archive for copious, endless discussions on this subject, requirements therefore, etc. ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
why FFS is THAT slower than EXT2 ?
-BEGIN PGP SIGNED MESSAGE- Well, guys, listen :-) I and my friends mentioned that "FreeBSD + ffs" is often slower (THAT slower) than "Linux + ext2" for number of tasks: rm, find, tar ... for IDE SCSI disks. I didn't try things like "FreeBSD + ext2" or "Linux + ffs". I attached here results of the test I performed. For test I "gunzip"ped FreeBSD ports collection, in attachment You can find "scripted" output of "# time sh install.sh" for both systems. Also there are "dmesg" outputs. machine was THE SAME: read "dmesg", FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff" (kernel was compiled with "-O2") Linux - RedHat-6.0 with out_of_box_kernel, just "# hdparm -d 1 -c 3 -m 16 /dev/hda", read "hdparm" output... even as non-native English speaker I know few other other words which begin with "f" :-) is "fast" the propriate one for "ffs" ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBcbQuRxlWKN2EXhAQHHqgL+K+2O8gkv1kYs8AhsqbMsIFTG5u7gfzcT oqqhKlTUlTtaKtAl6g/CnKsPpxfh0CaMEmQC+5bzqSa4MnZcyHwiAWlrNLRlU08A DfYJQRGa/6S5OiaJVYnsAuKnbr6tLZGZ =YWer -END PGP SIGNATURE- wtf.tar.gz
Re: why FFS is THAT slower than EXT2 ?
One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. Chuck On Wed, 27 Oct 1999, Ilia Chipitsine wrote: -BEGIN PGP SIGNED MESSAGE- Well, guys, listen :-) I and my friends mentioned that "FreeBSD + ffs" is often slower (THAT slower) than "Linux + ext2" for number of tasks: rm, find, tar ... for IDE SCSI disks. I didn't try things like "FreeBSD + ext2" or "Linux + ffs". I attached here results of the test I performed. For test I "gunzip"ped FreeBSD ports collection, in attachment You can find "scripted" output of "# time sh install.sh" for both systems. Also there are "dmesg" outputs. machine was THE SAME: read "dmesg", FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff" (kernel was compiled with "-O2") Linux - RedHat-6.0 with out_of_box_kernel, just "# hdparm -d 1 -c 3 -m 16 /dev/hda", read "hdparm" output... even as non-native English speaker I know few other other words which begin with "f" :-) is "fast" the propriate one for "ffs" ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBcbQuRxlWKN2EXhAQHHqgL+K+2O8gkv1kYs8AhsqbMsIFTG5u7gfzcT oqqhKlTUlTtaKtAl6g/CnKsPpxfh0CaMEmQC+5bzqSa4MnZcyHwiAWlrNLRlU08A DfYJQRGa/6S5OiaJVYnsAuKnbr6tLZGZ =YWer -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. Read the post again -- they were using soft updates. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. To put it slightly more strongly: as far as I'm concerned ext2 is not a serious fs if you really care about handling power failures and other such fun things. In clusters as small as 64 machines I've measured a 5% probability that after a power failure one of the 64 ext2 file systems will have a trashed root file system. With freebsd, over a four-year span, running through lots of power outages, I didn't lose an FFS file system even *once* (except for the disk that burned up, but not even FFS can fix that one). ext2 needs a lot of help. Evidently it will be getting it soon, though. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
There is actually a discussion beginning on freebsd-fs about the possibilty to starting a journaled file system project. Perhaps the speed issues (as well as the ACL's issues) could be discussed there? -don On Wed, 27 Oct 1999, Ben Rosengart wrote: On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. Read the post again -- they were using soft updates. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Chuck Robey wrote: On Wed, 27 Oct 1999, Ben Rosengart wrote: On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. Read the post again -- they were using soft updates. Why is that important? Soft updates is still far better than an async filesystem. Have you lost files in panics? I haven't. What panics? I've been running -stable and it's been living up to the name. I was pointing out to Chuck Youse that BSD metadata writes are also (mostly) asynchronous now, so if FFS is truly slower than ext2fs, there must be some other reason. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Ben Rosengart wrote: On Wed, 27 Oct 1999, Chuck Robey wrote: On Wed, 27 Oct 1999, Ben Rosengart wrote: On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. Read the post again -- they were using soft updates. Why is that important? Soft updates is still far better than an async filesystem. Have you lost files in panics? I haven't. What panics? I've been running -stable and it's been living up to the name. I was pointing out to Chuck Youse that BSD metadata writes are also (mostly) asynchronous now, so if FFS is truly slower than ext2fs, there must be some other reason. It felt like it was a comment on the filesystem reliability (the subject of the immediately preceding paragraph). I didn't see how softupdates hurt that reliability. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, Oct 27, 1999 at 12:44:42PM -0400, Ben Rosengart wrote: On Wed, 27 Oct 1999, Chuck Robey wrote: On Wed, 27 Oct 1999, Ben Rosengart wrote: On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. Read the post again -- they were using soft updates. Why is that important? Soft updates is still far better than an async filesystem. Have you lost files in panics? I haven't. What panics? I've been running -stable and it's been living up to the name. I was pointing out to Chuck Youse that BSD metadata writes are also (mostly) asynchronous now, so if FFS is truly slower than ext2fs, there must be some other reason. I heard talk the linux folks where using btrees to better handle large directories. -- GeoffB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Chuck Robey wrote: Read the post again -- they were using soft updates. Why is that important? Soft updates is still far better than an async filesystem. Have you lost files in panics? I haven't. Soft updates should get you most of the speed that async updates do. I have lost cylinder groups in panics on systems with soft-updates. (I was using a very buggy kernel module, so things were *hosed*). The original poster hasn't really provided enough information to know what is going on, and what the performance problem is. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, Oct 27, 1999 at 09:33:20PM +0600, Ilia Chipitsine wrote: I did a similar test ages ago, only I was extracting a version of the Linux kernel. The FreeBSD machine came out about 10% faster, despite the fact it was running squid and had an older, slower disk. FreeBSD: 112.95 109.00 112.14 109.71 111.68 111.41 111.88 Linux: 122.99 122.11 123.35 121.88 121.70 123.47 124.94 I think what you're seeing is the fact that ports is an extream case. If you want to put a system which tries to keep metadata consistant through hell then create lots of small files! You could try and see how working without soft updates and working async changes the timings. (Also - make sure you've set up softupdates correctly - it is quite easy to think you've turned softupdates on and actually have them off!) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
It seems Ilia Chipitsine wrote: FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff" (kernel was compiled with "-O2") Hmm, if you didn't do a "tunefs -n enable" you are not using softupdates and there is your reason why FreeBSD is slower.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
-BEGIN PGP SIGNED MESSAGE- On Wed, 27 Oct 1999, Ronald G. Minnich wrote: On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. To put it slightly more strongly: as far as I'm concerned ext2 is not a as far as I remember ext2 has some "counter". I used to use Linux and it performed 'fsck' from time to time (even if fs was clearly unmounted). that is a very good thing to have. I do not recall that FreeBSD did such thing. serious fs if you really care about handling power failures and other such fun things. In clusters as small as 64 machines I've measured a 5% what is standard deviation equal to ? "lanl" means Los-Alamos National Laboratory ? probability that after a power failure one of the 64 ext2 file systems will have a trashed root file system. With freebsd, over a four-year span, running through lots of power outages, I didn't lose an FFS file system I DID lose FFS even it was mounted "sync", not async. even *once* (except for the disk that burned up, but not even FFS can fix that one). ext2 needs a lot of help. Evidently it will be getting it soon, though. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBc49+RxlWKN2EXhAQGu5QL/REghsBodptbhMMnvDdKW5rkjaG7v9Mvh u9YWqQjPTlcbjKzrlncsHjDGp3uVJFhOaAdCehH//lhfzGUz7BOOMz9QJhhHEPdA UoghImMubxscz76Yc+qS3rTVGE/PqnOy =kZOJ -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
-BEGIN PGP SIGNED MESSAGE- On Wed, 27 Oct 1999, Soren Schmidt wrote: It seems Ilia Chipitsine wrote: FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff" (kernel was compiled with "-O2") Hmm, if you didn't do a "tunefs -n enable" you are not using softupdates and there is your reason why FreeBSD is slower.. 'mount' without any arguments confirmed that softupdates were enabled. I cannot prove it right now, just because I reformatted the hard drive and installed Linux on it. there must be _another_ reason. try to do the same test. -Søren -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBc96ORxlWKN2EXhAQFq+AMA4LWv5wz35CCLR+XSRhKtkDfiQL/8ATvL eoxOKB19iInIBPuypbXNudJBTQf/6L4oZUqpBxoWc/oqjMTuw8ExlvhVn2xzX40f EdSb4VutlrCTwv55tCw3SLd/CZG57ye7 =uTbw -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
-BEGIN PGP SIGNED MESSAGE- On Wed, 27 Oct 1999, David Scheidt wrote: On Wed, 27 Oct 1999, Chuck Robey wrote: Read the post again -- they were using soft updates. Why is that important? Soft updates is still far better than an async filesystem. Have you lost files in panics? I haven't. Soft updates should get you most of the speed that async updates do. I have lost cylinder groups in panics on systems with soft-updates. (I was using a very buggy kernel module, so things were *hosed*). The original poster hasn't really provided enough information to know what is going on, and what the performance problem is. in order to save space I gzip'ped output of my tests. ungzipping ports tarball on FreeBSD took 28 min on Linux --- about 2.5 times faster. there's output of "time sh install.sh". David Scheidt -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOBc9bORxlWKN2EXhAQGrxgL+PBNSU1hMNRh3mA/zvQQ/OqvlsGfrr5Bc octa9cLZ3acWrZ3WXtd4CZVy75d/mKtEophUAmKWVsmvRPj0cUjvI6iZmq5EOpK4 dRxBkFFl6jyjns1SSOxBQ8tfdTby0MyZ =upZS -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
in order to save space I gzip'ped output of my tests. ungzipping ports tarball on FreeBSD took 28 min on Linux --- about 2.5 times faster. This is something we already know, and it's not the sort of test that you should ever headline as "why is FFS so much slower"? Creation of massive directory tree hierarchies under FFS is more expensive because of the way that FFS tries to keep directories spread out, in order to later have a better chance of putting files close to their parent directories. When you create a massive and mostly empty tree like the ports tree, you pay for this optimisation. The justification for this behaviour is that you only create the tree once, but you may use it for years afterwards. Thus, claiming that "FFS is slower" is both short-sighted and incorrect. If you're going to bother to publicise the results of your tests, you could try actually conducting some meaningful tests first. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Ilia Chipitsine wrote: as far as I remember ext2 has some "counter". I used to use Linux and it performed 'fsck' from time to time (even if fs was clearly unmounted). that is a very good thing to have. And it's a good thing because ... well, maybe because it's not that reliable an FS. I actually can't see it as a good thing if you have a file system that doesn't need it. I do not recall that FreeBSD did such thing. It might not have needed to. It never has in five years for me. The numbers are from my old job at sarnoff, see my web page ... for a while in 1997-99 we had "things go wrong" about once a month. Over the space of 18 months as "things went wrong" we found ourselves having to fix at least one Linux box each time. On average it was four. I DID lose FFS even it was mounted "sync", not async. I guess I was lucky :-) anyway, I'll drop this thread, just trying to fill in some info. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
:On Wed, 27 Oct 1999, Ilia Chipitsine wrote: : as far as I remember ext2 has some "counter". I used to use Linux and : it performed 'fsck' from time to time (even if fs was clearly unmounted). : that is a very good thing to have. : :And it's a good thing because ... well, maybe because it's not that :reliable an FS. I actually can't see it as a good thing if you have a file :system that doesn't need it. : : I do not recall that FreeBSD did such thing. : :It might not have needed to. It never has in five years for me. : :The numbers are from my old job at sarnoff, see my web page ... for a :while in 1997-99 we had "things go wrong" about once a month. Over the :space of 18 months as "things went wrong" we found ourselves having to fix :at least one Linux box each time. On average it was four. : : I DID lose FFS even it was mounted "sync", not async. : :I guess I was lucky :-) : :anyway, I'll drop this thread, just trying to fill in some info. : :ron To be fair, the counter gizmo for ext2fs was from a time many years ago when ext2fs was not all that reliable. I believe ext2fs has gotten quite a bit more reliable in the last year though. Also it is no longer as simple as it was originally. It turns out there's a reason for UFS/FFS's complexity. The linux crowd has similar problems with their 'simpler' swap and VM subsystems. But before people start smirking keep in mind that linux is quite a bit farther ahead of us in the SMP department. When Kirk gets his softupdates/filesystem-checkmarking code working we are going to be a step up from anything linux could hope to accomplish in the filesystem arena because we will then be able to reliably dump, checkmark, AND sanity-check the filesystem on a live (and busy) system. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
I had a nightmare problem with Linux filesystems. Yes, i'm just a newbie recreational linux user. But i had installed mandrake 6.0, which apparently had serious filesystem bugs that would corrupt data if the cdrom was mounted during shutdown. I had to reinstall because of that, and even after DL'ing the patch, since the RPM had to be forced and never did seem to work right, i never trusted it. -jm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Ronald G. Minnich wrote: On Wed, 27 Oct 1999, Ilia Chipitsine wrote: as far as I remember ext2 has some "counter". I used to use Linux and it performed 'fsck' from time to time (even if fs was clearly unmounted). that is a very good thing to have. And it's a good thing because ... well, maybe because it's not that reliable an FS. I actually can't see it as a good thing if you have a file system that doesn't need it. I seem to recall that ULTRIX had such a mechanism. There must have been other things that decremented the counter though, because my /home filesystem got fscked nearly every reboot. /usr would only be if the machine was up a really long time. DAvid Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
"IC" == Ilia Chipitsine [EMAIL PROTECTED] writes: very buggy kernel module, so things were *hosed*). The original poster hasn't really provided enough information to know what is going on, and what the performance problem is. IC in order to save space I gzip'ped output of my tests. IC ungzipping ports tarball on FreeBSD took 28 min on Linux --- IC about 2.5 times faster. I've measured ext2fs vs. FFS+softupdates many times (both with optimal hdparam settings and flags), and I've found the opposite (both with UDMA and with fast-SCSI2 disks). Benchmark programs (bonnie, iozone) show FFS is faster in almost all areas. Also creating directories with 1000s of emtpy files and deleting these is faster. The only exception might be untarring large tarballs. Linux makes more aggressive use of the filesystem buffer; it even swaps out quite active processes to be able to cache large amounts. The drawback is that the system as a whole tends to become quite sluggish, while BSD has a better balance between keeping active processes and filesystem-cache. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
as far as I remember ext2 has some "counter". I used to use Linux and it performed 'fsck' from time to time (even if fs was clearly unmounted). that is a very good thing to have. linux performed a fsck on every 16th boot afaik. This may have been changed but that is how often it occurred when I used linux. This had more to do with the file system becoming fragmented than with it becoming inconsistent. (dont quote me on that.) -don To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Thu, 28 Oct 1999, Joe Abley wrote: On Wed, Oct 27, 1999 at 10:29:54AM -0600, Ronald G. Minnich wrote: To put it slightly more strongly: as far as I'm concerned ext2 is not a serious fs if you really care about handling power failures and other such fun things. I'm not sure I've ever really understood this position. In cases where data integrity is vital to retain, there is no excuse for not using machines with multiple power supplies, each fed from independent, clean power sources, with multiple fans, running a stable, tested OS release. I take it you never have had anyone hit the Big Red Button, a fire, a flood, or a random panic, a clueless tech, or a hardware failure? I see one of my machines go down along these lines every six weeks or so. A hosed filesystem would (really!) ruin my day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
When Kirk gets his softupdates/filesystem-checkmarking code working we are going to be a step up from anything linux could hope to accomplish in the filesystem arena because we will then be able to reliably dump, checkmark, AND sanity-check the filesystem on a live (and busy) system. I would really like to see the finished product from Kirk especially given all of the work he has already done. However, what will xfs mean to linux? -don To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, Oct 27, 1999 at 04:22:20PM -0500, David Scheidt wrote: On Thu, 28 Oct 1999, Joe Abley wrote: On Wed, Oct 27, 1999 at 10:29:54AM -0600, Ronald G. Minnich wrote: To put it slightly more strongly: as far as I'm concerned ext2 is not a serious fs if you really care about handling power failures and other such fun things. I'm not sure I've ever really understood this position. In cases where data integrity is vital to retain, there is no excuse for not using machines with multiple power supplies, each fed from independent, clean power sources, with multiple fans, running a stable, tested OS release. I take it you never have had anyone hit the Big Red Button, a fire, a flood, or a random panic, a clueless tech, or a hardware failure? I see one of my machines go down along these lines every six weeks or so. A hosed filesystem would (really!) ruin my day. Actually, no, at least not in the past six years I've been working with carriers and high-spec datacentres. But I take your point :) Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: su-ing a user remotely
Date: Wed, 27 Oct 1999 16:55:30 -0400 (EDT) From: Mark [EMAIL PROTECTED] What I'm looking for Let's say there are two logins on a FreeBSD machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred can't su to root because he's not in wheel, and he doesn't/won't know the root pass. Assuming I'm logged in a root, I'd like to be able to "bless" fred from my ttyp0 and 'upgrade' his login to root. Is this feasible or programatically realistic? Is there such a tool? What would need to get changed to make this happen? Why not (temporarily) update the "sudoers" file to permit "fred" the level of access (to the requisite command(s))? Assuming, of course, that "sudo" had been set up in the first place. [Probably not really -hackers material] Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
Joe Abley wrote: On Wed, Oct 27, 1999 at 10:29:54AM -0600, Ronald G. Minnich wrote: To put it slightly more strongly: as far as I'm concerned ext2 is not a serious fs if you really care about handling power failures and other such fun things. I'm not sure I've ever really understood this position. In cases where data integrity is vital to retain, there is no excuse for not using machines with multiple power supplies, each fed from independent, clean power sources, with multiple fans, running a stable, tested OS release. all that and a nice stable fs. if you're going to do it, do it all the way. Of course, double-point failures _do_ occur. But really, not very often. Paranoia with FS writes can seem extreme considering that the network which attaches that machine to the outside world is probably not engineered to the same degree of fault protection. however, network issues don't cause nearly as much headache as fs crashes. Just my $0.02. I'm not saying that FFS should throw caution to the wind (especially not in the default configuration) but to argue that async writes are only ever used by stupid people is a little unfair :) i never saw an argument that people who use async writes were stupid. i saw a statement that said async writes do not recover from power failures as well, and if you are concerned about that, you shouldn't use an async fs. this thread is chatty enough without misquoting people. damon -- Damon Conway Black Rock City Ranger...Riding the edge of chaos "Ana Ng and I are getting old, but we still haven't walked in the glow of each other's majestic presence." -- TMBG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Mike Smith wrote: in order to save space I gzip'ped output of my tests. ungzipping ports tarball on FreeBSD took 28 min on Linux --- about 2.5 times faster. This is something we already know, and it's not the sort of test that you should ever headline as "why is FFS so much slower"? Kirk has said that it would be possible for the FFS to modify its behaviour if it notices this usage pattern. Creation of massive directory tree hierarchies under FFS is more expensive because of the way that FFS tries to keep directories spread out, in order to later have a better chance of putting files close to their parent directories. When you create a massive and mostly empty tree like the ports tree, you pay for this optimisation. The justification for this behaviour is that you only create the tree once, but you may use it for years afterwards. Thus, claiming that "FFS is slower" is both short-sighted and incorrect. If you're going to bother to publicise the results of your tests, you could try actually conducting some meaningful tests first. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [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 the message
Re: su-ing a user remotely
On Wed, Oct 27, 1999 at 04:55:30PM -0400, Mark wrote: I'm looking for a tool which I think I'll have to end up making myself. What I'm looking for Let's say there are two logins on a FreeBSD machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred can't su to root because he's not in wheel, and he doesn't/won't know the root pass. Assuming I'm logged in a root, I'd like to be able to "bless" fred from my ttyp0 and 'upgrade' his login to root. Is this feasible or programatically realistic? Is there such a tool? What would need to get changed to make this happen? A friend of mine shortly ago mentioned a tool he wrote some time ago that would scan /dev/kmem for a process with a specific PID and change the UID of this process to whatever value you wanted it to be. You can get it from: ftp://ftp.42.org/pub/FreeBSD/presto-1.1.tar.gz Using it you should be able to change this the UID of fred's loginshell, which should accomplish what you are looking for. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cdd produces only noise from CD-AUDIO tracks
Under -current built from Oct 22 soucrces, and cdd built today, ripping CD-AUDIO tracks just produces output files which are just a loud hiss. I've tried this with both of my CD-ROM drives to no avail, and it used to work for both of them under -current several months ago. wcd0: drive speed 5512KB/sec, 256KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA wcd0: Audio: play, 255 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked wcd1: drive speed 344 - 1034KB/sec, 768KB cache wcd1: supported read types: CD-R, CD-RW, CD-DA, packet track wcd1: supported write types: CD-R, CD-RW, test write wcd1: Audio: play, 128 volume levels wcd1: Mechanism: ejectable tray wcd1: Medium: no/blank disc inside, unlocked, lock protected Anyone have some insight on this? I think I remember seeing a thread along these lines some time ago, but didn't take notice at the time and can't find it in the list archives. -- Brian Buchanan [EMAIL PROTECTED] -- FreeBSD - The Power to Serve! http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: su-ing a user remotely
On 27-Oct-99 Mark wrote: I'm looking for a tool which I think I'll have to end up making myself. What I'm looking for Let's say there are two logins on a FreeBSD machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred can't su to root because he's not in wheel, and he doesn't/won't know the root pass. Assuming I'm logged in a root, I'd like to be able to "bless" fred from my ttyp0 and 'upgrade' his login to root. Is this feasible or programatically realistic? Is there such a tool? What would need to get changed to make this happen? Take a look at the sudo, super, and su2 ports and see if any of those can do what you need. Thx. --- John Baldwin [EMAIL PROTECTED] -- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
Chuck Robey wrote: On Tue, 26 Oct 1999 [EMAIL PROTECTED] wrote: Thomas David Rivers writes: If you mean Xt (and possibly Motif) - the answer is "very carefully." [...] You're approach would probably work, but there's an easier way. See topic 28 in the Xt FAQ. ftp://ftp.x.org/contrib/faqs/FAQ-Xt It's not name mangling causing problems, it's lack of "this" when the method is invoked as a callback from Xt. Yes! This is the method! I like it, or at least, it's as close (in C++ code) to something I do like. I assume they're using a static member function for the callback and storing the this pointer for the object somewhere handy? This is the canonical way to re-enter C++ code from C land, and can even be used for C++ interrupt handlers if you're very careful. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: su-ing a user remotely
On Wed, 27 Oct 1999, Mark wrote: I'm looking for a tool which I think I'll have to end up making myself. What I'm looking for Let's say there are two logins on a FreeBSD machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred can't su to root because he's not in wheel, and he doesn't/won't know the root pass. Assuming I'm logged in a root, I'd like to be able to "bless" fred from my ttyp0 and 'upgrade' his login to root. Is this feasible or programatically realistic? Is there such a tool? What would need to get changed to make this happen? I do this on sparc boxes occaisonally using the nifty forth interperter in the boot ROM to change the UID of some process. Handy for recovering random lost passwords. I suspect that you could do the same with a debugger on FreeBSD, but haven't really thought about it. David scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Wed, 27 Oct 1999, Wes Peters wrote: Chuck Robey wrote: On Tue, 26 Oct 1999 [EMAIL PROTECTED] wrote: Thomas David Rivers writes: If you mean Xt (and possibly Motif) - the answer is "very carefully." [...] You're approach would probably work, but there's an easier way. See topic 28 in the Xt FAQ. ftp://ftp.x.org/contrib/faqs/FAQ-Xt It's not name mangling causing problems, it's lack of "this" when the method is invoked as a callback from Xt. Yes! This is the method! I like it, or at least, it's as close (in C++ code) to something I do like. I assume they're using a static member function for the callback and storing the this pointer for the object somewhere handy? This is the canonical way to re-enter C++ code from C land, and can even be used for C++ interrupt handlers if you're very careful. Yes, you store the address of the object you want the callback vectored to in the UserData Xt pointer, and when the callback comes into the static func, it just takes the offered object address and reflects the call back out to the right function in the right object. Neat, the user never sees any complication at all. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Oct 27, 2:51pm, Julian Elischer wrote: } Subject: Re: why FFS is THAT slower than EXT2 ? } } } On Wed, 27 Oct 1999, Mike Smith wrote: } } in order to save space I gzip'ped output of my tests. } ungzipping ports tarball on FreeBSD took 28 min } on Linux --- about 2.5 times faster. } } This is something we already know, and it's not the sort of test that } you should ever headline as "why is FFS so much slower"? } } Kirk has said that it would be possible for the FFS to modify its } behaviour if it notices this usage pattern. The basic problem is that the directory layout policy that FFS uses is very non-optimal in this case. This was discussed extensively on freebsd-hackers last year, search the list archive for Reading/writing /usr/ports VERY slow Carl Mascott noticed nearly a 3x speedup when he untarred /usr/ports on FFS filesystem that was generated with only one cylinder group. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UFS ACLs
Chuck Youse wrote: I admittedly haven't done much homework on this topic, but I was wondering if anyone has played with the idea of implementing ACLs on top of UFS. One of the weakest areas in UNIX is its lack of fine-grained access control for resources - the biggest resource being, of course, the filesystem. As my personal experience with Novell Netware shows most of the time the presence of the fine-grained access control is a great temptation to create a complete mess in the filesystem. The thing I personally feel neccessary is being able to assign access rights to a file to two separate groups because it's cheap and resolves most of the problems. I have implemented it as a small patch that works with both FFS and EXT2FS in FreeBSD. Let me know if you are interested in looking at it. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
timer interrupts
This message was sent from Geocrawler.com by "Manju Radhakrishnan" [EMAIL PROTECTED] Be sure to reply to that address. Hi, I am trying to modify IP code in FreeBSD so that the packets from IP layer are not immediately sent to the interface output but they are buffered and sent at a certain rate. So I need to set an interrupt such that a function is called after some time interval. Is using timeout the only way? since timeouts are at a priority lower than network priority, is there anything else that I can use. thanks for the help, Manju Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Running unattended (ifo FFS thread)
On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. This means that it generally always gets through the fsck.. Of course if fsck had to delete files then they're gone, but if you value its ability to stay up without human intervention its handy. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On 27-Oct-99 Peter Mutsaers wrote: The only exception might be untarring large tarballs. Linux makes more aggressive use of the filesystem buffer; it even swaps out quite active processes to be able to cache large amounts. The drawback is that the system as a whole tends to become quite sluggish, while BSD has a better balance between keeping active processes and filesystem-cache. Is there anyway to tune this behaviour under FreeBSD? I know the argument is that 'FreeBSD is self tuning' but some of us are unable to resist fiddling =) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. This means that it generally always gets through the fsck.. Of course if fsck had to delete files then they're gone, but if you value its ability to stay up without human intervention its handy. The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
On 28-Oct-99 Kevin Day wrote: This means that it generally always gets through the fsck.. Of course if had to delete files then they're gone, but if you value its ability to stay without human intervention its handy. The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. Yeah, the machines we have don't get shutdown except for a power failure so that wasn't a problem :) I'll have a look for your PR tho. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Running unattended (ifo FFS thread)
On Thu, 28 Oct 1999, Daniel O'Connor wrote: On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. we do fsck -p || fsck -y This means that it generally always gets through the fsck.. Of course if fsck had to delete files then they're gone, but if you value its ability to stay up without human intervention its handy. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum 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
ip forwarding broken on alpha
I have an older AlphaStation 600 5/266 running -current (cvsupped
last week) which is setup as a router between 2 100mb networks. When
the machine is pushed fairly hard (like running a netperf -tUDP_STREAM
-- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the
alpha falls over almost instantly. I have not enabled any NAT or
firewall functionality, just ip forwarding.
It generally crashes in MCLGET down in the ethernet driver's receiver
interrupt handler. The driver doesn't seem to matter -- I've tried
Intel Etherexpress Pro 100Bs and 3Com 3c905C-TX Fast Etherlink XLs. A
typical stack trace looks like this:
fatal kernel trap:
trap entry = 0x2 (memory management fault)
a0 = 0x826417b78f222
a1 = 0x1
a2 = 0x0
pc = 0xfc4b31bc
ra = 0xfc4b315c
curproc= 0
ddbprinttrap from 0xfc4b31bc
ddbprinttrap(0x826417b78f222, 0x1, 0x0, 0x2)
panic: trap
panic
Stopped at Debugger+0x2c: ldq ra,0(sp) 0xfe0005ab57d0 ra=0xff
fffc5042e0,sp=0xfe0005ab57d0
db tr
Debugger() at Debugger+0x2c
panic() at panic+0xf4
trap() at trap+0x5cc
xl_newbuf() at xl_newbuf+0x15c
(null)() at 0x4
db c
this maps to pci/if_xl.c:1654. But the if_xl driver is probably not
at fault, as I can crash just as easily in fxp_add_rfabuf() when using
intel nics.
Before trying the 3com cards, I had been working under the assumption
that it was a problem with the fxp driver. I instrumented the mbuf
routines somewhat (i hate debugging macros) and it seems the bad
access is due to mclfree getting trashed replaced by a "random" bad
value (0x826417b78f222 in this panic).
This might be a red herring, but I've found that if I run the entire
ip_input path under splnet() (added splnet() around the call to
ip_input() in ipintr().), things get a hell of a lot more stable.
Rather than crashing in a few seconds, it sometimes takes minutes.
And rather than an illegal access, I tend to run out of kernel stack
space ( either a panic("possible stack overflow\n"); in
alpha/alpha/interrupt.c, or I end up in the SRM console after calling
halt from a PC which isn't in the kernel, which smells like an overrun
stack to me). I'm not sure if this is related, or if it is a separate
problem entirely.
Since an x86 (PII@300MHz, 440lx motherboard, kernel built from same
sources) is rock solid under the same workload, I suspect there's
something wrong that is alpha specific, but I'll be damned if I can
figure it out.
My best guess is that it has something to do with the different
interrupt structure on i386 alpha. As I understand it, the i386 can
mask off particular interrupt sources, but the alpha simply raises
lowers the ipl with the following levels available
(from alpha/include/alpha_cpu.h):
#define ALPHA_PSL_IPL_0 0x /* all interrupts enabled */
#define ALPHA_PSL_IPL_SOFT 0x0001 /* software ints disabled */
#define ALPHA_PSL_IPL_IO0x0004 /* I/O dev ints disabled */
#define ALPHA_PSL_IPL_CLOCK 0x0005 /* clock ints disabled */
#define ALPHA_PSL_IPL_HIGH 0x0006 /* all but mchecks disabled */
Can anybody hazard a guess as to what's going on? I've appended dmesg
output my config file for completeness.
BTW, as long as the load is light, ip forwarding seems to work. I
can't seem to make this happen using 2 100Mb tulips in this box (which
must copy on the input path due to DMA alignment problems, this slows
things down quite a bit, due to the low memory bandwidth of this
machine)
Thanks,
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #4: Wed Oct 27 11:35:25 EDT 1999
[EMAIL PROTECTED]:/usr/project/ari_scratch2/gallatin/src/sys/comp
ile/ALPHA
AlphaStation 500 or 600 (KN20AA)
Digital AlphaStation 600 5/266, 266MHz
8192 byte page size, 1 processor.
CPU: EV5 (21164) major=5 minor=0
OSF PAL rev: 0x100020116
real memory = 131940352 (128848K bytes)
avail memory = 122200064 (119336K bytes)
Preloaded elf kernel "kernel" at 0xfc674000.
cia0: ALCOR/ALCOR2, pass 2
pcib0: 2117x PCI host bus adapter on cia0
pci0: PCI bus on pcib0
xl0: 3Com 3c905C-TX Fast Etherlink XL irq 8 at device 7.0 on pci0
xl0: interrupting at CIA irq 8
xl0: Ethernet address: 00:50:da:09:3e:41
miibus0: MII bus on xl0
xlphy0: 3c905C 10/100 internal PHY on miibus0
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcib1: DEC 21050 PCI-PCI bridge at device 8.0 on pci0
pci1: PCI bus on pcib1
de0: Digital 21040 Ethernet irq 16 at device 0.0 on pci1
de0: interrupting
RE: Running unattended (ifo FFS thread)
On Thu, 28 Oct 1999, Daniel O'Connor wrote: On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. It isn't really clear what else you would do, though. Most people don't know enough to fix things that fsck can't. If it hoses the box, restore from backup. It is what they are for! David scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
I don't know waht really happened, but the originally quoted numbers sound fishy to me. There may well be some other problem. I ran two tests on my rather modest machine (P166, 64mb, UW Scsi Drives, 3.3-Stable). I have soft updates turned on. (correctly, I might add :-) Unpacking the ports file from a tarball: 6:30 Creating a ports dir tarfile: 4:30 The filesystems in question were about 800 megs, created with default settings. I'd say thats pretty acceptable performance. -- Robert Sexton - [EMAIL PROTECTED], Cincinnati OH, USA Getting to Know your friends, Part VIII: "Jerry is a little too Cerebral for me. But then again, he likes Twinkies." Read the Newton FAQ! http://www.kudra.com/newton/newton-faq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UNILOAD v.1.2 (boot loader/manager) is ready
On Tue, 26 Oct 1999, Andrey Simonenko wrote: I made some days ago UNILOAD v.1.2, the main feature of this version is the ability to load system from beyond 1024 cylinder mark. Here it is Woo, that feature is _very_ useful. What about incorporating this into FreeBSD's boot code ? We already support it, but it's turned off by default because a number of the systems we tested didn't like it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI bus Latency
Please try wrapping your messages to a sane width; try 72 columns. When doing a pci_read_config(dev, PCI_LATENCY_TIMER, 4) I get varying values on different hardware configurations. On Machine A the value is 32 and my device driver (using DMA) works fine. On Machine B the value is 64 and my device driver doesn't work fine - there seem s to be these hickups in which the Chip writing to the PCI controller says it has finished transferring data but the write counters are still 0. My card works closely with two network cards in the system. Since you don't make it clear what "the Chip" and "the PCI controller" are, it's kinda hard to be very helpful here. Actually, I reckon I just need some pointers and things to remember when it comes to dealing with latency. Any help? I'd start by buying and reading the PCI specification document end to end. You can probably skip the section on physical dimensions, but just about all of the rest of it is relevant. You can save a little time and a lot of money by getting a copy of the Shanley book "PCI System Architecture". Most online bookstores have it; it's cheap. Without meaning to be insulting, it's probably not worthwhile pursuing this further until you've read one or both of the above, since we'd just be regurgitating large portions of the books. Buy, read, and if you're still having trouble then come back and try again. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
