Re: soft updates and qmail (RE: qmail IO problems)
Andre Oppermann wrote: Since when does `atomic' equal `synchronous' ? Because otherwise it would not be atomically, would it? I am loath to add to this bloated thread, but... atomic and durable aren't the same thing. This is why A.C.I.D. semantics contain both A D. The atomicity guarantee concerning rename is meant to suggest that there be no time when the filesystem view contains either both links or no link to the file you are renaming. The operation will either succeed or fail as an atomic unit with regard to the system's view of the filesystem. This DOES NOT mean that the data will be on stable store. -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
I was about to write up a group of suggestions that include the notion that you could use kqueue to watch the directory's vnode, you could use Erez's stackable file system code to pass all file creates through a filter, use lpd's spooling mechanism to treat the incoming directory like a print queue, use a standard issue cron job, etc, etc. But... At present the files are created through procmail like this: |/usr/bin/perl $HOME/process_cvs_mail.pl ~/msgs/$FILE ...this fragment tells me that you are in control of the process of creating these files. This makes the whole problem much easier to solve and side steps the issue of watching the directory altogether. In addition to the suggestions above, you could also: You could set up the message processing daemon to listen on a named pipe and send the messages there from the process_cvs_mail script. You could handle queue entry with the process_cvs_mail script and queue exit with your daemon; signal the daemon from the script when new work appears in the queue. This would mirror a threaded work queue approach that blocks on a a conditional variable until work comes into the queue. -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Re: New netgraph features?]
John Smith wrote: loose something, if we, say, create special node for 'netgraph tunneling' (so that it may ot may not I would like to see netgraph used to facilitate shared coherent interface support for FreeBSD (very valuable for clustering). Does anyone have an opinion on the difficulty of hacking something like this into the tunnel node code? -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
"Jacques A. Vidrine" wrote: I doubt that you could measure any difference between if (foo) free(foo); and free(foo); Nevertheless, I tend to write it that way at times -- maybe because it seems so natural to me to ask `do I need to free this thing?' -- and that gets translated directly to code. I find that I still use the: if( foo ) free( foo ); ...syntax a large part of the time. It's a habit developed before you could trust the free() implementation on every platform to conform to sanity. It also prevents me from getting into the habit of using syntax that will get me into trouble when programming in embedded environments kernels. In any case, this style doesn't raise the "what the hell?" flag the way a number of other things do. Jack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pipe
"G. Adam Stanislav" wrote: On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote: No, you didn't. You probably read the first line, then your eyes glazed over and you skipped to the bottom. Dudes. This is a programmer from another environment coming to us to learn more about our programming paradigm. Don't blast him for not picking it up fast enough. Give the guy some help. Geez. -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repeatable STL core with -pthread
James FitzGibbon wrote:
The program will core after about 10 seconds, every time.
It would appear that there is an issue with some low-level allocator in the
STL as shipped in 4.x.
Dude. The STL implementation that ships with g++ isn't thread safe.
In fact, if you read the STL portion of the C++ specification, you will
notice that threads are not mentioned at all. The only guarantees made
by the STL are that operations will complete within certain performance
guidelines.
As a safety tip, the string implementation in the g++ implementation
isn't thread safe either. It uses a shared buffer scheme ("char*
string-rep") to reduce memory consumption improve performance. This
is in opposition to "deep copy" style libraries, like the SGI STL, that
work in threaded environments.
Because of the way the C++ standard is written, commercial STL
implementations, such as the Rogue Wave library that comes with the Sun
C++ compiler, suffer from the same threading problems.
--
Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED]
Integratus, Inc. | http://www.integratus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Virtual interaces and tunneling stuff over SSH
[EMAIL PROTECTED] wrote: use port forwarding of ssh to establish a ppp connection. I have something written up on how I did it, it's been awhile, so YMMV: http://dorothy.hentschel.net/ppp_over_ssh.html Or, better yet, use IPSec. -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Oz-ISP] FreeBSD and the forces of darkness. Real religious wars! (fwd)
Parag Patel wrote: Can your graphics guy whip up a couple of Daemons in the style of Southpark (esp. Cartman) and the PowerPuff Girls? Just a couple of things I want to see... Oh... My... God... I would pay to print the t-shirts. -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
Ronald G Minnich wrote: So, I repeat: easily done, not acceptable to freebsd core. If you can easily do it, why aren't you? I had thought someone was actively working on this (because it is SO obviously useful to have fast reboots in an HA environment). It's kind of a shame. Sure is. What are we going to do about it? -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
Coleman Kane wrote: I really don't think that stupidity is the issue, there are plenty of devices which you use very discretely which may only need support every once in awhile. It might be nice to start running on modules regularly. It would also be useful to be able to update your device driver while running freebsd, without needing to reboot. Another note on the loadable/unloadable driver tip: SCSI, USB, and Firewire are all adaptable bus architectures that allow you to add and remove devices from your system at will. There are dozens of situations in which you might wish to hot swap devices. If I, for sake of argument, wanted to remove one of my SlowAssDrive2000 disks from my server and replace it with a NiftyFastDrive2001, why should I have to reboot? Why shouldn't the server automatically unload the driver if the bus protocol gives me registration/deregistration information? I guess I don't see the harm in a ref count system for device drivers on hot swappable bus architectures. Does anyone want to see a tiny FreeBSD kernel that pulls in drivers via an /etc/system style configuration file? Let's stop attacking these ideas as foreign evil and start looking for any interesting notions that we can use. Thanks, -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Histrionic Ranting...
Dear Hackers, In all of the discussion that has poured forth in the aftermath of the press release concerning the merging of Walnut Creek and BSDI, no one seems to have stated this simple fact: this merger brings an amazing team (back) together to work on the collective product that will be the future of both free and commercial BSD; Karels, McKusick, Leffler, Torek, etc. To my mind there has only been one other group in the last thirty years (Kernigan, Ritchie, Pike, Bach, etc) that has done as much for the state of modern computing. When you add in the value brought to the project by people like Greenman, Hubbard, Fagen, Lehey, and the rest of the FreeBSD team, and then layer on top of that the tremendous resources of the contributing user base, well... it makes me want to send off my resume to see if I can do anything to help--not scream bloody murder. Yours, -- Jack Rusher, Senior Software Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: downed IP addresses/redundancy
Alfred Perlstein wrote: Does anyone particularly like/hate this idea? Just wanted to share, and possibly get better suggestions. I usually do that like this: HostA - Address1, Alias1 HostB - Address2 ...where Host A and Host B talk to each other through the pair of "real" addresses, while the service network uses the address referred to above as "alias 1". When Host A goes away, Host B does an ifconfig if alias Alias1 to bring up the service net address on Host B. We just completed a full n-way local and wide area application level failover product that runs under FreeBSD 3.x. It does a lot of this for you, including maintaining heartbeat links, starting and stopping services, and the rest of the stuff you would expect from such a beast. Oh, and it runs cross platform; you can fail an Apache (or whatever) instance between Solaris, Linux and FreeBSD. Go check out the press release at the URL below. Yours, -- Jack Rusher, Chief Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc.| http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: downed IP addresses/redundancy
Alfred Perlstein wrote: You have multiple customers on two boxes, each customer gets 2 IP address and you lolad balance between the two. Ah! I see your difficulty. I was thinking about availability; you were thinking about load balancing. Some customers may wish to run thier own sql servers, they should only bind to the IP address on each machine that they own. The customer can't fail over properly because even when the alias for the box that dies comes up, thier daemon won't get requests on the added IP. You have worse trouble than that. If you are running an order/entry database, you don't want the service to fail over to the second machine without remote synchronization of the data. Otherwise, you end up with two databases that have entries that compete for the same serial numbers. No one likes hand merging orders. :-) This also makes it important that the database only ever run on one machine at a time. You would want to start the database on the machine that holds the service net address, right after you do the ifconfig to bring up that address on the secondary's interface. Can you give me some more complete scenarios? I am interested in your problem. Yours, -- Jack Rusher, Chief Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc.| http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
