Re: Mandatory locking?
On Monday, 23 August 1999 at 8:47:34 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. My real question was more like "OK, I have a situation coming up in which I need to be able to lock out other processes. What tools are available for it". I don't know yet whether what I end up with can be solved by this method, but it's nice to know what tools you have. You certainly wouldn't want to lock out access to the entire device during this time. I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
In message [EMAIL PROTECTED], Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. I still don't see the need for mandatory locking, or locking out user access in general... I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Well, maybe you were more lucky, I've had my share of troubles, and I think the very concept stinks... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999, Sheldon Hearn wrote: The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. Yes, I agree that that's what it means. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' This makes no sense. to mean "When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one." The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) The above is not flexibility; it's just different behavior. We need to follow their specifications so things can be portable. So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 9:47:40 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. I still don't see the need for mandatory locking, or locking out user access in general... I'll try to explain, using a different example, since I'm not quite sure where my rebuild stuff is going yet. To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Consider what happens if a second request which refers the same parity data comes in during this business: 1. Read the old data into a temporary buffer. 1a. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 2a. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 3a. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 4a. XOR the result with the data which is to be written. 5. Write the data block. 5a. Write the data block. 6. Write the parity block. 6a. Write the parity block. The parity data read at (2a) will be wrong. It won't know of the data block to be written at (6). If the volume becomes degraded, it may no longer know about the first transaction. For this, we don't need fcntl locking: it would be too slow, and it's all done in the kernel anyway. In userland, we'd use a different example: I make a number of financial transactions over the Internet. In each case, the system checks my account balance, transfers the money and deducts it from my account: 1. Check balance. 2. Perform transfer. 3. Write updated balance back. Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus "forget" one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the same thing: file protection belongs in the kernel. I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Well, maybe you were more lucky, I've had my share of troubles, and I think the very concept stinks... You and Garrett. I've never heard this from *anybody* else. The general opinion I've heard until now was that the lack of mandatory locking was a significant weakness in BSD. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPsec/IPv6
Bah, so FreeBSD will be InSecureBSD ? Well, so long as the ITAR bear stands around making grizzly noises at people, it seems. I wouldn't count on that. As far as I can tell, what's holding KAME integration up is the fact that they're not done merging with INRIA yet. A news about NRL/INRIA/KAME merging (unified-ipv6). unified-ipv6 project has been in big trouble with manpower, design differences. Recently situations changed for all of us so here's the decision we have made. NRL decided to concentrates on IPsec (because in US not much interest in IPv6 than IPsec - people in US are lucky about IPv4 address space, it seems). INRIA will be doing future researches on top of KAME code. KAME agreed to add some knobs that helps INRIA to do their experiment. So, it is planned that KAME will have an alias: "unified-ipv6". KAME team is trying to ship KAME/OpenBSD and KAME/BSDI4 during this month or next month (September). KAME September 30th STABLE kit will officially have "unified-ipv6" alias on it. It is now okay to merge KAME code into FreeBSD, I believe. If you do not feel ready, I'll be visiting FreeBSDCon so let's talk about it there (but will cause 2 month delay from now). The biggest problem is how to keep mutiple repositories in sync. KAME (= unified-ipv6) code shares most of IPv6 code among *BSD platforms. If FreeBSD repository is modified after import, and that conflicts with content in KAME repository, we can't merge that back in. So I would like to suggest FreeBSD project to refrain from changing IPv6 part too much, for certain amount of time (*). Rather, please send diffs to KAME. Once that happens, I'm more than happy to continue to lean on Justice Maryln Patel's decision on crypto as free speach in the S.F. Bay Area region. We've already talked to our lawyer, he said it looked legit to him, and so we've been shipping crypto on our CDs for over a year now. I even announced it back then, to almost no audience reaction whatsoever. It seems that people like to get more excited about the prospect of something being closed than it being opened up. :) It now happened, so please contact Mr. Patel:-) KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). itojun (*) As a side note: actually, KAME and unified-ipv6 has been experiencing big trouble sharing IPv6 code among *BSD, due to FreeBSD's variable renaming like ifa_list (ifa_link on others) or time_second (why FreeBSD couldn't reuse time.tv_sec to hold this? I don't get it). I'd like propose to fix those back to more standard ones (ifa_link or time.tv_sec) for portability among *BSD. If you are okay, those changes will come with FreeBSD/KAME integration. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On 23-Aug-99 Greg Lehey wrote: I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. I think its a good idea, and hey if people object it can always be an option like - option NO_MANDATORY_LOCKING Not quite - developers have to deal with the mess that it would cause - Matt for example says: :Ugh. Yuch. No, nothing to do with permission bits, not for something :this convoluted! Are you saying that he should just enable an option and forget about it when he tweaks something horrible in NFS that only a handfull of others understand ? :-I -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setting up -STABLE for hack contest
Evren Yurtesen writes : it is possible to detect operating systems from their behaviours of replying to packets. see the program queso from ports/packages. but anyway you can change the login prompt from /etc/gettytab file Also have a look at ports/security/nmap, and go to www.insecure.org. In order to stop someone guessing your OS, you will need to make changes to your TCP implementation. These include, changing the way in which TCP initial sequence numbers are calculated, as well as changing behaviour of TCP wrt the handling of certain "unexpected" TCP segments on open or closed ports - e.g. what happens when someone sends a surprise FIN segment to a closed port. Geoff. -- Geoff Rehmet, The Internet Solution [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] tel: +27-83-292-5800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
proposed change for /etc/periodic/* scripts
Hi, Currently, the reports that are generated and emailed to root are fine in what they do. however, a lot of the time there is actaully nothing of interest in these reports if nothing has gone wrong on the system etc. Basically I only want to know about the changes that have happened. This would be useful in cutting down the size of these emails esp. when you are receiving them from multiple fbsd servers.. :P example: * if there are no passwd/group diffs found, don't print anything out (not even the header). Same for setuid etc. diffs. * For the 'df' status, only report filesystems that are over a certain capacity (95% or only xxMb left etc..) and the same for all the other tests..basically if there's nothing to report don't print anything (not even the header) otherwise print the header and the results.. Ideas / Comments / Suggestions ? - Cillian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, 23 Aug 1999 09:59:29 +0100, Cillian Sharkey wrote: Ideas / Comments / Suggestions ? Diffs ? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: On TCP sequence numbers
[ Geoff Rehmet ] Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Just a funny (?) aside - while playing about with nmap here a while back, a colleague accidentally discovered that our Digital (or Compaq Tru64, if you want to be perverse) Unix 4.0E box was using a constant (?!) sequence number. Cian -- What think ye of Christ? Whose son is he? Will you, like Peter, boldly say: "Who?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 01:00:05 MST, "Brian F. Feldman" wrote: The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. That's good enough for me. :-) If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. I'm not to phased with backward compatibility on this one, since I think it's always been understood that the output of ls isn't really intended for scripts (that's what find and test are for). The OpenGroup spec actually makes a point of that in its manpage. Thanks for your input. Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Slightly BSD related problem
Hi, I've got a problem with my machine at home which is slightly BSD related (cause ONLY BSD could handle the problem:))). So: At this moment, I've got a 2.2.7-FreeBSD and an NT installed on my PC. There are two hard drives in the PC, the primary master IDE drive is a 2.5 Quantum drive, it is set to LBA in the BIOS. The second one is secondary slave, an old 405M Quantum drive. The (AWARD) BIOS can't recognize right geometry of the latter one via 'IDE HD autodetection'. The first HD has got the NT and BSD installed and a 'booteasy' in the root sector installed from the FreeBSD distribution. Although booteasy can recognize the type of the partitions on the first HD, it cannot boot them. The only way to boot up my PC is to insert the BSD install CD in the CD drive and when the BSD boot prompt appears, type: 1:wd(0,a)kernel. After that, the BSD already installed on the hard drive would start up, recognizes is all the parts of the PC and everything would run fine as they should. This situation happened tho weeks ago. Before, my PC work quite well, w/o problems. I would like to know, where does BSD know from the geometry of the disks when BIOS can't get them. Thanks in advance Sebestyn Zoltn [EMAIL PROTECTED]I'm believing that the Holy Spirit is gonna allow the hand, and the foot, and MAKE INSTALL NOT WARthe mouth, just to begin to speak, and to minister, and to heal coordinated by the head. I use UNIX because reboots are for hardware upgrades. Kick me! Whip me!! Make me develop on AIX!!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 11:36:00 +0200, Sheldon Hearn wrote: If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. Eeek, I've been confused. Our -o and the OpenGroup spec's -o are completely different. :-) The -n option will imply -l, but -o will be a no-op unless at least one of -n and -l is specified. Manpage changes will be included in the deal. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
call system function in logout.c ceate zombie process
Hi all, if I put command like "system(/usr/local/bin/radacct)" in logout.c everything goes normal but _if_ user logout normally that is, at prompt user type logout the problem is when user login using ssh and connection terminated by accident such as the client hang and have reboot, utmp wasn't clear and sshd become a zombie process is there any suggestion to avoid this problem ? thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 13:13:14 +0200, Sheldon Hearn wrote: The -n option will imply -l, but -o will be a no-op unless at least one of -n and -l is specified. Manpage changes will be included in the deal. The diff for this change is available from: http://www.freebsd.org/~sheldonh/ls.diff.n_implies_l Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml]
While going through old cvs commit log, I spotted this: Index: param.h === RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.50 diff -u -r1.50 param.h --- param.h 1999/06/20 08:34:24 1.50 +++ param.h 1999/06/20 17:56:50 @@ -45,6 +45,8 @@ #defineBSD 199506 /* System version (year month). */ #define BSD4_3 1 #define BSD4_4 1 + +/* Please update doc/en/handbook/ports/chapter.sgml when changing */ #undef __FreeBSD_version #define __FreeBSD_version 48 /* Master, propagated to newvers */ With the recent changes to the doc tree, should this file be updated too? (Or maybe it was and I haven't seen that log yet :) -- Daniel C. Sobral [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
[EMAIL PROTECTED] (John-Mark Gurney) writes: Christopher Seiwald scribbled this message on Aug 18: It's a pretty straightforward change to bypass the insertion sort for large subsets of the data. If no one has a strong love for qsort, I'll educate myself on how to make and contribute this change. why don't you implement this w/ the 5 element median selection qsort algorithm? my professor for cis413 talked about this algorithm and that it really is the fastest qsort algorithm... I don't have any pointers to a paper on this... but I might be able to dig some info up on it if you are interested... I don't think the point is eliminating worst-cases, but optimizing common cases, which in this case caused more worst-cases and thus needs fixing. Besides, the median selection chooses among more than 3 elements already (but only when the data set is large enough). For fixing worst cases, an introspective sort might be a good idea, i.e. do a quick sort but fall back to heap sort if a certain depth is exceeded (you know you're losing when the depth exceeds log n). This also has another advantage - if you limit the depth of the sort, you don't need to use the cpu stack for state, you can allocate a fixed-size array for the purpose. This probably isn't a real performance advantage for a C qsort implementation because of the overhead of calling cmp. It does, however, guarantee that sorting uses a reasonable amount of stack. Such an assumption isn't portable when using qsort(3), though. Expect to die if you do large qsorts from threads with small thread stacks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
building -STABLE release
What would be the right releasetag to use in order to build a 3.2-STABLE 'release' (make release)? Would that be RELENG_3 ? From looking at 'cvs log Makefile' in the top of the source tree I get: symbolic names: RELENG_3_2_PAO: 1.222.2.4.0.2 RELENG_3_2_PAO_BP: 1.222.2.4 RELENG_3_2_0_RELEASE: 1.222.2.4 RELENG_3_1_0_RELEASE: 1.222.2.1 RELENG_3: 1.222.0.2 RELENG_3_BP: 1.222 (older stuff omitted). PAO is laptop stuff, BP == ???, RELEASE is obvious. Leaves RELENG_3 I think Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
[EMAIL PROTECTED] (Greg Lehey) writes: Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus "forget" one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the The difference is that if a program has privileges to screw up whatever you are protecting, it can do so even if you do have mandatory locking, simply by functioning incorrectly when it does gain access to the data. And even without otherwise incorrect behavior, if you have a program that doesn't use any locking and another one that uses mandatory locking to prevent races with the non-locking program, the mere existence of the locking program does not prevent multiple non-locking programs from generating similar conditions. (I'm not opposed to mandatory locking in principle, but I don't find your reasoning very convincing.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On 23 Aug 1999, Ville-Pertti Keinonen wrote: [EMAIL PROTECTED] (Greg Lehey) writes: Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus "forget" one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the The difference is that if a program has privileges to screw up whatever you are protecting, it can do so even if you do have mandatory locking, simply by functioning incorrectly when it does gain access to the data. And even without otherwise incorrect behavior, if you have a program that doesn't use any locking and another one that uses mandatory locking to prevent races with the non-locking program, the mere existence of the locking program does not prevent multiple non-locking programs from generating similar conditions. That's very odd, I thought the idea behind mandatory locking was to completely eliminate the possibility that a program could do what you're saying; all programs would *mandatorily* be forced to do locking to access the resource. It's the advisory locking that allows the scenario you paint. I think mandatory locking should exist, but only be available to root. If a program needs this, it must run with root privs, so that ordinary users cannot wedge the machine, but (as usual) root can shoot himself in the foot (traditional Unix methodology). (I'm not opposed to mandatory locking in principle, but I don't find your reasoning very convincing.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new device driver
Hi, A friend (Juha) has written a new device driver for another batch of video capture cards from LifeVide, Genoa and ATIech which use the Zoran and Philips SAA chipset. The driver is likely to be called ztv If I add this to FreeBSD, where is the best place Keep it in /usr/src/sys/pci Or add it to /usr/src/sys/dev/... perhaps /usr/src/sys/dev/pci/ztv What are we doing now with new PCI device drivers? Thanks Roger -- Roger Hardiman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, 23 Aug 1999, Cillian Sharkey wrote: Keeping records would be handy alright..but cutting out all the "everything is ok" msgs would reduce reading time..having an option for full report OR just the important results should satisfy everyone.. What I do run things through a filter that shows only things that I find interesting. It is only a few dozens of lines of shell. I don't actually do this for FreeBSD daily reports, because there isn't enough there to worry about, but for my application stuff it works a treat. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: building -STABLE release
On Mon, 23 Aug 1999, Wilko Bulte wrote: What would be the right releasetag to use in order to build a 3.2-STABLE 'release' (make release)? Would that be RELENG_3 ? Yes. Though RELENG_3 is a branch tag. RELENG_3_2_PAO: 1.222.2.4.0.2 RELENG_3_2_PAO_BP: 1.222.2.4 RELENG_3_2_0_RELEASE: 1.222.2.4 RELENG_3_1_0_RELEASE: 1.222.2.1 RELENG_3: 1.222.0.2 RELENG_3_BP: 1.222 PAO is laptop stuff, BP == ???, RELEASE is obvious. Leaves RELENG_3 I think BP = branchpoint. Look at RELENG_3_BP, it's 1.222, that's when it was split. Look at RELENG_3, it's 1.222.0.2, which would be the second revision of that file since it was branched, I think. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
Greg Lehey wrote: all done in the kernel anyway. In userland, we'd use a different example: I make a number of financial transactions over the Internet. In each case, the system checks my account balance, transfers the money and deducts it from my account: 1. Check balance. 2. Perform transfer. 3. Write updated balance back. Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus "forget" one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the same thing: file protection belongs in the kernel. Well, I'd say advisory lock does the job if the software is written right, and if the software is not written right, mandatory locking won't help. Let's give an example. You right a program using mandatory locking making access to a file. I write an "incorrect" program accessing that file. I garantee you that the file is going to be screwed up, because I intend to write random output to it as soon as I get access to it. After all, if I'm incorrect, I'm allowed to do anything. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
Daniel O'Connor wrote: On 23-Aug-99 Greg Lehey wrote: I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. I think its a good idea, and hey if people object it can always be an option like - option NO_MANDATORY_LOCKING Phew, that was tough. When introducing security holes, the default should be the hole not being present. Ie, reverse that option. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SPARC?
On Mon, 23 Aug 1999 11:28:20 -0400 Dennis [EMAIL PROTECTED] wrote: I heard a rumor that freebsd runs on a sparc, but I dont see any backing for that. Is it in the works? FreeBSD does not run on the SPARC. I think they've been talking about it for ... what, 5 years now... but it never materialized. NetBSD, however, runs quite well on the SPARC. Sun4 - Ultra is incomplete in NetBSD, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[freebsdcon] radisson reservation
(I believe it got bounced due to my mistake in To: line. sorry if you got it multiple times) Hello, if this mailing list is inappropriate please tell me so. I contacted radisson hotels for FreeBSDCon reservation with special discount, to get the following email - they don't know about special rate code "FreeBSDCon". What is the exact code for reservation? Do any of you have success experience with it? Also, the email suggests that web reservation does not work for special rate reservation. You may want to update freebsdcon.org webpages. itojun --- Forwarded Message Return-Path: [EMAIL PROTECTED] Received: from bricks.carlson.com (mail.carlson.com [208.240.12.67]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA01929 for [EMAIL PROTECTED]; Mon, 23 Aug 1999 18:57:14 +0900 (JST) Received: from mail.carlson.com (root@localhost) by bricks.carlson.com with ESMTP id EAA15651 for [EMAIL PROTECTED]; Mon, 23 Aug 1999 04:57:09 -0500 (CDT) Received: from otcmsg07.carlson.com (otcmsg07.carlson.com [172.24.129.74]) by mail.carlson.com with SMTP id EAA15647 for [EMAIL PROTECTED]; Mon, 23 Aug 1999 04:57:08 -0500 (CDT) Received: by otcmsg07.carlson.com with Internet Mail Service (5.5.2448.0) id P0HFJBXG; Mon, 23 Aug 1999 04:57:05 -0500 Message-ID: [EMAIL PROTECTED] From: Omaha Specialists [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Cc: Omaha Specialists [EMAIL PROTECTED] Subject: RE: * Radisson Hotels Date: Mon, 23 Aug 1999 04:55:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Filter: mailagent [version 3.0 PL56] for [EMAIL PROTECTED] Mr Hagino, Special group/conference rates are not available via the web - we did contact the hotel and they don't show a special rate for your group - what does BSD stand for? All the groups that we have listed here have to be booked with the hotel directly. I can provide you with their phone and fax number. Phone# is 510-548-7920 fax# 510-548-7944. You may want to contact them directly concerning this conference. Sincerely, Geri Lowe Radisson Hotels International -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Sunday, August 22, 1999 11:34 PM To: [EMAIL PROTECTED] Subject: * Radisson Hotels Mozilla/4.51 [en] (X11; I; NetBSD 1.4 i386; Nav) gw.radisson.com jun-ichiro hagino +81-3-3490-9225 I would like to reserve a non-smoking room, 1 adult, 18/oct/99 - 21/oct/99, at Radisson Berkeley Marina (Berkeley CA). I'm attending FreeBSDCon, a conference held there. I wonder how I can ensure to get discount for FreeBSDCon ($125/night) via web reservation. Thanks for your help. --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
When I did a remote geographic disk based mirroring product a few years ago, I just had an ioctl that said that this disk was special for a while. Then the open routine would fail. This flag was cleared in the close routine (and by the companion ioctl). I did allow users to open the device w/o read and write to get status on the device, but that was it until the rebuilding process was complete. Granted, this was the control device for the mirroring driver... But that worked fairly well. I only needed to do this in recovery situations for a few hundred disk I/Os, so the average user would likely have never noticed. Oh, this was on Solaris, but the concepts are exactly the same for FreeBSD. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: I contacted radisson hotels for FreeBSDCon reservation with special discount, to get the following email - they don't know about special rate code "FreeBSDCon". What is the exact code for reservation? Do any of you have success experience with it? Use 'Walnut Creek CDROM' they know what that means. It would smart of FreeBSDcon to make sure before they put "just mention FreeBSD" that the hotel actually will respond to that. It took me 10 minutes of explanation for the reservation clerk to finally figure out just what the hell I was talking about. WC CDROM did the trick. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SPARC?
On Mon, 23 Aug 1999, Dennis wrote: I heard a rumor that freebsd runs on a sparc, but I dont see any backing for that. Is it in the works? dennis It is more correct to say that it passes in and out of the thoughts of people from time to time, with very little code that has actually materialised. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
At 9:59 AM +0100 8/23/99, Cillian Sharkey wrote: * if there are no passwd/group diffs found, don't print anything out (not even the header). Same for setuid etc. diffs. I have one change to one of the scripts, the one checking for mail spool files. I changed it to recognize the spool file that the script itself is sending, and not keep warning me about something that it itself was doing. * For the 'df' status, only report filesystems that are over a certain capacity (95% or only xxMb left etc..) I think this would need to be "knob-ized". I will ignore these status reports for some time, and then some event comes up where I am interested in reviewing all of them. If a partition goes over 90%, for instance, I will want to know if it's been growing 1% a week for months, or if all the growth happened last night. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
Garance A Drosihn wrote: I think this would need to be "knob-ized". I will ignore these status reports for some time, and then some event comes up where I am interested in reviewing all of them. If a partition goes over 90%, for instance, I will want to know if it's been growing 1% a week for months, or if all the growth happened last night. Something inbetween might be nice. Nightly be able to display only "changed" items, but have full output on the weekly/monthly runs. Jim -- James E. HousleyPGP: 1024/03983B4D System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 Pager: [EMAIL PROTECTED] 7C F0 B5 BF 27 8B 92 FE "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
At 1:11 AM +0900 8/24/99, Daniel C. Sobral wrote: Daniel O'Connor wrote: I think its a good idea, and hey if people object it can always be an option like - option NO_MANDATORY_LOCKING Phew, that was tough. When introducing security holes, the default should be the hole not being present. Ie, reverse that option. If we spent our time thinking about the implementation, maybe we could come up with something which meets the needs of the people who would use mandatory locking, without introducing any kind of security hole. Let's list what the potential security risks are, and see if we can't think our way around them. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
Bill Fumerola wrote... On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: I contacted radisson hotels for FreeBSDCon reservation with special discount, to get the following email - they don't know about special rate code "FreeBSDCon". What is the exact code for reservation? Do any of you have success experience with it? Use 'Walnut Creek CDROM' they know what that means. It would smart of FreeBSDcon to make sure before they put "just mention FreeBSD" that the hotel actually will respond to that. It took me 10 minutes of explanation for the reservation clerk to finally figure out just what the hell I was talking about. WC CDROM did the trick. I had a similar experience, and you're right, mentioning Walnut Creek seemed to work. Unfortunately, you have to call the local hotel to get reservations, and not the toll-free national hotline. The hotel in Berkeley doesn't have a toll free number, so after sitting on hold with the Berkeley Radission for 15 minutes, burning long distance money, I decided to call the national reservations hotline. They told me I had to call the reservations desk at the Berkeley Radission. Another thing I found out is that the reservations desk there is only open Monday through Friday (not sure about the hours). If you call on a weekend, the front desk people can't make the reservation because it's for a conference. Anyway, I was finally able to make the reservation, by calling on a Monday morning... (didn't have to sit on hold too long, thankfully) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
On Mon, 23 Aug 1999, Kenneth D. Merry wrote: Unfortunately, you have to call the local hotel to get reservations, and not the toll-free national hotline. The hotel in Berkeley doesn't have a toll free number, so after sitting on hold with the Berkeley Radission for 15 minutes, burning long distance money, I decided to call the national reservations hotline. They told me I had to call the reservations desk at the Berkeley Radission. I called the 800 number in the FreeBSDcon brochure, it worked fine. Regretfully, I now won't be attending the conference so now I get to find out just how well they cancel reservations. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
Bill Fumerola wrote... On Mon, 23 Aug 1999, Kenneth D. Merry wrote: Unfortunately, you have to call the local hotel to get reservations, and not the toll-free national hotline. The hotel in Berkeley doesn't have a toll free number, so after sitting on hold with the Berkeley Radission for 15 minutes, burning long distance money, I decided to call the national reservations hotline. They told me I had to call the reservations desk at the Berkeley Radission. I called the 800 number in the FreeBSDcon brochure, it worked fine. They should stick that magic 800 number on the FreeBSDcon web site. Regretfully, I now won't be attending the conference so now I get to find out just how well they cancel reservations. Bummer. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: L440GX+ Server Board
Hi list, About the problem bellow, I bought a 2940 Adaptec Ultra2 Wide SCSI controller, but it didn't work too. I wrote to Justin T. Gibbs and he told me that my problem is not SCSI. Somebody has any idea? []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays "ok" again. I recompiled the kernel with "maxusers 128", but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On 23-Aug-99 Cillian Sharkey wrote: yes perhaps an /etc/periodic.conf would be good, to control the level of verbosity and/or set options for each script ? I've hacked periodic here so that the scripts can be turned off with knobs in a periodic.conf file. This would simplify customizing new installitions - one no longer needs to add exit 0 to scripts. Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: L440GX+ Server Board
Has anyone else gotten this server board to work? I've got an N440BX and have been considering getting the L440GX+ but haven't because I don't know if it works.. Kevin On Mon, 23 Aug 1999, Luiz Morte da Costa Junior wrote: Hi list, About the problem bellow, I bought a 2940 Adaptec Ultra2 Wide SCSI controller, but it didn't work too. I wrote to Justin T. Gibbs and he told me that my problem is not SCSI. Somebody has any idea? []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays "ok" again. I recompiled the kernel with "maxusers 128", but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil 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: Mandatory locking?
At 10:12 PM +0200 8/23/99, Mark Murray wrote: Folk are all skirting around a very convenient (and necessary) loophole; in cases where there _is_ mandatory locking, there is always some meta-user which is allowed to violate this. If we include non-unix systems in the discussion, this isn't always true. In the mainframe OS that I used to work on, there was no meta-user who could just ignore locks set by other processes. The super-user could find which process had a file locked, and kill that process (thus removing the lock). Or the super-user could run a program which modified the in-core locking table so the file did not appear to be locked. However, ordinary programs run by that super user did not have any magic power to ignore mandatory locks set by some other process. It is true that nobody is running that mainframe OS anymore... :-) I'm just saying we COULD (and maybe "should"?) implement this such that even root has to honor mandatory locks. Root (or some thing) would have a way to get around or cancel the mandatory lock, but "standard" programs run by root should not bypass the mandatory locking. (IMO) --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, 23 Aug 1999, Garance A Drosihn wrote: At 11:29 AM -0400 8/23/99, Chuck Robey wrote: I think mandatory locking should exist, but only be available to root. If a program needs this, it must run with root privs, so that ordinary users cannot wedge the machine, but (as usual) root can shoot himself in the foot (traditional Unix methodology). I don't think we want to force people into running their program as root just to get mandatory locking. Perhaps there would be a program with root-privs which would have to be run to register files which will have mandatory locking, but the program which manipulates those files shouldn't have to run as root. There are other ways to access the rights, such as sockets, pipes, etc. You write a server which runs as root and can lock, and the clients, running with clients privs, make service requests. If you restrict locking to root, then even if someone manages to wedge his machine, he's not doing anything that an idiot with root and the rm command can't do much worse. I think Garrett's fears are of folks unwittingly wedging machines too easily, so real mandatory locking ought to be restricted to programs that root can set up. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
Chuck Robey wrote: I think Garrett's fears are of folks unwittingly wedging machines too easily, so real mandatory locking ought to be restricted to programs that root can set up. And those fears are well-founded, but your proposed solution just creates another set of bottlenecks. Making mandatory locks available to any process and giving root an avenue by which it can revoke the locks, by whatever means, is a better solution. SIGKILL seems like an ideal candidate to me. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 15:28:01 -0400, Garance A Drosihn wrote: At 3:28 PM +0930 8/23/99, Greg Lehey wrote: I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of... For what it's worth, I also like the idea of mandatory locking. It's important to think through some of the implementation details, but I would also like to see some way to specify mandatory locking in at least some situations. I'm not particularly thrilled with the idea of keying it off chmod bits, though. That seems like a recipe for disaster. Remember where that came from: System V. I don't like it either, but if we're going to do it, we should offer this method (maybe as an option) for compatibility reasons. Anyway, I am also puzzled as to why there would be much objection to the option of mandatory locking. My initial systems-programming experience was on a mainframe OS where mandatory locking was the NORM, and you had to go out of your way to avoid locking. It seemed to work quite well in my experience. Ditto in all points. I think that the people who are objecting are seeing potential rather than real problems. Obviously you don't apply mandatory locking to every file, but there are many cases where it makes sense. On Monday, 23 August 1999 at 17:47:46 -0400, Garance A Drosihn wrote: At 10:12 PM +0200 8/23/99, Mark Murray wrote: Folk are all skirting around a very convenient (and necessary) loophole; in cases where there _is_ mandatory locking, there is always some meta-user which is allowed to violate this. If we include non-unix systems in the discussion, this isn't always true. In the mainframe OS that I used to work on, there was no meta-user who could just ignore locks set by other processes. The super-user could find which process had a file locked, and kill that process (thus removing the lock). Or the super-user could run a program which modified the in-core locking table so the file did not appear to be locked. Exactly. The reason why mandatory locking isn't a problem is because it's possible to kill processes holding the locks. It should be possible to find out who these processes are. However, ordinary programs run by that super user did not have any magic power to ignore mandatory locks set by some other process. It is true that nobody is running that mainframe OS anymore... :-) They're running similar OSs. Tandem's NSK, for example, has always had mandatory locking. I'm just saying we COULD (and maybe "should"?) implement this such that even root has to honor mandatory locks. Root (or some thing) would have a way to get around or cancel the mandatory lock, but "standard" programs run by root should not bypass the mandatory locking. (IMO) I don't think that it should be necessary for root to have this override. The tendency in the last few years has been to lessen root's authority, not increase it. And remember, just because people on this forum haven't had much experience with mandatory locking doesn't mean that others don't: it's been in use for years, and people *don't* have (many) problems with deadlocks. The real issue here is that (mandatory) locking is standard on just about every operating system nowadays. I'd guess that even Microsoft has it. The lack of support on FreeBSD doesn't improve the system. I've done some searching on the web, and came up with a lot of stuff. http://homer.njit.edu:8000/cis332/flock.html and http://miller.cs.wm.edu/lxr3.linux/http/source/Documentation/mandatory.txt seem to be the most interesting. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setting up -STABLE for hack contest
Geoff Rehmet writes: Also have a look at ports/security/nmap, and go to www.insecure.org. Hm, just did that. While reading up on nmap, I saw this: "TCP Initial Window -- This simply involves checking the window size on returned packets. [...] In their "completely rewritten" TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used by OpenBSD and FreeBSD." Gee, I wonder how that happened... Dave -- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide [EMAIL PROTECTED] http://www.nordicdms.com -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
Hi Greg, hackers list, I don't want to express an opinion about the need or otherwise for mandatory locking, but I would appreciate a teensy clarification of the problem domain: On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Are you suggesting that random user processes have to do all of this every time that they access a vinum drive? I thought that access was mediated by a driver or server process. Isn't this process in a position to ensure the integrity of the transaction without any help from locking mechanisms? If some major maintenance utility needs to run on the raw device, during which time the state is inconsistent as far as user processes are concerned, isn't it sufficient to remove their read priveliges? Sorry if these are dumb questions. I have had no experience at file system or data-base applications, but I do want to learn as much about them as I can. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 03:28:01PM -0400, Garance A Drosihn wrote: Anyway, I am also puzzled as to why there would be much objection to the option of mandatory locking. My initial systems-programming If you provide mandatory locks that can be broken, then many of the objections may disappear... Providing mandatory locks that can be broken would be rather useful, I think. Mandatory locks that cannot be broken are another matter... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote: In process-space, this is the kernel. In file-space, this should be root. Processes that require mandatory locking must revoke superuser before attempting locks. I don't like restricting the breaking of mandatory locks to the superuser. It could be restricted to specific users (say file owner + root)... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
On Mon, Aug 23, 1999 at 12:28:32AM -0700, Christopher Seiwald wrote: The alteration that I've tried and tested is to have the isort bail back to qsort if it does more than N swaps. I put N at 1024, which Perhaps a ratio: #comparisons : # swaps If the ratio gets too high, then bail. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setting up -STABLE for hack contest
On Mon, 23 Aug 1999 17:44:47 -0700 "Dave Walton" [EMAIL PROTECTED] wrote: Hm, just did that. While reading up on nmap, I saw this: "TCP Initial Window -- This simply involves checking the window size on returned packets. [...] In their "completely rewritten" TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used by OpenBSD and FreeBSD." Gee, I wonder how that happened... It's not "interesting" at all. Lots of systems default to a 16k receive window. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
The thing about well-intentioned but incorrect locking code is that it will appear to work fine, until it trips over the one code path where it forgets to lock some file that it should have locked. And even then, the code will "work" just fine, until multiple processes are accessing that file at the same time. I think it is appropriate for an operating system to provide an option such that *it* (the system) will enforce the locking, and not have to trust that all code-paths in all programs will do the right thing WRT advisory locking. Dunno about that.. if you're using advisory locking, you know to say "lock the file, then read the data, do your calculation, write it out, and unlock". This manditory locking sounds like an invitation for disaster. "I don't need to pay attention to the details because the kernel will take care of it for me." Actually, I don't really understand the paradigm. Two processes need to safely update a file, so one of them aquires a mandatory lock, and the other.. uh.. just blocks trying to open the file? How does it know it's not the first one? -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote: Dunno about that.. if you're using advisory locking, you know to say "lock the file, then read the data, do your calculation, write it out, and unlock". This manditory locking sounds like an invitation for disaster. "I don't need to pay attention to the details because the kernel will take care of it for me." Actually, I don't really understand the paradigm. Two processes need to safely update a file, so one of them aquires a mandatory lock, and the other.. uh.. just blocks trying to open the file? How does it know it's not the first one? It means that if user A puts data in (and follows locking procedure correctly) then he doesn't have to worry that user B might not be following correct locking procedure, because user B is mandatorily forced to follow the procedure. There isn't any added sloppiness, just a guarantee that if one user locks a file, no other rogues can get into it while the lock exists. Bleah.. I can't count the number of times I've seen idiotic code like: open file read data close file open file for write write data close file Mandatory locking of the type above doesn't force such a thing to work. Now that I've read the rest of the thread, I see that the meaning may be that certain files are marked such that they can't be opened without locking. That seems extremely dangerous, given all the time that such a thing hasn't been around.. who knows how many scripts and programs will now be vulnerable to hanging forever.. can I lock my maildrop? My web pages? My print spool? -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, 23 Aug 1999, Christopher Masto wrote: Bleah.. I can't count the number of times I've seen idiotic code like: open file read data close file open file for write write data close file Mandatory locking of the type above doesn't force such a thing to work. What has that code you show above got to do with mandatory locking? You completely missed the explicit locking calls that you have to make, to get and release the locks. If you don't make the call, and you have madatory locking, then your process will sleep until someone else releases the lock; if you only have advisory locking, and you use the miscreant code you show, then indeed things will go awry. ---+--- Chuck Robey| Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 23:11:30 -0400, Christopher Masto wrote: On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote: Dunno about that.. if you're using advisory locking, you know to say "lock the file, then read the data, do your calculation, write it out, and unlock". This manditory locking sounds like an invitation for disaster. "I don't need to pay attention to the details because the kernel will take care of it for me." Actually, I don't really understand the paradigm. Two processes need to safely update a file, so one of them aquires a mandatory lock, and the other.. uh.. just blocks trying to open the file? How does it know it's not the first one? It means that if user A puts data in (and follows locking procedure correctly) then he doesn't have to worry that user B might not be following correct locking procedure, because user B is mandatorily forced to follow the procedure. There isn't any added sloppiness, just a guarantee that if one user locks a file, no other rogues can get into it while the lock exists. Bleah.. I can't count the number of times I've seen idiotic code like: open file read data close file open file for write write data close file Mandatory locking of the type above doesn't force such a thing to work. I don't see a consistency problem in the code above, it's just inefficient. Now that I've read the rest of the thread, I see that the meaning may be that certain files are marked such that they can't be opened without locking. No, I think you're confusing opening and locking. It's something like this: User 1 User 2 open file open file lock file read file (blocks) diddle file unlock file read completes In fact, fcntl locking is range locking, not file locking, so as long as the two users don't want to access the same part of the file. That seems extremely dangerous, given all the time that such a thing hasn't been around.. I've been using it for 22 years now. who knows how many scripts and programs will now be vulnerable to hanging forever.. Why? There is a danger, of course, that user 1 will lock the file and not unlock it. That's a badly written program, so you stop it. End of hang. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote: On Mon, 23 Aug 1999, Christopher Masto wrote: Bleah.. I can't count the number of times I've seen idiotic code like: open file read data close file open file for write write data close file Mandatory locking of the type above doesn't force such a thing to work. What has that code you show above got to do with mandatory locking? You completely missed the explicit locking calls that you have to make, to get and release the locks. If you don't make the call, and you have madatory locking, then your process will sleep until someone else releases the lock; Exactly. You said that mandatory locking means that user A's correct use of locking means that user B doesn't have to be careful. That's not the case, since A can step in between B's read and write. A's mandatory lock doesn't help. I don't see the use for it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tue, Aug 24, 1999 at 12:52:10PM +0930, Greg Lehey wrote: No, I think you're confusing opening and locking. It's something like this: User 1User 2 open file open file lock file read file (blocks) diddle file unlock file read completes How about a little timing difference? User 1 User 2 open file read file open file lock file (blocks?) close file lock returnsopen file (blocks) diddle file unlock file scribble over User 1's changes What I'm getting at is that if User 2 has to do something special anyway, it might as well be using advisory locking. That seems extremely dangerous, given all the time that such a thing hasn't been around.. I've been using it for 22 years now. who knows how many scripts and programs will now be vulnerable to hanging forever.. Why? There is a danger, of course, that user 1 will lock the file and not unlock it. That's a badly written program, so you stop it. End of hang. That's not what I meant. It hasn't been on FreeBSD, so FreeBSD is not designed to deal with it. I mentioned a couple of examples.. if I lock a bunch of files in my web space, does apache get a bunch of children stuck forever? Who knows what might get tripped up? -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 23:27:27 -0400, Christopher Masto wrote: On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote: On Mon, 23 Aug 1999, Christopher Masto wrote: Bleah.. I can't count the number of times I've seen idiotic code like: open file read data close file open file for write write data close file Mandatory locking of the type above doesn't force such a thing to work. What has that code you show above got to do with mandatory locking? You completely missed the explicit locking calls that you have to make, to get and release the locks. If you don't make the call, and you have madatory locking, then your process will sleep until someone else releases the lock; Exactly. You said that mandatory locking means that user A's correct use of locking means that user B doesn't have to be careful. That's not the case, since A can step in between B's read and write. B doesn't have to be careful about messing up A's transaction, like he doesn't need to be careful not to overwrite A's address space. If he wants his own transactions protected, he needs to do something about that. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
network performance vs. linux on small transfers
I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Much thanks in advance, Wayne Cuddy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: network performance vs. linux on small transfers
I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Are you setting the TCP_NODELAY socket option on the SMTP connection? If not, then please do that and let me know if it fixes the problem or not. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: several messages
Thank you for your reply. At what point should I set this socket option? I am assuming right after the socket is allocated?? I will try this and post my results tomorrow night. For those wondering, I cannot just execute Sendmail directly, there are many architectural reasons for this design... Thanks again, Wayne On Tue, 24 Aug 1999, Daniel O'Connor wrote: Date: Tue, 24 Aug 1999 13:41:37 +0930 (CST) From: Daniel O'Connor [EMAIL PROTECTED] To: Wayne Cuddy [EMAIL PROTECTED] Cc: FreeBSD Hackers List [EMAIL PROTECTED] Subject: RE: network performance vs. linux on small transfers On 24-Aug-99 Wayne Cuddy wrote: I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Tried setsockopt and TCP_NODELAY? From netinet/tcp.h #define TCP_NODELAY 0x01/* don't delay send to coalesce packets */ --- 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 On Mon, 23 Aug 1999, David Greenman wrote: Date: Mon, 23 Aug 1999 21:17:06 -0700 From: David Greenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: FreeBSD Hackers List [EMAIL PROTECTED] Subject: Re: network performance vs. linux on small transfers I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Are you setting the TCP_NODELAY socket option on the SMTP connection? If not, then please do that and let me know if it fixes the problem or not. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: network performance vs. linux on small transfers
On Tue, 24 Aug 1999, Wayne Cuddy wrote: Date: Tue, 24 Aug 1999 00:38:21 -0400 (EDT) From: Wayne Cuddy [EMAIL PROTECTED] To: FreeBSD Hackers List [EMAIL PROTECTED] Subject: network performance vs. linux on small transfers I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. do you really have to deliver the messages sequentially ? SMTP conversation is rather slow, especially for small messages. you may want to try to deliver them simultaneously, by creating multiple SMTP conversations. you may also try other MTA such as qmail, postfix, etc. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. how about profiling your program / system ? try to find where it spends most time. it could be forking, disk I/O, SMTP conversation, etc. I strongly suspect that it's SMTP conversation, but can't really sure before you mesure it. -k- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: several messages
As an (former) implementer of fast TCP/IP peer-peer communications, I'd have to agree with Dave, and say that it is definitely the TCP_NODELAY option. You'll find that disabling the TCP-ACK delay will greatly increase your performace. The reason that it is so "slow" is because the TCP/IP stack is trying to wait to send a TCP "ACK" piggy-backed with data that you MAY BE SENDING SOON. So it waits for 1/5 of a second for you to send SOMETHING, then shrugs its shoulders when you don't, and sends the TCP ACK without further delay. This is a "standard" that most TCP/IP stacks implement. You'll find the same "problem" under Windows. In fact, when I was doing the peer-peer communications, from a Unix to a Windows '95 machine (and NT), the TCP_NODELAY was not yet implemented in the WinSock library. The workaround was to send garbage back as fast as possible, so the ACK could piggy-back itself on SOMETHING. You may want to set the transmit and recieve low-water marks as well. Look at the man page for "setsockopt". -Mark Taylor NetMAX Developer [EMAIL PROTECTED] http://www.netmax.com/ Wayne Cuddy wrote: Thank you for your reply. At what point should I set this socket option? I am assuming right after the socket is allocated?? I will try this and post my results tomorrow night. For those wondering, I cannot just execute Sendmail directly, there are many architectural reasons for this design... Thanks again, Wayne On Tue, 24 Aug 1999, Daniel O'Connor wrote: Date: Tue, 24 Aug 1999 13:41:37 +0930 (CST) From: Daniel O'Connor [EMAIL PROTECTED] To: Wayne Cuddy [EMAIL PROTECTED] Cc: FreeBSD Hackers List [EMAIL PROTECTED] Subject: RE: network performance vs. linux on small transfers On 24-Aug-99 Wayne Cuddy wrote: I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Tried setsockopt and TCP_NODELAY? From netinet/tcp.h #define TCP_NODELAY 0x01/* don't delay send to coalesce packets */ --- 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 On Mon, 23 Aug 1999, David Greenman wrote: Date: Mon, 23 Aug 1999 21:17:06 -0700 From: David Greenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: FreeBSD Hackers List [EMAIL PROTECTED] Subject: Re: network performance vs. linux on small transfers I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Are you setting the TCP_NODELAY socket option on the SMTP connection? If not, then please do that and let me know if it fixes the problem or not. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. 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: network performance vs. linux on small transfers
On Tue, 24 Aug 1999, kadal wrote: On Tue, 24 Aug 1999, Wayne Cuddy wrote: Date: Tue, 24 Aug 1999 00:38:21 -0400 (EDT) From: Wayne Cuddy [EMAIL PROTECTED] To: FreeBSD Hackers List [EMAIL PROTECTED] Subject: network performance vs. linux on small transfers I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. do you really have to deliver the messages sequentially ? SMTP conversation is rather slow, especially for small messages. you may want to try to deliver them simultaneously, by creating multiple SMTP conversations. you may also try other MTA such as qmail, postfix, etc. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. how about profiling your program / system ? try to find where it spends most time. it could be forking, disk I/O, SMTP conversation, etc. I strongly suspect that it's SMTP conversation, but can't really sure before you mesure it. Wild guess, the creation of spool files syncronously is killing performance you may give freebsd a signifigant boost by either: mount -o async -u /var (spool partition) or enabling softupdates, check out: /usr/src/sys/contrib/softupdates/README.softupdates. please tell me how it goes. good luck, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: several messages
Wayne Cuddy scribbled this message on Aug 24: Thank you for your reply. At what point should I set this socket option? I am assuming right after the socket is allocated?? I will try this and post my results tomorrow night. For those wondering, I cannot just execute Sendmail directly, there are many architectural reasons for this design... sounds like you need to fork upon recieption of the message and send the message in a child process... don't forget to reap your children though... you don't want a lot of zombies laying around... if you do this, you really don't need to set the TCP_NODELAY option.. but you might want to anyways... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: network performance vs. linux on small transfers
According to kadal: you may also try other MTA such as qmail, postfix, etc. Postfix (and qmail I think) support SMTP PIPELINING, which greatly reduce latency. It is very interesting for small messages. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Unable to locate function body: ip_nat_init()
Hi, I am going through the networking code for the stable release. In the file ip_input.c there is a call to a function ip_nat_init() in the function ip_init(). However I have been unable to locate the code for this function (ip_nat_init()). Could somebody please tell me in which file is this function defined? Also in the file ip_input.c a function pointer ip_nat_ptr is dereferenced in the function ip_input.c However I could not locate where this function pointer is being initialized. Could somebody please tell me where this pointer is being initialized? Thanks in advance. Ratnakarprasad Tiwari
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Marc Ramirez wrote: Oh! I was under the impression that it just didn't work, even with correct perms, but I use FreeBSD. Lemme try it... Can't mount, even with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris 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: cvs commit: src/bin/test test.c
On Wed, Aug 18, 1999, Sheldon Hearn wrote: green 1999/08/17 17:18:53 PDT Modified files: bin/test test.c Log: The new test(1) did not use access() correctly. I don't know why, since supposedly it's ksh-derived, and it's not broken in pdksh. I've added a test for test running as root: if testing for -x, the file must be mode 0111 to get "success", rather than just existant. Reviewed by: chris What were you actually trying to fix, here? I didn't see any discussion of this on hackers, current or bugs, nor in response to my initial commit message. He was "fixing" (though, as Bruce pointed out, it wasn't a valid fix) test -x. Apparently, access(2) will return 'success' on access(file, X_OK) if called by a program run by root. The patch partly solves the problem, but the euid-vs-ruid problem remains. -- |Chris Costello [EMAIL PROTECTED] |Disc space, the final frontier! `-- 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: BSD XFS Port BSD VFS Rewrite
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: : : Matt doesn't represent the FreeBSD project, and even if he rewrites : the VFS subsystem so he can understand it, his rewrite would face : considerable resistance on its way into FreeBSD. I don't think : there is reason to rewrite it, but there certainly are areas : that need fixing. : :You are misinformed as far as I know.. From discussions I saw, th :main architect of a VFS rewrite would be Kirk, and Matt would be acting as :Kirk's right-hand-man. Yes, this is correct. Kirk is going to be the main architect. I have been heavily involved and will continue to be. :The use of the "vfs_default" to make unimplemented VOP's : : I beg to differ. The only difference is that we pass through : multiple layers before we hit the bottom of the stack. There is :... :Well I believe that Kirk considers them misguided too, but he stated that :he wasn't going to remove them without serious thought about the alternatives. The vfs op callout layering has not been on the radar screen. There are much too many other more serious problems. I really doubt that any changes will be made to this piece any time in the next year or even two, if at all. The main items on the radar screen are related to buffer management (struct buf stuff. For example, preventing VM blockages due to pages being wired by write I/O's), VFS locking and reference count issues (for example, namei lookups, blockages in the pager and syncer due to vnode locks held by blocked processes, etc...), and interactions between VFS and VM (for example: moving away from VOP_READ/VOP_WRITE and moving more towards a getpages/putpages model). None of the items have been set in stone yet. We're waiting for Kirk to get back from vacation and get back into the groove. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
yp_mkdb
I am in the process of upgrading a NIS master using version 2.1.0 to version 3.2. The 'Makefile' has been customized to include automount maps for our IRIX machines as was the 'Makefile' in the old NIS Master. The problem is that for some reason the program 'yp_mkdb' in 3.2 is much more picky. It does not tolerate lines as such: nschein -rw,intrnister:/usr/home: It complains when it encounters the '-' if removed it works fine. Also it has problems with the '+' and absence of a whitespace following the first ASCI string in the following line: +auto.home What has changed in yp_mkdb? Is there a way to escape certain symbols? I have already tried \ '' "". Or is there another way to make the database file? Nathaniel Schein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Gigabit ethernet support?
Any supported cards in 3.2.x? The HCL pages don't list any:( Thanks, --- David 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: BSD XFS Port BSD VFS Rewrite
2. Advisory locks are hung off private backing objects. I'm not sure. The struct lock * is only used by layered filesystems, so they can keep track both of the underlying vnode lock, and if needed their own vnode lock. For advisory locks, would we want to keep track both of locks on our layer and the layer below? Don't we want either one or the other? i.e. layers bypass to the one below, or deal with it all themselves. I think you want the lock on the intermediate layer: basically, on every vnode that has data associated with it that is unique to a layer. Let's not forget, also, that you can expose a layer into the namespace in one place, and expose it covered under another layer, at another. If you locked down to the backing object, then the only issue you would be left with is one or more intermediate backing objects. Right. That exported struct lock * makes locking down to the lowest-level file easy - you just feed it to the lock manager, and you're locking the same lock the lowest level fs uses. You then lock all vnodes stacked over this one at the same time. Otherwise, you just call VOP_LOCK below and then lock yourself. I think this defeats the purpose of the stacking architecture; I think that if you look at an unadulterated NULLFS, you'll see what I mean. Intermediate FS's should not trap VOP's that are not applicable to them. One of the purposes of doing a VOP_LOCK on intermediate vnodes that aren't backing objects is to deal with the global vnode pool management. I'd really like FS's to own their vnode pools, but even without that, you don't need the locking, since you only need to flush data on vnodes that are backing objects. If we look at a stack of FS's with intermediate exposure into the namespace, then it's clear that the issue is really only applicable to objects that act as a backing store: -- -- FS Exposed in hierarchyBacking object -- -- top yes no intermediate_1 no no intermediate_2 no yes intermediate_3 yes no bottom no yes -- -- So when we lock "top", we only lock in intermediate_2 and in bottom. Then we attempt to lock in intermediate_3, but it fails: not because there is a lock on the vnode in intermediate_3, but because there is a lock in bottom. It's unnecessary to lock the vnodes in the intermediate path, or even at the exposure level, unless they are vnodes that have an associated backing store. The need to lock in intermediate_2 exists because it is a translation layer or a namespace escape. It deals with compression, or it deals with file-as-a-directory folding, or it deals with file-hiding (perhaps for a quoata file), etc.. If it didn't, it wouldn't need backing store (and therefore wouldn't need to be locked). For a layer with an intermediate backing object, I'm prepared to declare it "special", and proxy the operation down to any inferior backing object (e.g. a union FS that adds files from two FS's together, rather than just directoriy entry lists). I think such layers are the exception, not the rule. Actually isn't the only problem when you have vnode fan-in (union FS)? i.e. a plain compressing layer should not introduce vnode locking problems. If it's a block compression layer, it will. Also a translation layer; consider a pure Unicode system that wants to remotely mount an FS from a legacy system. To do this, it needs to expand the pages from the legacy system [only it can, since the legacy system doesn't know about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock on a file on such a system. To propogate the lock, you have to do an arithmetic conversion at the translation layer. This gets worse if the lower end FS is exposed in the namespace as well. You could make the same arguments for other types of translation or namespace escapes. I think that export policies are the realm of /etc/exports. The problem with each FS implementing its own policy, is that this is another place that copyinstr() gets called, when it shouldn't. Well, my thought was that, like with current code, most every fs would just call vfs_export() when it's presented an export operation. But by retaining the option of having the fs do its own thing, we can support different export semantics if desired. I think this bears down on whether the NFS server VFS consumer is allowed access to the VFS stack at the particular intermediate layer. I think this is really an administrative policy decision, and not an option for the VFS. I think it would be bad if a given VFS could refuse to participate in a
yp_mkdb
I am in the process of upgrading a NIS master using version 2.1.0 to version 3.2. The 'Makefile' has been customized to include automount maps for our IRIX machines as was the 'Makefile' in the old NIS Master. The problem is that for some reason the program 'yp_mkdb' in 3.2 is much more picky. It does not tolerate lines as such: nschein -rw,intrnister:/usr/home: It complains when it encounters the '-' if removed it works fine. Also it has problems with the '+' and absence of a whitespace following the first ASCI string in the following line: +auto.home What has changed in yp_mkdb? Is there a way to escape certain symbols? I have already tried \ '' "". Or is there another way to make the database file? Nathaniel Schein 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: BSD XFS Port BSD VFS Rewrite
Matt doesn't represent the FreeBSD project, and even if he rewrites the VFS subsystem so he can understand it, his rewrite would face considerable resistance on its way into FreeBSD. I don't think there is reason to rewrite it, but there certainly are areas that need fixing. You are misinformed as far as I know.. From discussions I saw, th main architect of a VFS rewrite would be Kirk, and Matt would be acting as Kirk's right-hand-man. Which discussions are these? Are they archived somewhere? Nate 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: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Brian C. Grayson wrote: On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: A group of us at Apple are trying to figure out how to handle situations where a filesystem with "foreign" user ID's are present. Have you looked at mount_umap(8)? I (naively) think it would solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill 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: Mandatory locking?
On Sunday, 22 August 1999 at 22:04:38 -0700, Matthew Dillon wrote: Somehow you need to get a lock. You mean have one program make a fcntl call that causes other programs to return an error or block if they try to open that file while the first program holds an open descriptor? Correct. I suppose it's worth discussing what the default should be. Should they get EAGAIN or block? Obviously you'd want a way of specifying which, but there would have to be a default for non-lock-aware programs. I think I'd go for blocking; it's less error prone. I dunno, it sounds pretty icky to me. I would redesign whatever you are doing that requires mandatory locks to use advisory locks instead. It can be as simple as a wrapper around whatever program your users are running that is causing whatever the problem is. I'm accessing a file that any program might want to open. Redesigning everything isn't an option. On Monday, 23 August 1999 at 7:29:32 +0200, Poul-Henning Kamp wrote: In message 19990823122719.g83...@freebie.lemis.com, Greg Lehey writes: On Sunday, 22 August 1999 at 22:52:33 -0400, Garrett Wollman wrote: On Mon, 23 Aug 1999 12:09:50 +0930, Greg Lehey g...@lemis.com said: That's a strange thing to say. Should we do away with locks in the kernel too? Of course not. Locks in the kernel are actually necessary. So what's unspeakably evil about ensuring that user processes don't tread on each other's feet? In my specific case, I need to make a Vinum volume inaccessible while rebuilding the parity stripes. How would you ensure that? A user process is doing the rebuilding. Then you give that user-process a magic ioctl to do it with. That sounds like a kludge to me. Why should it be made unavailable ? So that certain multiple accesses can be done atomically. I thought the idea of RAID-5 was that this wasn't needed ? No, the idea of RAID-5 is that you can tolerate failures. I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
According to Brian F. Feldman: -O lets you do explicit inlining, and -O2 enables -finline-functions. You meant -O3 of course. -O3Optimize yet more. This turns on everything -O2 does, along with also turning on -finline-func- tions. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
On 23-Aug-99 Greg Lehey wrote: I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. I think its a good idea, and hey if people object it can always be an option like - option NO_MANDATORY_LOCKING Phew, that was tough. --- 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 pgpUZ9kdbjmC7.pgp Description: PGP signature
Re: Mandatory locking?
In message 19990823152849.h83...@freebie.lemis.com, Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. All you need to do to recover you index then is to have an ioctl which will read one sector at a time, mark the buffer dirty write it out again. I have seen sources for two well-respected RAID-5 products which do it this way. I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 8:47:34 +0200, Poul-Henning Kamp wrote: In message 19990823152849.h83...@freebie.lemis.com, Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. My real question was more like OK, I have a situation coming up in which I need to be able to lock out other processes. What tools are available for it. I don't know yet whether what I end up with can be solved by this method, but it's nice to know what tools you have. You certainly wouldn't want to lock out access to the entire device during this time. I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ls(1) options affecting -l long format
Hi folks, Chris Costello recently committed (and then backed out at my request) a change to ls(1) that made -n (numeric ID's instead of names) imply -l (long format). The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' to mean When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one. As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Archie's mod to qsort:
| - if (swap_cnt == 0) { /* Switch to insertion sort */
| + if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
As Akira Wada points out, this eliminates the benefit of the optimization
in the first place, which is to let isort take over if the data is largely
sorted in the first place.
Akira Wada's alternative mod:
| + pl = (char *)a; pn = (char *)a + (n - 1) * es;
| + while (pl pn cmp(pl, pl + es) = 0) pl += es;
| + if (pl = pn) return;
This is a little more comprehensive, but does throw in an extra pass
of comparisons, which (I'm sure) someone would complain about.
The alteration that I've tried and tested is to have the isort bail
back to qsort if it does more than N swaps. I put N at 1024, which
worked for my data :).This is almost guaranteed to do no more work
than the current logic, because it it only gives up on the isort when
it has evidence that the isort is doing too much work.
Christopher
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
In message 19990823162813.i83...@freebie.lemis.com, Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. I still don't see the need for mandatory locking, or locking out user access in general... I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Well, maybe you were more lucky, I've had my share of troubles, and I think the very concept stinks... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999, Sheldon Hearn wrote: The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. Yes, I agree that that's what it means. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' This makes no sense. to mean When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one. The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) The above is not flexibility; it's just different behavior. We need to follow their specifications so things can be portable. So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Brian Fundakowski Feldman / Any sufficiently advanced bug is\ gr...@freebsd.org | indistinguishable from a feature. | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 9:47:40 +0200, Poul-Henning Kamp wrote: In message 19990823162813.i83...@freebie.lemis.com, Greg Lehey writes: Why should it be made unavailable ? So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks = your index are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. I still don't see the need for mandatory locking, or locking out user access in general... I'll try to explain, using a different example, since I'm not quite sure where my rebuild stuff is going yet. To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Consider what happens if a second request which refers the same parity data comes in during this business: 1. Read the old data into a temporary buffer. 1a. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 2a. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 3a. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 4a. XOR the result with the data which is to be written. 5. Write the data block. 5a. Write the data block. 6. Write the parity block. 6a. Write the parity block. The parity data read at (2a) will be wrong. It won't know of the data block to be written at (6). If the volume becomes degraded, it may no longer know about the first transaction. For this, we don't need fcntl locking: it would be too slow, and it's all done in the kernel anyway. In userland, we'd use a different example: I make a number of financial transactions over the Internet. In each case, the system checks my account balance, transfers the money and deducts it from my account: 1. Check balance. 2. Perform transfer. 3. Write updated balance back. Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus forget one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the same thing: file protection belongs in the kernel. I'm a little surprised that there's any objection to the concept of mandatory locking. Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Well, maybe you were more lucky, I've had my share of troubles, and I think the very concept stinks... You and Garrett. I've never heard this from *anybody* else. The general opinion I've heard until now was that the lack of mandatory locking was a significant weakness in BSD. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
IPsec/IPv6
Bah, so FreeBSD will be InSecureBSD ? Well, so long as the ITAR bear stands around making grizzly noises at people, it seems. I wouldn't count on that. As far as I can tell, what's holding KAME integration up is the fact that they're not done merging with INRIA yet. A news about NRL/INRIA/KAME merging (unified-ipv6). unified-ipv6 project has been in big trouble with manpower, design differences. Recently situations changed for all of us so here's the decision we have made. NRL decided to concentrates on IPsec (because in US not much interest in IPv6 than IPsec - people in US are lucky about IPv4 address space, it seems). INRIA will be doing future researches on top of KAME code. KAME agreed to add some knobs that helps INRIA to do their experiment. So, it is planned that KAME will have an alias: unified-ipv6. KAME team is trying to ship KAME/OpenBSD and KAME/BSDI4 during this month or next month (September). KAME September 30th STABLE kit will officially have unified-ipv6 alias on it. It is now okay to merge KAME code into FreeBSD, I believe. If you do not feel ready, I'll be visiting FreeBSDCon so let's talk about it there (but will cause 2 month delay from now). The biggest problem is how to keep mutiple repositories in sync. KAME (= unified-ipv6) code shares most of IPv6 code among *BSD platforms. If FreeBSD repository is modified after import, and that conflicts with content in KAME repository, we can't merge that back in. So I would like to suggest FreeBSD project to refrain from changing IPv6 part too much, for certain amount of time (*). Rather, please send diffs to KAME. Once that happens, I'm more than happy to continue to lean on Justice Maryln Patel's decision on crypto as free speach in the S.F. Bay Area region. We've already talked to our lawyer, he said it looked legit to him, and so we've been shipping crypto on our CDs for over a year now. I even announced it back then, to almost no audience reaction whatsoever. It seems that people like to get more excited about the prospect of something being closed than it being opened up. :) It now happened, so please contact Mr. Patel:-) KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). itojun (*) As a side note: actually, KAME and unified-ipv6 has been experiencing big trouble sharing IPv6 code among *BSD, due to FreeBSD's variable renaming like ifa_list (ifa_link on others) or time_second (why FreeBSD couldn't reuse time.tv_sec to hold this? I don't get it). I'd like propose to fix those back to more standard ones (ifa_link or time.tv_sec) for portability among *BSD. If you are okay, those changes will come with FreeBSD/KAME integration. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
On 23-Aug-99 Greg Lehey wrote: I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. I think its a good idea, and hey if people object it can always be an option like - option NO_MANDATORY_LOCKING Not quite - developers have to deal with the mess that it would cause - Matt for example says: :Ugh. Yuch. No, nothing to do with permission bits, not for something :this convoluted! Are you saying that he should just enable an option and forget about it when he tweaks something horrible in NFS that only a handfull of others understand ? :-I -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: setting up -STABLE for hack contest
Evren Yurtesen writes : it is possible to detect operating systems from their behaviours of replying to packets. see the program queso from ports/packages. but anyway you can change the login prompt from /etc/gettytab file Also have a look at ports/security/nmap, and go to www.insecure.org. In order to stop someone guessing your OS, you will need to make changes to your TCP implementation. These include, changing the way in which TCP initial sequence numbers are calculated, as well as changing behaviour of TCP wrt the handling of certain unexpected TCP segments on open or closed ports - e.g. what happens when someone sends a surprise FIN segment to a closed port. Geoff. -- Geoff Rehmet, The Internet Solution geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
proposed change for /etc/periodic/* scripts
Hi, Currently, the reports that are generated and emailed to root are fine in what they do. however, a lot of the time there is actaully nothing of interest in these reports if nothing has gone wrong on the system etc. Basically I only want to know about the changes that have happened. This would be useful in cutting down the size of these emails esp. when you are receiving them from multiple fbsd servers.. :P example: * if there are no passwd/group diffs found, don't print anything out (not even the header). Same for setuid etc. diffs. * For the 'df' status, only report filesystems that are over a certain capacity (95% or only xxMb left etc..) and the same for all the other tests..basically if there's nothing to report don't print anything (not even the header) otherwise print the header and the results.. Ideas / Comments / Suggestions ? - Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, 23 Aug 1999 09:59:29 +0100, Cillian Sharkey wrote: Ideas / Comments / Suggestions ? Diffs ? :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: On TCP sequence numbers
[ Geoff Rehmet ] Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Just a funny (?) aside - while playing about with nmap here a while back, a colleague accidentally discovered that our Digital (or Compaq Tru64, if you want to be perverse) Unix 4.0E box was using a constant (?!) sequence number. Cian -- What think ye of Christ? Whose son is he? Will you, like Peter, boldly say: Who? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
Ideas / Comments / Suggestions ? ^ ^^^ Well ? Diffs ? I haven't actually done any work on this (yet) but I might see what I can hack together.. ;) Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 01:00:05 MST, Brian F. Feldman wrote: The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. That's good enough for me. :-) If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. I'm not to phased with backward compatibility on this one, since I think it's always been understood that the output of ls isn't really intended for scripts (that's what find and test are for). The OpenGroup spec actually makes a point of that in its manpage. Thanks for your input. Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, 23 Aug 1999 10:18:40 +0100, Cillian Sharkey wrote: I haven't actually done any work on this (yet) but I might see what I can hack together.. The reason I suggest that you provide diffs first is that it's difficult to comment on your proposal without seeing _how_ and to _what_ extent you want to change things. Diffs will remedy that. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon 1999-08-23 (09:59), Cillian Sharkey wrote: and the same for all the other tests..basically if there's nothing to report don't print anything (not even the header) otherwise print the header and the results.. Ideas / Comments / Suggestions ? I have changes to this effect active on a box not here, I'll see if it is up-to-date enough to generate patches, and send them on to help you, if necessary. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
Currently, the reports that are generated and emailed to root are fine in what they do. however, a lot of the time there is actaully nothing of interest in these reports if nothing has gone wrong on the system etc. Basically I only want to know about the changes that have happened. This would be useful in cutting down the size of these emails esp. when you are receiving them from multiple fbsd servers.. :P Make sure they always generate some output so that a message does get mailed. On more than once occasion I noticed that one of my boxes keeled over or the network broke when I didn't get my expected daily output from that machine. example: * if there are no passwd/group diffs found, don't print anything out (not even the header). Same for setuid etc. diffs. * For the 'df' status, only report filesystems that are over a certain capacity (95% or only xxMb left etc..) You might want to make the df part an rc.conf (or maybe a new periodic.conf) knob. I have couple of machines that basically do nothing all week long and the disk space should always be pretty much constant. If I notice that the disk space usage changed a lot, then I should go check that machine out, because something went haywire. and the same for all the other tests..basically if there's nothing to report don't print anything (not even the header) otherwise print the header and the results.. I've had a bad experience with this in the past. One of our adminstrators didn't like wading through all of the periodic output and changed the scripts to do what you want. Sometime down the line I figured out that he had broken something in the script early on and 90% of it never got executed, and since no output meant everything was fineyou get the point. Again, maybe an rc.conf knob that tells the periodic scripts to be quiet. I've got a couple of machines here that I would might use that on, but not on my main servers. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Slightly BSD related problem
Hi, I've got a problem with my machine at home which is slightly BSD related (cause ONLY BSD could handle the problem:))). So: At this moment, I've got a 2.2.7-FreeBSD and an NT installed on my PC. There are two hard drives in the PC, the primary master IDE drive is a 2.5 Quantum drive, it is set to LBA in the BIOS. The second one is secondary slave, an old 405M Quantum drive. The (AWARD) BIOS can't recognize right geometry of the latter one via 'IDE HD autodetection'. The first HD has got the NT and BSD installed and a 'booteasy' in the root sector installed from the FreeBSD distribution. Although booteasy can recognize the type of the partitions on the first HD, it cannot boot them. The only way to boot up my PC is to insert the BSD install CD in the CD drive and when the BSD boot prompt appears, type: 1:wd(0,a)kernel. After that, the BSD already installed on the hard drive would start up, recognizes is all the parts of the PC and everything would run fine as they should. This situation happened tho weeks ago. Before, my PC work quite well, w/o problems. I would like to know, where does BSD know from the geometry of the disks when BIOS can't get them. Thanks in advance Sebestyén Zoltán sz...@netvisor.huI'm believing that the Holy Spirit is gonna allow the hand, and the foot, and MAKE INSTALL NOT WARthe mouth, just to begin to speak, and to minister, and to heal coordinated by the head. I use UNIX because reboots are for hardware upgrades. Kick me! Whip me!! Make me develop on AIX!!! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
Make sure they always generate some output so that a message does get mailed. On more than once occasion I noticed that one of my boxes keeled over or the network broke when I didn't get my expected daily output from that machine. My proposal would only *cut down* on all the white space, unnecessary lines etc. in the output, there would of course always be a report mailed out (with network interface status, uptime info etc..) As long as I get the reports and see no errors, i know all the various housekeeping chores the periodic scripts do have actually been done, if not I'll see an error msg in the report.. You might want to make the df part an rc.conf (or maybe a new periodic.conf) knob. I have couple of machines that basically do nothing all week long and the disk space should always be pretty much constant. If I notice that the disk space usage changed a lot, then I should go check that machine out, because something went haywire. yes perhaps an /etc/periodic.conf would be good, to control the level of verbosity and/or set options for each script ? I've had a bad experience with this in the past. One of our adminstrators didn't like wading through all of the periodic output and changed the scripts to do what you want. Sometime down the line I figured out that he had broken something in the script early on and 90% of it never got executed, and since no output meant everything was fineyou get the point. Yes, that's always a danger.. :P to sum up : for scripts that do chores, if they ran successfully don't bother telling me. if they failed, tell me. for status reports (df, netstat, ruptime..) tell me for checks (passwd diff etc.) tell me IF there's something to report - Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 11:36:00 +0200, Sheldon Hearn wrote: If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. Eeek, I've been confused. Our -o and the OpenGroup spec's -o are completely different. :-) The -n option will imply -l, but -o will be a no-op unless at least one of -n and -l is specified. Manpage changes will be included in the deal. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon, Aug 23, 1999 at 09:59:29AM +0100, Cillian Sharkey wrote: * if there are no passwd/group diffs found, don't print anything out (not even the header). Same for setuid etc. diffs. * For the 'df' status, only report filesystems that are over a certain capacity (95% or only xxMb left etc..) This may not be a good idea. I often check daily reports to see if a disk has suddenly filled or had been gradually filling over a long period of time - you wouldn't be able to get this info if you print stuff selectively. For anyone who reads daily reports regurally it doesn't take long to get used to the usual look of a report of moderate length (2screens?) and to notice if something is out of place. You don't have to read every single word (and if you need to come back to it all the info should be there). David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
On 23-Aug-99 Brian Somers wrote: I think its a good idea, and hey if people object it can always be an option like - option NO_MANDATORY_LOCKING Not quite - developers have to deal with the mess that it would cause - Matt for example says: Well, I think it would be a useful option, so adding the ability to disable it would possibly keep the people that hate it happy :) --- 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
