From dave at difference.com.au Tue Apr 2 22:09:48 2002 From: dave at difference.com.au (David Cake) Date: Wed Oct 27 01:24:42 2004 Subject: [tech] A project idea... In-Reply-To: <1017326445.1316.63.camel@Epoch> References: <1017315186.1315.18.camel@Epoch> <20020328125612.GA1396@sigaba> <1017324006.1315.24.camel@Epoch> <20020328221814.B109589@morwong.ucc.gu.uwa.edu.au> <1017326445.1316.63.camel@Epoch> Message-ID: > >I believe the mac you want to install on is an LC630. YDL doesn't claim to >install on anything before PowerPCs. > >Like I said, I don't know Its not hard. THe number is on the front. The LC630s and the first model G3 do look similar, but are not that much alike on the inside. If its an LC630, for all the reasons people have described, Linux would be a bad idea. >Besides, I'm one of these people that's sick and bloody tired of the >'install linux on everything'. Let's face it. Linux on PPC looks very >much like Linux on x86. What's the fucking point? > >This is a very good question actually, but i think It would be >something different. >I would gladly port NetBSD to it, if I thought it were possible. NetBSD already supports the LC630, I think. It certainly runs on 68k machines. Cheers David From alastair at ucc.gu.uwa.edu.au Sun Apr 7 18:53:34 2002 From: alastair at ucc.gu.uwa.edu.au (Alastair Irvine) Date: Wed Oct 27 01:24:44 2004 Subject: [tech] Machine room power In-Reply-To: <20020319051132.A2687@morwong.ucc.gu.uwa.edu.au> References: <20020319051132.A2687@morwong.ucc.gu.uwa.edu.au> Message-ID: <20020407185334.F169058@morwong.ucc.gu.uwa.edu.au> On Tue, 19 March, 2002 at 05:11:33AM +0800, Simon Fryer wrote: [snip] > I seem to recall machines plugged into it survive some pretty unpleasent > spikes that caused robooting of PC's not plugged into it. AFAIK all that > it needed was to replace the fans and it should have been happy again. Do we still have said PDU or did it get junkified? -- ... A Macintosh is a computer with training wheels you can't remove. _____________________________________________________________________ | | | -=*Alastair Irvine*=- | | C-monkey/Magic-player/RPGer/net-nut alastair@ucc.gu.uwa.edu.au | |_____________________________________________________________________| From david_luyer at pacific.net.au Sun Apr 7 19:21:40 2002 From: david_luyer at pacific.net.au (David Luyer) Date: Wed Oct 27 01:24:44 2004 Subject: [tech] Machine room power In-Reply-To: <20020407185334.F169058@morwong.ucc.gu.uwa.edu.au> Message-ID: <000001c1de26$638923a0$46943ecb@pacific.net.au> Is this the power conditioner / power switch with solid state relays to control each group of ports and a DB9 I'd soldered on as a control port, with a DB9 plug with various pins soldered together as an "everything turned on" hack? It was from the Culler from (my particularly dodgy) memory. I probably still have the pinouts to control it documented somewhere, and it had it's circuit diagram printed inside it, but I wouldn't recommend opening it as you'd break all my soldering :) I think it was all 5V control/240V switch solid state relays on the control side, and some random arrangement of capacitors and inductors in a closed unit for the power conditioner part :) David. -- David Luyer Phone: +61 3 9674 7525 Network Development Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 BYTE http://www.pacific.net.au/ NASDAQ: PCNTF > -----Original Message----- > From: tech-bounces@ucc.gu.uwa.edu.au > [mailto:tech-bounces@ucc.gu.uwa.edu.au] On Behalf Of Alastair Irvine > Sent: Sunday, 7 April 2002 8:54 PM > To: tech@ucc.gu.uwa.edu.au; hwc@ucc.gu.uwa.edu.au > Cc: Simon Fryer > Subject: Re: [tech] Machine room power > > > On Tue, 19 March, 2002 at 05:11:33AM +0800, Simon Fryer wrote: > [snip] > > I seem to recall machines plugged into it survive some > pretty unpleasent > > spikes that caused robooting of PC's not plugged into it. > AFAIK all that > > it needed was to replace the fans and it should have been > happy again. > > Do we still have said PDU or did it get junkified? > > -- > ... A Macintosh is a computer with training wheels you can't remove. > > _____________________________________________________________________ > | > | > | -=*Alastair Irvine*=- > | > | > C-monkey/Magic-player/RPGer/net-nut alastair@ucc.gu.uwa.edu.au | > |_____________________________________________________________ > ________| > > From adrian at ucc.gu.uwa.edu.au Sat Apr 13 19:16:51 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:44 2004 Subject: [tech] air-con Message-ID: <20020413191651.K187497@morwong.ucc.gu.uwa.edu.au> .. the aircon looks like its not cooling. when I popped in a couple of days ago it was iced up so I turned off the cooling part to let it defrost. But now .. she no workie. can someone who has an air-con clue or two please take a look? Adrian From trs80 at ucc.gu.uwa.edu.au Tue Apr 16 10:39:38 2002 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Wed Oct 27 01:24:44 2004 Subject: [tech] Mac stuff Message-ID: I've got appletalk working again, after some beating my head against atalkd.conf. UCC is in the "UWA Guild Cameron-Hall" zone, with the uplink (guild network) being 46520, the machine room being 46526 and the clubroom (including the corridor) being 46522. The full config follows (maily for backup purposes): #eth0 is unconfigured, since there's no macs on it. # big blue room eth1 -phase 2 -net 46520 -addr 46520.0 # clubroom eth2 -seed -phase 2 -net 46522 -addr 46522.0 -zone "UWA Guild Cameron-Hall" # machine room eth3 -seed -phase 2 -net 46526 -addr 46526.0 -zone "UWA Guild Cameron-Hall" atalkd likes to rewrite this, but I'm not sure how well it would recover if the entire network goes down. Also, I've set up the macs in the corridor, with only SSH and Bolo on them. -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Treasurer http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From adrian at ucc.gu.uwa.edu.au Tue Apr 16 10:50:08 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:44 2004 Subject: [tech] Mac stuff In-Reply-To: References: Message-ID: <20020416105008.O187497@morwong.ucc.gu.uwa.edu.au> On Tue, Apr 16, 2002, James Andrewartha wrote: > I've got appletalk working again, after some beating my head against > atalkd.conf. UCC is in the "UWA Guild Cameron-Hall" zone, with the uplink > (guild network) being 46520, the machine room being 46526 and the clubroom > (including the corridor) being 46522. The full config follows (maily for > backup purposes): Well done! adrian From proxy at zdlcomputing.com Wed Apr 17 01:04:22 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:45 2004 Subject: [tech] Mac stuff In-Reply-To: References: Message-ID: <1018976665.19191.46.camel@Epoch> now is the time to do something REALLY fucked up. And reinstall them with debain-m68k. I mean, it's possible on the quadra, and once you've done 1 you can do 50. And for all you non believers out there: http://maclinuxstatus.sourceforge.net/status/ It is possible, VERY possible. I just know James wants to pull more debian stickers from his wallet.... whatever he uses them for during the week I don't know. Alternatively, before I restart this particular flame thread, I'm led to believe there are Net and FreeBSD ports to m68k. After all there only terminals, so surely a purer ssh would be good. or at the very least, install a better ssh client (one that does colours), and perhaps nsca mosaic (if it still exists) to do X forwarding. --davYd On Tue, 2002-04-16 at 10:39, James Andrewartha wrote: I've got appletalk working again, after some beating my head against atalkd.conf. UCC is in the "UWA Guild Cameron-Hall" zone, with the uplink (guild network) being 46520, the machine room being 46526 and the clubroom (including the corridor) being 46522. The full config follows (maily for backup purposes): #eth0 is unconfigured, since there's no macs on it. # big blue room eth1 -phase 2 -net 46520 -addr 46520.0 # clubroom eth2 -seed -phase 2 -net 46522 -addr 46522.0 -zone "UWA Guild Cameron-Hall" # machine room eth3 -seed -phase 2 -net 46526 -addr 46526.0 -zone "UWA Guild Cameron-Hall" atalkd likes to rewrite this, but I'm not sure how well it would recover if the entire network goes down. Also, I've set up the macs in the corridor, with only SSH and Bolo on them. -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Treasurer http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020417/077ecd36/attachment.htm From fryers at ucc.gu.uwa.edu.au Wed Apr 17 04:41:22 2002 From: fryers at ucc.gu.uwa.edu.au (Simon Fryer) Date: Wed Oct 27 01:24:45 2004 Subject: [tech] Mac stuff In-Reply-To: <1018976665.19191.46.camel@Epoch> References: <1018976665.19191.46.camel@Epoch> Message-ID: <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> Bingle > A while ago Riff tapped: > Alternatively, before I restart this particular flame thread, I'm led to > believe there are Net and FreeBSD ports to m68k. There is an OpenBSD post to the M68k platform. As an interesting side note, the packages for the M68k platform work on a number of different hardware platforms. My HP300 uses the same M68k packages as the Macs and a couple of other machines from memory. > After all there only terminals, so surely a purer ssh would be good. > or at the very least, install a better ssh client (one that does > colours), and perhaps nsca mosaic (if it still exists) to do X > forwarding. You clearly have not tried this. Let us just say that well, any graphical web browser generates a lot of X traffic. And well, ssh has to encrypt all this traffic. Running on a slow CPU, the time required to encrypt and decrytpt X traffic is significant. The HP300 I use has a 50MHz 68030 and this gave rather sluggish X performance when using X forwarding and SSH. I don't want to think about this with anything slower. See Ya Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh From proxy at zdlcomputing.com Wed Apr 17 10:46:05 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:46 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> References: <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019011173.19191.68.camel@Epoch> On Wed, 2002-04-17 at 04:41, Simon Fryer wrote: Bingle > A while ago Riff tapped: > Alternatively, before I restart this particular flame thread, I'm led to > believe there are Net and FreeBSD ports to m68k. There is an OpenBSD post to the M68k platform. As an interesting side note, the packages for the M68k platform work on a number of different hardware platforms. My HP300 uses the same M68k packages as the Macs and a couple of other machines from memory. Yeah, I think it works on a pile of chips made by HP, Atari, Amiga etc. (I'm not sure if they all have comparable motorolla chipsets or not). But they are there in the compatability list. > After all there only terminals, so surely a purer ssh would be good. > or at the very least, install a better ssh client (one that does > colours), and perhaps nsca mosaic (if it still exists) to do X > forwarding. You clearly have not tried this. Let us just say that well, any graphical web browser generates a lot of X traffic. And well, ssh has to encrypt all this traffic. Running on a slow CPU, the time required to encrypt and decrytpt X traffic is significant. The HP300 I use has a 50MHz 68030 and this gave rather sluggish X performance when using X forwarding and SSH. I don't want to think about this with anything slower. I wasn't suggesting X over ssh (that WOULD be evil and slow). However a better ssh client then niftyTelnet would be nice. Considering the macs are coloured a telnet/ssh client capable of ansi colours would be very convienient (especially for BitchX ;) Mosaic is a program I came across in the NSCA tools that were originally on my mac when I acquired it. However it is not actually the program I was thinking of, as Mosaic is a primative webbrowser. I'm sure there must be a program able to run X on a mac display (under macOs) similar to winaXe (and other such programs) for putting X on windows. Still it would be fun to port a few of them to a range of distros/platforms. Considering that would give them very nice telnet/ssh facility, and would give them full colour capability, and maintain the usefulness of the terminal for when all the door members deceide they have to go to class. --davYd -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020417/f8eca885/attachment.html From adrian at ucc.gu.uwa.edu.au Wed Apr 17 16:49:46 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:47 2004 Subject: [tech] Mac stuff In-Reply-To: <1019011173.19191.68.camel@Epoch> References: <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> Message-ID: <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> On Wed, Apr 17, 2002, Riff wrote: > Still it would be fun to port a few of them to a range of > distros/platforms. Considering that would give them very nice telnet/ssh > facility, and would give them full colour capability, and maintain the > usefulness of the terminal for when all the door members deceide they > have to go to class. Why not learn how to program stuff for MacOS 7 and write up a decent telnet/ssh client? All the telnet/ssh side of stuff is done - you'll just have to write up a decent terminal emulator. Start with putty - you can get the source for that - and see if its going to be easy or hard to adapt the actual terminal emulation side of things. Running linux on the macs is fun, but they're macs, not PCs. Besides, one should be able to play network bolo now. :) Adrian From adrian at ucc.gu.uwa.edu.au Wed Apr 17 16:52:53 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:47 2004 Subject: [tech] Mac stuff In-Reply-To: <1018976665.19191.46.camel@Epoch> References: <1018976665.19191.46.camel@Epoch> Message-ID: <20020417165253.Q187497@morwong.ucc.gu.uwa.edu.au> On Wed, Apr 17, 2002, Riff wrote: > Alternatively, before I restart this particular flame thread, I'm led to > believe there are Net and FreeBSD ports to m68k. You mean openbsd, right? adrian From proxy at zdlcomputing.com Wed Apr 17 16:58:10 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:47 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417165253.Q187497@morwong.ucc.gu.uwa.edu.au> References: <1018976665.19191.46.camel@Epoch> <20020417165253.Q187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019033892.10254.148.camel@Epoch> On Wed, 2002-04-17 at 16:52, Adrian Chadd wrote: On Wed, Apr 17, 2002, Riff wrote: > Alternatively, before I restart this particular flame thread, I'm led to > believe there are Net and FreeBSD ports to m68k. You mean openbsd, right? Perhaps That was yesterday though, so I can't really remember. Anyway have to fight with this monitor adrian --davYd From acolyte at ucc.gu.uwa.edu.au Wed Apr 17 17:22:24 2002 From: acolyte at ucc.gu.uwa.edu.au (Andrew Bailey) Date: Wed Oct 27 01:24:48 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> References: <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <20020417172224.E241004@morwong.ucc.gu.uwa.edu.au> On Wed, Apr 17, 2002 at 04:49:46PM +0800, Adrian Chadd wrote: > On Wed, Apr 17, 2002, Riff wrote: > > Why not learn how to program stuff for MacOS 7 and write up a > decent telnet/ssh client? > That is a really cool Idea > All the telnet/ssh side of stuff is done - you'll just have to write > up a decent terminal emulator. > > Start with putty - you can get the source for that - and see if > its going to be easy or hard to adapt the actual terminal emulation > side of things. > Hmm , or not. The putty source is wrong(TM). Having just spent most of the day trawling through it, I can say it has issues. Like the fact it uses lots of nice windows calls, the indenting, or rather the lack of it, is not sane, and finally the exit strategies are kinda evil. I really dont think have exit(n) in random functions all through out you code is a good idea(TM). Oh and it suffers from using lots and lots of global variables[0]. So in short its damn ugly:(. Hell just porting the makefile will probably take all day. Lets just say, if you port putty to the MAC, please please please change the coding style. Oh, did I mention, lack of parens with one line if statements, uggh. Andrew -- its the wrong day to talk about putty in my presence:). [0] its a personal peeve of mine if I have to grep the source dir to find out the type of a variable. Like it sucks, pass your vars people please. -- "The hot dog eating contest is not only a beautiful display of athleticism, it is a fundamental way for citizens of all nations to display patriotism," - Wayne Norbitz From proxy at zdlcomputing.com Wed Apr 17 17:38:11 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:49 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> References: <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019036292.19191.197.camel@Epoch> On Wed, 2002-04-17 at 16:49, Adrian Chadd wrote: On Wed, Apr 17, 2002, Riff wrote: > Still it would be fun to port a few of them to a range of > distros/platforms. Considering that would give them very nice telnet/ssh > facility, and would give them full colour capability, and maintain the > usefulness of the terminal for when all the door members deceide they > have to go to class. Why not learn how to program stuff for MacOS 7 and write up a decent telnet/ssh client? As I recall MacOS 7 requires co-operative multitasking (that sounds evil already) All the telnet/ssh side of stuff is done - you'll just have to write up a decent terminal emulator. Start with putty - you can get the source for that - and see if its going to be easy or hard to adapt the actual terminal emulation side of things. Let's add the idea off writing to my, 'think about it' list. Considering my project list is already quite long. (i think this is something to do with my short attension span). I have a few pieces of code to do already, and I want to fuck around with the kernel on my mac a bit (see if I can't get a semi working incantation of the sound and floppy drivers) Of course, if someone else wanted to write one... I'm sure UCC would love to let you use the mac's to develop it ;) Running linux on the macs is fun, but they're macs, not PCs. Besides, one should be able to play network bolo now. :) Yes, Bolo is good, although not really my style. --davYd -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020417/d190cb0c/attachment.htm From john at ucc.gu.uwa.edu.au Wed Apr 17 17:52:54 2002 From: john at ucc.gu.uwa.edu.au (John West McKenna) Date: Wed Oct 27 01:24:50 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417172224.E241004@morwong.ucc.gu.uwa.edu.au> from Andrew Bailey at "Apr 17, 2002 05:22:24 pm" Message-ID: <200204170952.RAA07657@mermaid.ucc.gu.uwa.edu.au> Andrew Bailey writes: >[0] its a personal peeve of mine if I have to grep the source dir to find out >the type of a variable. Like it sucks, pass your vars people please. I fondly remember one project that I inherited. One bug was caused by some code like this: wait_for_esc() { int ch; ch = 0; while (ch!=27) ch=get_key(); return 0; } The bug? Declaring ch as a local. No function had a declared return type. The ones that should have been void just returned 0. get_key() was one of them. It put the key it read into the global ch. John From dave at difference.com.au Wed Apr 17 17:59:35 2002 From: dave at difference.com.au (David Cake) Date: Wed Oct 27 01:24:50 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417172224.E241004@morwong.ucc.gu.uwa.edu.au> References: <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> <20020417172224.E241004@morwong.ucc.gu.uwa.edu.au> Message-ID: If you really have an urge for a better telnet for Mac OS, you could always grab the source of Better Telnet, which is a GPLed descendent of NCSA Telnet, and hack on that. More likely to be productive than starting with putty. http://www.cstone.net/~rbraun/mac/telnet/ Cheers David From david at luyer.net Wed Apr 17 23:06:49 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:24:51 2004 Subject: [tech] Mac stuff In-Reply-To: <200204170952.RAA07657@mermaid.ucc.gu.uwa.edu.au> Message-ID: <05db01c1e621$80187400$46943ecb@pacific.net.au> Note: This message is primarily about Unix programming, so please ignore the subject line :-) Andrew Bailey writes: >[0] its a personal peeve of mine if I have to grep the source dir to find out >the type of a variable. Like it sucks, pass your vars people please. I have no problem passing variables, I just find that I often end up having to pass them via a void * to do it cleanly -- although I guess then you still have a clear typecast back inside the function when you operate that way as you have to case the void * to something to use it. int handler(int fd, void *data); int timeout_handler(void *data); add_handler(&(struct pollfd){0, POLLIN, 0}, handler, data); add_event(&(struct timeval){5, 0}, timeout_handler, data); Yes: 1. squid has changed the way I code, although it's for the better IMO - my code is generally far faster than fork()ing code, and I have taken fork()ing servers and achieved insane speedups by applying the squid model (parameterizing the data, and using a poll() or select() based central loop)... 2. that's not valid C (unless C has become smarter since I last looked :-)) 3. add_handler is required to coalesce different events, and handler has to know what kind of event it's handling The first thing to learn about Unix programming: fork() is good. The second thing to learn about Unix programming: fork() is evil. (and threading vs poll()/select()... both add complexity, you could argue for years about the winner, IMO squid+diskd shows who the winner is: poll()/select() but with an extra process per disk to hand off blocking disk IO to over shared memory ... beats squid asyncio - poll()/select() with threads to hand off disk IO ... and beats all "pure" threading attempts at the same problem that I've seen to date) David. From adrian at ucc.gu.uwa.edu.au Wed Apr 17 23:15:32 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:51 2004 Subject: [tech] Mac stuff In-Reply-To: <05db01c1e621$80187400$46943ecb@pacific.net.au> References: <200204170952.RAA07657@mermaid.ucc.gu.uwa.edu.au> <05db01c1e621$80187400$46943ecb@pacific.net.au> Message-ID: <20020417231532.X187497@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 18, 2002, David Luyer wrote: > Yes: > 1. squid has changed the way I code, although it's for the better IMO > - my > code is generally far faster than fork()ing code, and I have taken > fork()ing servers and achieved insane speedups by applying the > squid > model (parameterizing the data, and using a poll() or select() > based > central loop)... Ditto. > (and threading vs poll()/select()... both add complexity, you could > argue for > years about the winner, IMO squid+diskd shows who the winner is: > poll()/select() > but with an extra process per disk to hand off blocking disk IO to over > shared > memory ... beats squid asyncio - poll()/select() with threads to hand > off disk > IO ... and beats all "pure" threading attempts at the same problem that > I've > seen to date) Well, you've seen my initial attempts at a network IO library. :-) The event-driven single process model for network applications is good. It forces you to actually _think_ about what you're doing and break your ideas up into non-blocking chunks. The trouble is dealing with bits of state when your connection suddenly dies. Squid has tried to do it using a callback/refcounted struct - you lock/unlock structs, and you call free() when you're finished - and everything that uses it does a if (cbdataValid(pointer)) { do stuff } cbdataUnlock(pointer); /* we're finished */ which prevents now-dead structs from actually being read. I think its the wrong solution, but i haven't figure out a better one just yet. Guess I should try implementing a simple http proxy using my library. :) Adrian From david at luyer.net Wed Apr 17 23:39:45 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:24:52 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417231532.X187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <05df01c1e626$19861d50$46943ecb@pacific.net.au> > The trouble is dealing with bits of state when your connection > suddenly dies. Squid has tried to do it using a callback/refcounted > struct - you lock/unlock structs, and you call free() when > you're finished - and everything that uses it does a > > if (cbdataValid(pointer)) [...] > which prevents now-dead structs from actually being read. > > I think its the wrong solution, but i haven't figure out > a better one just yet. Guess I should try implementing a simple > http proxy using my library. :) I don't like any of the callback data refcounting stuff. This is where java and perl just win, but they're not an option for things where I'm looking at kernel-side acceleration... rather than JVM or perl deceleration. Although my RADIUS server is written in perl and beats all C-based ones I've seen simply through algorithms I wouldn't have considered writing in C because it would just have been too hard (of course, I could in theory translate it to C now and get a speedup, but at the moment it's quite nice in perl). My current approach is to attempt to avoid data that has to be free'd - which isn't going to always be possible, but in many cases it is possible and again a speedup to avoid allocating and deallocating memory. eg. my standard event runner contains (standard copyright applies, all code I write, whether for my employer or not, is automatically copyright by my employer, unfortunately -- I get away with contributions to projects already under GPL, fortunately, though): /* The below code is COPYRIGHT (c) 2002 Pacific Internet, * all rights reserved. * * This code may not be compiled in any situation. * * This code is provided to members of this list only as an illustration * of coding style. * * In fact, this is not code. It is free form text which is not meant * to resemble or represent any programming language. And it is * deliberately incomplete, so even if it were code, it would not work. */ #define eprintf(X, ...) \ fprintf(stderr, __FUNCTION__ ": " X "\n" , ## __VA_ARGS__) /* Queue length (entries), size (allocated), position (next event) */ static int eventQueueLen = 0, eventQueueSz = 0, eventQueuePos = -1; static event *eventQueue = NULL; extern void add_event_absolute(struct timeval *t, event_function f, void *data) { int newpos; if (eventQueueLen == eventQueueSz) { eventQueue = realloc(eventQueue, (++eventQueueSz) * sizeof(event)); if (!eventQueue) { eprintf("realloc failed for eventQueue!"); exit(1); } } newpos = ((eventQueuePos++) + eventQueueLen) % eventQueueSz; eventQueue[newpos].t.tv_sec = t->tv_sec; eventQueue[newpos].t.tv_usec = t->tv_usec; eventQueue[newpos].run = f; eventQueue[newpos].data = data; } David. From adrian at ucc.gu.uwa.edu.au Wed Apr 17 23:43:54 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:52 2004 Subject: [tech] Mac stuff In-Reply-To: <05df01c1e626$19861d50$46943ecb@pacific.net.au> References: <20020417231532.X187497@morwong.ucc.gu.uwa.edu.au> <05df01c1e626$19861d50$46943ecb@pacific.net.au> Message-ID: <20020417234354.Y187497@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 18, 2002, David Luyer wrote: > My current approach is to attempt to avoid data that has to be > free'd - which isn't going to always be possible, but in many > cases it is possible and again a speedup to avoid allocating and > deallocating memory. oh, I do this too. the system malloc is just useless for apps like squid that alloc/free lots and lots of fixed-sized entries. The block allocator thats just gone into squid should make this a little nicer (well, a lot nicer - the initial reports are like 20% less cpu usage, about 10-20% memory usage since everything is packed into arrays now) but you should really limit the number of allocator calls you're making in any case. Adrian From david at luyer.net Wed Apr 17 23:56:01 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:24:53 2004 Subject: [tech] Mac stuff In-Reply-To: <05df01c1e626$19861d50$46943ecb@pacific.net.au> Message-ID: <05e201c1e628$5fac4410$46943ecb@pacific.net.au> I wrote: > My current approach is to attempt to avoid data that has to be > free'd - which isn't going to always be possible, but in many > cases it is possible and again a speedup to avoid allocating and > deallocating memory. ...of course this doesn't stop the memory from having been re-used. The way to do this without the code having to know about it is: * the "add handler" handles locking the passed data * the "execute handler" 1. checks the data is valid, else drops the handler and unlocks (once) without executing the handler 2. executes the handler (which may add a new handler and lock) and then unlocks the data (once, ie, leaving it locked if it was multiply locked) * the "remove handler" handles unlocking the data * the data is implicitly valid until invalidated * override "free" with something which will detect locked data and invalidate rather than free * in the unlock code, if the data is invalidated and you're removing the final lock, free it But this also fails. It fails where the data is _not_ malloc()d but _is_ now invalid (because an explicit invalidation is needed, the locking/unlocking/invalidation is not fully transparent). There's always a need for some policy and avoiding these problems can be easy or hard depending on the complexity of the underlying project. David. From ian at mckellar.org Thu Apr 18 01:06:27 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:24:53 2004 Subject: [tech] Mac stuff In-Reply-To: <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> References: <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019063187.25676.15.camel@mouse.danger.com> On Wed, 2002-04-17 at 01:49, Adrian Chadd wrote: > > All the telnet/ssh side of stuff is done - you'll just have to write > up a decent terminal emulator. > > Start with putty - you can get the source for that - and see if > its going to be easy or hard to adapt the actual terminal emulation > side of things. putty source sucks. libssh forever! Its currently dependant on gobject, but that should be portable to MacOS I guess. > > Running linux on the macs is fun, but they're macs, not PCs. > Besides, one should be able to play network bolo now. :) And network Risk! Best Game *Ever* Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020417/0180ac9f/attachment.pgp From bongus at rainbow.lorikeet.id.au Thu Apr 18 10:10:01 2002 From: bongus at rainbow.lorikeet.id.au (Angus Stewart) Date: Wed Oct 27 01:24:54 2004 Subject: [tech] Mac stuff In-Reply-To: <1019063187.25676.15.camel@mouse.danger.com> References: <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <3.0.6.32.20020418101001.0097c640@mail.rainbow.lorikeet.id.au> >putty source sucks. speaking of putty, last night in a fit of boredom, I cat /dev/urandom from a putty terminal... along with the pretty spam, it did things like change the window title, maximised and minimised the window. I wonder what other things are possible. seeya, Angus From adrian at ucc.gu.uwa.edu.au Thu Apr 18 10:14:21 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:24:54 2004 Subject: [tech] Mac stuff In-Reply-To: <3.0.6.32.20020418101001.0097c640@mail.rainbow.lorikeet.id.au> References: <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> <1018976665.19191.46.camel@Epoch> <20020417044122.A246118@morwong.ucc.gu.uwa.edu.au> <1019011173.19191.68.camel@Epoch> <20020417164945.P187497@morwong.ucc.gu.uwa.edu.au> <3.0.6.32.20020418101001.0097c640@mail.rainbow.lorikeet.id.au> Message-ID: <20020418101421.D187497@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 18, 2002, Angus Stewart wrote: > >putty source sucks. > > speaking of putty, last night in a fit of boredom, I cat /dev/urandom from > a putty terminal... along with the pretty spam, it did things like change > the window title, maximised and minimised the window. I wonder what other > things are possible. Lots, when your max/min/titlebar/etc controls are ansi escape sequences. adrian From trs80 at ucc.gu.uwa.edu.au Fri Apr 19 11:29:15 2002 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Wed Oct 27 01:24:54 2004 Subject: [tech] Mac stuff In-Reply-To: Message-ID: On Wed, 17 Apr 2002, David Cake wrote: > If you really have an urge for a better telnet for Mac OS, > you could always grab the source of Better Telnet, which is a GPLed > descendent of NCSA Telnet, and hack on that. More likely to be > productive than starting with putty. > http://www.cstone.net/~rbraun/mac/telnet/ It's Been Done (tm). MacSSH, http://www.macssh.com/, based off Better Telnet, supports ANSI colours and SSH v2 (no v1 support though). And it's now installed on the macs in the corridor. -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Treasurer http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From ian at mckellar.org Sat Apr 20 02:05:51 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:24:55 2004 Subject: [tech] Mac stuff In-Reply-To: References: Message-ID: <1019239551.25660.2925.camel@mouse.danger.com> On Thu, 2002-04-18 at 20:29, James Andrewartha wrote: > On Wed, 17 Apr 2002, David Cake wrote: > > > If you really have an urge for a better telnet for Mac OS, > > you could always grab the source of Better Telnet, which is a GPLed > > descendent of NCSA Telnet, and hack on that. More likely to be > > productive than starting with putty. > > http://www.cstone.net/~rbraun/mac/telnet/ > > It's Been Done (tm). MacSSH, http://www.macssh.com/, based off Better > Telnet, supports ANSI colours and SSH v2 (no v1 support though). And it's > now installed on the macs in the corridor. ssh1 protocol sucks. Has design flaws, isn't documents. sucks. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020419/586b5fd1/attachment.pgp From proxy at zdlcomputing.com Sun Apr 21 02:16:18 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:55 2004 Subject: [tech] A question of File System Message-ID: <1019326588.1437.58.camel@Epoch> Now I stress here that I DON'T WANT TO START A 'my fs is better then yours cause I said so' FLAME WAR. but... The question I have now been asking myself, while having the occasionaly random argument with others; is which file system is better: ext3 or ReiserFS Which do you think has more extensibility?, more usefulness?, more ability to recover from unclean mounts?, which has a higher overhead? and most importantly, which one is more |337? Of course, feel free to suggest a better filesystem still (noone may suggest NTFS or FAT*) --davYd (what a phenomenon, davYd made a somewhat non-spammy post) Madeley From fryers at ucc.gu.uwa.edu.au Sun Apr 21 02:44:08 2002 From: fryers at ucc.gu.uwa.edu.au (Simon Fryer) Date: Wed Oct 27 01:24:55 2004 Subject: [tech] A question of File System In-Reply-To: <1019326588.1437.58.camel@Epoch> References: <1019326588.1437.58.camel@Epoch> Message-ID: <20020421024407.K246118@morwong.ucc.gu.uwa.edu.au> Bingle > A while ago Riff tapped: > Now I stress here that I DON'T WANT TO START A 'my fs is better then > yours cause I said so' FLAME WAR. > > but... > The question I have now been asking myself, while having the occasionaly > random argument with others; is which file system is better: ext3 or > ReiserFS > Which do you think has more extensibility?, more usefulness?, more > ability to recover from unclean mounts?, which has a higher overhead? > and most importantly, which one is more |337? > > Of course, feel free to suggest a better filesystem still (noone may > suggest NTFS or FAT*) UFS works for me but I still use reletivly small hard drives (<10G) The file system seem to be mostly portable between OS's (OpenBSD, Tru64). See Ya Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh From grahame at azale.net Sun Apr 21 17:43:44 2002 From: grahame at azale.net (Grahame Bowland) Date: Wed Oct 27 01:24:55 2004 Subject: [tech] A question of File System In-Reply-To: <1019326588.1437.58.camel@Epoch> References: <1019326588.1437.58.camel@Epoch> Message-ID: <1019382224.3883.2.camel@solitaire> On Sun, 2002-04-21 at 02:16, Riff wrote: > Of course, feel free to suggest a better filesystem still (noone may > suggest NTFS or FAT*) Magnetic beads make for cute non-volatile storage. From proxy at zdlcomputing.com Sun Apr 21 17:51:51 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:55 2004 Subject: [tech] A question of File System In-Reply-To: <1019382224.3883.2.camel@solitaire> References: <1019326588.1437.58.camel@Epoch> <1019382224.3883.2.camel@solitaire> Message-ID: <1019382765.1437.77.camel@Epoch> On Sun, 2002-04-21 at 17:43, Grahame Bowland wrote: Magnetic beads make for cute non-volatile storage. Unfortunately that storage idea is somewhat impractical. Seeing as I'm trying to store mp3s onto it. Though it would be an interesting way to consume the back wall of 'the machine room' (meaning the room which has more then one computer in it) what's that? 40gigs of magnetic beads in a parrallel raid array. In fact, one would need 343,597,383,680 beads in order to store 40gigs. Assuming each bead was a square centimeter (which read/write heads and wires etc) you would require 343598 cubic metres of space to store those beads. Perhaps I should rephrase my hypothetical conversation: what's that small warehouse? mp3 storage facility made from a fuckload of small beads --davYd "the I used python to work out those numbers, any mistakes blame Guido" Madeley From fryers at ucc.gu.uwa.edu.au Sun Apr 21 18:16:11 2002 From: fryers at ucc.gu.uwa.edu.au (Simon Fryer) Date: Wed Oct 27 01:24:56 2004 Subject: [tech] A question of File System In-Reply-To: <1019382765.1437.77.camel@Epoch> References: <1019326588.1437.58.camel@Epoch> <1019382224.3883.2.camel@solitaire> <1019382765.1437.77.camel@Epoch> Message-ID: <20020421181611.L246118@morwong.ucc.gu.uwa.edu.au> Bingle > A while ago Riff tapped: > On Sun, 2002-04-21 at 17:43, Grahame Bowland wrote: > > Magnetic beads make for cute non-volatile storage. > > Unfortunately that storage idea is somewhat impractical. Seeing as I'm > trying to store mp3s onto it. > Though it would be an interesting way to consume the back wall of 'the > machine room' (meaning the room which has more then one computer in it) > > what's that? > 40gigs of magnetic beads in a parrallel raid array. US army used beads for capturing data from nuclear explosions. If it is good enough for their data - I am sure it is good enough for your MP3 collection. > In fact, one would need 343,597,383,680 beads in order to store 40gigs. > Assuming each bead was a square centimeter (which read/write heads and > wires etc) you would require 343598 cubic metres of space to store those > beads. You are using stupidly large beads. Look at the picture of Ben being moved in the UCC. The person (Tony Epton) is holding up a board containing some beads. You really need a magnifying glass to have any hope of seeing the beads. Of course - threading them is a different story. You could also use Nichrome wire delay lines but then again these are voletile memory. > Perhaps I should rephrase my hypothetical conversation: > > what's that small warehouse? > mp3 storage facility made from a fuckload of small beads You mean you don't have one of these already? > --davYd "the I used python to work out those numbers, any mistakes blame But surely the mistakes will be a result of setting the problem up incorrectly. "The trouble with computers is that they do what you tell them, not what you want them to do!" - a frustrated programmer. Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh From david at luyer.net Sun Apr 21 22:16:58 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:24:56 2004 Subject: [tech] A question of File System References: <1019326588.1437.58.camel@Epoch> Message-ID: <014d01c1e93f$3353b5a0$43943ecb@Hyperion> > The question I have now been asking myself, while having the occasionaly > random argument with others; is which file system is better: ext3 or > ReiserFS "Better"? There's no such thing as a best filesystem. Faster for reads? Faster for writes? More robust? More flexible? Able to grow, shrink and migrate on demand? With little pink flowers on top? Good for reads is NTFS (even though you excluded it as a Microsoft fs...) or HFS+ I believe also. Fast for writes... reiserfs if you have small files which grow, ext2 and ext3 are also pretty fast with a small number of files per directory. More robust... I'd expect XFS will do well... something which doesn't need a fsck is good (although early advfs did not have a fsck but was rather bad because if it ever did get corrupt, the recovery utilities would typically lock up the system - fortunately after printing an error about the inode it was trying to fix, allowing you to do a clear inode on next reboot and start over...). On demand growth, shrinking and migration... on Digital Unix (aka OSF/1 or Tru64), advfs rocks for these reasons. It's really, really cool. (PolyCentre advfs that is.) And if you want pretty pink flowers, well, I'm sure Apple will have a filesystem with them soon... in five fruity flavours. > which one is more |337? ext2fs+inum:patch... (I assume my kernel isn't still running on enyo with that Grahame? ;-)) or of course there's other kernel hacks like my /var/spool/mail/x -> /var/spool/.m/x/x ....cuz to be 'leet your fs needs kernel hacks. Or perlfs. That's really 'leet :) > Of course, feel free to suggest a better filesystem still (noone may > suggest NTFS or FAT*) Why - you assume Microsoft couldn't make a good fs? NTFS is actually a decent fs. David. From proxy at zdlcomputing.com Sun Apr 21 22:34:39 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:24:56 2004 Subject: [tech] A question of File System In-Reply-To: <014d01c1e93f$3353b5a0$43943ecb@Hyperion> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> Message-ID: <1019399722.1435.86.camel@Epoch> On Sun, 2002-04-21 at 22:16, David Luyer wrote: Why - you assume Microsoft couldn't make a good fs? NTFS is actually a decent fs. I know NTFS is quite nice. However the other features I wanted from this server, are much easier under linux. And as of yet, the NTFS module driver sucks (along with most the kernel really). Oh well, Reiser has been running quite well so far. We'll wait till it dies. --davYd the Stupid Fresher From grahame at azale.net Mon Apr 22 16:39:07 2002 From: grahame at azale.net (Grahame Bowland) Date: Wed Oct 27 01:24:56 2004 Subject: [tech] A question of File System In-Reply-To: <014d01c1e93f$3353b5a0$43943ecb@Hyperion> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> Message-ID: <1019464748.21502.9.camel@typhaon> On Sun, 2002-04-21 at 22:16, David Luyer wrote: > > which one is more |337? > > ext2fs+inum:patch... (I assume my kernel isn't still running on enyo > with that Grahame? ;-)) Nope, that's gone. :-) > or of course there's other kernel hacks like my > > /var/spool/mail/x -> /var/spool/.m/x/x > > ....cuz to be 'leet your fs needs kernel hacks. One of the first things I ripped out. Replaced the /u/username stuff with reiserfs. Recently to support our webmail (which for some reason couldn't handle TxT even with IMAP) I converted all the TxT boxes back to mbox format (sucky, I know.) We're now pondering Maildirs but aren't totally convinced. Anyone know of a decent (eg. non-UW) IMAP server that does mbox? courier is nice but only does maildirs. > Why - you assume Microsoft couldn't make a good fs? NTFS is actually a > decent fs. I've never been sure if it's journalled or not. NT4 seems to need a fsck but 2k on NTFS doesn't seem to. -- Grahame Bowland From david at luyer.net Mon Apr 22 17:40:25 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:24:56 2004 Subject: [tech] A question of File System In-Reply-To: <1019464748.21502.9.camel@typhaon> Message-ID: <001d01c1e9e1$bada8100$638317d2@pacific.net.au> > Recently to support our webmail (which for some reason > couldn't handle TxT even with IMAP) I converted all the TxT boxes back > to mbox format (sucky, I know.) We're now pondering Maildirs > but aren't totally convinced. Try using UW IMAP with mbx rather than TxT. I use that now for my personal system with very good performance and full features -- doesn't have that "internal folder data" message, either, that only shows up on the less featureful mailbox formats. TxT has some deficiencies, eg, non-sticky unique identifiers. root@typhaon:~# cat /etc/c-client.cf I accept the risk for IMAP toolkit 4.1. set new-folder-format mbx set empty-folder-format mbx set black-box-directory /home/mail-root (that's typhaon.pacific not typhaon.ucs :-)) David. From nick at ucc.gu.uwa.edu.au Mon Apr 22 22:08:02 2002 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Wed Oct 27 01:24:57 2004 Subject: [tech] A question of File System In-Reply-To: <1019464748.21502.9.camel@typhaon> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019464748.21502.9.camel@typhaon> Message-ID: <20020422220802.S231762@morwong.ucc.gu.uwa.edu.au> On Mon, Apr 22, 2002 at 04:39:07PM +0800, Grahame Bowland wrote: > I've never been sure if it's journalled or not. NT4 seems to need a fsck > but 2k on NTFS doesn't seem to. I believe what it has are background fscks, like VMS. It's certainly a practical way to get your machine up and running as fast as possible, but it introduces Hard Problems (tm) about what to do if you do happen to find corrupt data after your applications are up and running and serving it to the outside world, storing it in your databases, etc. Reboot, perhaps? ::-) There's quite a lot of l33t filesystems these days - perhaps ext3 + Daniel Phillip's htree directory indexing patch. Constant time directory operations in measured in the tens of microseconds, million file directories, etc. ext2 is a nice base to build things from, but updates to the core kernel code will be conservative, slow, and massively tested by Ted T'so. ext3 will work in multiple modes - full data journalling, the metadata-only journalling that most journalling FS'es use, an ordered mode that guarantees no stale file blocks after a crash and journalling to a separate disk (eg massively fast NVRAM). Another of Daniel Phillip's plans is the Tux2 filesystem that'll make journalling obsolete and snapshotting easy. Don't think there's been much progress recently. ReiserFS is fine, though I don't really notice any performance difference. I use it on my laptop and it was certainly handy that it's resizable and easily movable - I was able to shuffle it down the disk by 50MB to avoid some bad blocks. Much is planned for it, some of it's even sane. XFS is nice, at least on SGIs. "I'd like 30Mbps guaranteed bandwidth to video spool, please". JFS is also mature and featureful. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From ian at mckellar.org Tue Apr 23 01:29:14 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:24:57 2004 Subject: [tech] A question of File System In-Reply-To: <014d01c1e93f$3353b5a0$43943ecb@Hyperion> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> Message-ID: <1019496554.25676.7279.camel@mouse.danger.com> On Sun, 2002-04-21 at 07:16, David Luyer wrote: > > The question I have now been asking myself, while having the occasionaly > > random argument with others; is which file system is better: ext3 or > > ReiserFS > > Fast for writes... reiserfs if you have small files which grow, ext2 and > ext3 are also pretty fast with a small number of files per directory. > The big advantage of ext3 over reiserfs is that its just ext2 + journalling so its a known quantity. The big disadvantage of ext3 vs reiserfs is that its just ext2 + journalling so its slow. Reiserfs also has (at least it will have) some kind of extended attributes system. I don't know if/when that'll actually be used in userland. Oh, and Oracle have ported their cluster filesystem to linux. Nice journalled filesystem that can be used by multiple machines at once over fiber-channel. Pretty darn cool - and faster than ext2 even though its essentially a network filesystem. > > And if you want pretty pink flowers, well, I'm sure Apple will have > a filesystem with them soon... in five fruity flavours. Dom (ex-Be guy who wrote BFS) is working on a new FS at apple. That should kick ass. BFS had all sorts of really nice things like journalling and indexed file attributes. If Apple let him implement that kind of thing it'll be great. The lack of attributes and the lack of automatic metadata indexing on unix filesystems sucks. If OS X got that it just might make me give up OS 9. While we're talking about journalling its pretty funny when the ops guys here have to drive over to the colo to fsck a machine that went down. *sigh* Solaris and BSD - why would anyone run these in production? ;-) > > > Of course, feel free to suggest a better filesystem still (noone may > > suggest NTFS or FAT*) > > Why - you assume Microsoft couldn't make a good fs? NTFS is actually a > decent fs. Because bigotry is cool and closing ones eyes is the best way to learn new things. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020422/2676b972/attachment.pgp From fryers at ucc.gu.uwa.edu.au Tue Apr 23 02:22:54 2002 From: fryers at ucc.gu.uwa.edu.au (Simon Fryer) Date: Wed Oct 27 01:24:57 2004 Subject: [tech] A question of File System In-Reply-To: <1019496554.25676.7279.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> Message-ID: <20020423022254.T246118@morwong.ucc.gu.uwa.edu.au> Morning > A while ago Ian McKellar tapped: > While we're talking about journalling its pretty funny when the ops guys > here have to drive over to the colo to fsck a machine that went down. > *sigh* Solaris and BSD - why would anyone run these in production? ;-) Because any system (no matter which OS) is only ever as good as the people that admin it, and, to a certain extent, the quality of the hardware. Simon Who, from that remark, should experiance machines going down all the time! -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh From ian at mckellar.org Tue Apr 23 02:47:06 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:24:58 2004 Subject: [tech] A question of File System In-Reply-To: <20020423022254.T246118@morwong.ucc.gu.uwa.edu.au> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <20020423022254.T246118@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019501226.25660.7363.camel@mouse.danger.com> On Mon, 2002-04-22 at 11:22, Simon Fryer wrote: > Morning > > > A while ago Ian McKellar tapped: > > > While we're talking about journalling its pretty funny when the ops guys > > here have to drive over to the colo to fsck a machine that went down. > > *sigh* Solaris and BSD - why would anyone run these in production? ;-) > > Because any system (no matter which OS) is only ever as good as the people > that admin it, and, to a certain extent, the quality of the hardware. Of course, but if you don't give the admins some basic tools like decent filesystems theres not a lot they can do. Solaris also has kooky behaviour on IDE whereby a single read error will bring the machine down rather than marking the block and alerting a sysadmin. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020422/bc5985f4/attachment.pgp From david at luyer.net Tue Apr 23 08:46:43 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:24:58 2004 Subject: [tech] A question of File System References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> Message-ID: <00a601c1ea60$68c474f0$43943ecb@Hyperion> > While we're talking about journalling its pretty funny when the ops guys > here have to drive over to the colo to fsck a machine that went down. > *sigh* Solaris and BSD - why would anyone run these in production? ;-) So they forgot to turn logging on on the ufs partitions on a remote and unreliable Solaris box? It doesn't need to be configured in a way it needs to fsck. If you're using hardware RAID or MD it might not be worth bothering with logging but if your hardware is unreliable or lacking in redundancy, it's just a mount option... David. From ian at mckellar.org Tue Apr 23 08:49:28 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:24:59 2004 Subject: [tech] A question of File System In-Reply-To: <00a601c1ea60$68c474f0$43943ecb@Hyperion> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <00a601c1ea60$68c474f0$43943ecb@Hyperion> Message-ID: <1019522968.29683.7834.camel@mouse.danger.com> On Mon, 2002-04-22 at 17:46, David Luyer wrote: > > While we're talking about journalling its pretty funny when the ops guys > > here have to drive over to the colo to fsck a machine that went down. > > *sigh* Solaris and BSD - why would anyone run these in production? ;-) > > So they forgot to turn logging on on the ufs partitions on a remote > and unreliable Solaris box? Quite possibly... I would really like to have UCCans running the machines here... Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020422/817a255e/attachment.pgp From mustang at ucc.gu.uwa.edu.au Tue Apr 23 12:43:47 2002 From: mustang at ucc.gu.uwa.edu.au (David Manchester) Date: Wed Oct 27 01:24:59 2004 Subject: [tech] A question of File System In-Reply-To: <1019496554.25676.7279.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> Message-ID: <20020423124347.C269591@morwong.ucc.gu.uwa.edu.au> On Mon, Apr 22, 2002 at 10:29:14AM -0700, Ian McKellar wrote: > On Sun, 2002-04-21 at 07:16, David Luyer wrote: > > > The question I have now been asking myself, while having the occasionaly > > > random argument with others; is which file system is better: ext3 or > > > ReiserFS > > > > Fast for writes... reiserfs if you have small files which grow, ext2 and > > ext3 are also pretty fast with a small number of files per directory. > > > The big advantage of ext3 over reiserfs is that its just ext2 + > journalling so its a known quantity. The big disadvantage of ext3 vs > reiserfs is that its just ext2 + journalling so its slow. Reiserfs also > has (at least it will have) some kind of extended attributes system. I > don't know if/when that'll actually be used in userland. > > Oh, and Oracle have ported their cluster filesystem to linux. Nice > journalled filesystem that can be used by multiple machines at once over > fiber-channel. Pretty darn cool - and faster than ext2 even though its > essentially a network filesystem. Its nice to see some parts of Digital Unix will live on... > > And if you want pretty pink flowers, well, I'm sure Apple will have > > a filesystem with them soon... in five fruity flavours. > > Dom (ex-Be guy who wrote BFS) is working on a new FS at apple. That > should kick ass. BFS had all sorts of really nice things like > journalling and indexed file attributes. If Apple let him implement that > kind of thing it'll be great. The lack of attributes and the lack of > automatic metadata indexing on unix filesystems sucks. If OS X got that > it just might make me give up OS 9. > > While we're talking about journalling its pretty funny when the ops guys > here have to drive over to the colo to fsck a machine that went down. > *sigh* Solaris and BSD - why would anyone run these in production? ;-) Its even funnier that they're not running journalled filesystems. WTF aren't they running Solaris 7/8 with UFS/journalling ? > > Why - you assume Microsoft couldn't make a good fs? NTFS is actually a > > decent fs. > > Because bigotry is cool and closing ones eyes is the best way to learn > new things. Got a linux kernel booting on the danger yet? ;) D. -- " I don't get mad.... I get stabby. " - William "Fat Tony" Williams. From mustang at ucc.gu.uwa.edu.au Tue Apr 23 12:44:59 2002 From: mustang at ucc.gu.uwa.edu.au (David Manchester) Date: Wed Oct 27 01:24:59 2004 Subject: [tech] A question of File System In-Reply-To: <1019522968.29683.7834.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <00a601c1ea60$68c474f0$43943ecb@Hyperion> <1019522968.29683.7834.camel@mouse.danger.com> Message-ID: <20020423124459.D269591@morwong.ucc.gu.uwa.edu.au> On Mon, Apr 22, 2002 at 05:49:28PM -0700, Ian McKellar wrote: > On Mon, 2002-04-22 at 17:46, David Luyer wrote: > > > While we're talking about journalling its pretty funny when the ops guys > > > here have to drive over to the colo to fsck a machine that went down. > > > *sigh* Solaris and BSD - why would anyone run these in production? ;-) > > > > So they forgot to turn logging on on the ufs partitions on a remote > > and unreliable Solaris box? > > Quite possibly... I would really like to have UCCans running the > machines here... Would you like me to send them my rates? :) D. -- " I don't get mad.... I get stabby. " - William "Fat Tony" Williams. From fryers at ucc.gu.uwa.edu.au Tue Apr 23 13:01:15 2002 From: fryers at ucc.gu.uwa.edu.au (Simon Fryer) Date: Wed Oct 27 01:25:00 2004 Subject: [tech] A question of File System In-Reply-To: <1019501226.25660.7363.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <20020423022254.T246118@morwong.ucc.gu.uwa.edu.au> <1019501226.25660.7363.camel@mouse.danger.com> Message-ID: <20020423130114.W246118@morwong.ucc.gu.uwa.edu.au> Evening > A while ago Ian McKellar tapped: > On Mon, 2002-04-22 at 11:22, Simon Fryer wrote: > > Morning > > > > > A while ago Ian McKellar tapped: > > > > > While we're talking about journalling its pretty funny when the ops guys > > > here have to drive over to the colo to fsck a machine that went down. > > > *sigh* Solaris and BSD - why would anyone run these in production? ;-) > > > > Because any system (no matter which OS) is only ever as good as the people > > that admin it, and, to a certain extent, the quality of the hardware. > > Of course, but if you don't give the admins some basic tools like decent > filesystems theres not a lot they can do. They say a poor workman blames his tools. However, having the right, high quality tools makes a huge difference, in both time and level of frustration. > Solaris also has kooky > behaviour on IDE whereby a single read error will bring the machine down > rather than marking the block and alerting a sysadmin. Oh, this is bad. And this makes it onto production platforms how exactly??? I am kinda afraid now. Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh From mustang at ucc.gu.uwa.edu.au Tue Apr 23 13:30:19 2002 From: mustang at ucc.gu.uwa.edu.au (David Manchester) Date: Wed Oct 27 01:25:00 2004 Subject: [tech] A question of File System In-Reply-To: <20020423130114.W246118@morwong.ucc.gu.uwa.edu.au> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <20020423022254.T246118@morwong.ucc.gu.uwa.edu.au> <1019501226.25660.7363.camel@mouse.danger.com> <20020423130114.W246118@morwong.ucc.gu.uwa.edu.au> Message-ID: <20020423133019.E269591@morwong.ucc.gu.uwa.edu.au> On Tue, Apr 23, 2002 at 01:01:15PM +0800, Simon Fryer wrote: > > > A while ago Ian McKellar tapped: > > They say a poor workman blames his tools. However, having the right, high > quality tools makes a huge difference, in both time and level of frustration. > > > Solaris also has kooky > > behaviour on IDE whereby a single read error will bring the machine down > > rather than marking the block and alerting a sysadmin. > > Oh, this is bad. And this makes it onto production platforms how exactly??? > I am kinda afraid now. Two things to consider: Ian's remark is a non-sequiteur, in so much as if that behaviour did actually occur, there'd be patches or the hardware would be replaced under warranty if that was where the problem lied. The original Ultra 5s had 4GB Seagates that absolutely sucked dead dromedary balls in terms of performance and happy ATA compliance. IDE sucks: if you care about "production platform" quality, why are you using IDE ? Checking your linux reality, D. -- " I don't get mad.... I get stabby. " - William "Fat Tony" Williams. From nick at ucc.gu.uwa.edu.au Tue Apr 23 14:20:27 2002 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Wed Oct 27 01:25:00 2004 Subject: [tech] A question of File System In-Reply-To: <1019496554.25676.7279.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> Message-ID: <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au> On Mon, Apr 22, 2002 at 10:29:14AM -0700, Ian McKellar wrote: > On Sun, 2002-04-21 at 07:16, David Luyer wrote: > > Fast for writes... reiserfs if you have small files which grow, ext2 and > > ext3 are also pretty fast with a small number of files per directory. > > > The big advantage of ext3 over reiserfs is that its just ext2 + > journalling so its a known quantity. The big disadvantage of ext3 vs > reiserfs is that its just ext2 + journalling so its slow. ext2/ext3's certainly not "slow". Directory operations are slow on large directories. ext3 in full-data-journalling mode is slow at writes, not that you'd typically run it that way. Both cream Solaris UFS and Veritas VxFS, generally speaking. (VxFS certainly has its uses - it can do online resizing for example) ReiserFS is very fast at directory operations on large directories (not as fast as ext3+htree, though ::-) ) and large numbers of small files. > Reiserfs also > has (at least it will have) some kind of extended attributes system. I > don't know if/when that'll actually be used in userland. [...] That's definitely got some promise. It's kinda irritating at the moment because it doesn't have the simple ext2 attributes (immutable bit, etc), but there is or has been a patch to provide that. What it ought to get at some stage is more generic extended attributes, eg somewhere to store ACL's for Samba. The equivalent ext2 support for that ( http://acl.bestbits.at/ ) sounds like it's going to go into the kernel at a leisurely pace. XFS should also be able to do it. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From ian at mckellar.org Wed Apr 24 04:11:48 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:25:01 2004 Subject: [tech] A question of File System In-Reply-To: <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019592708.10707.24.camel@mouse.danger.com> On Mon, 2002-04-22 at 23:20, Nick Bannon wrote: > On Mon, Apr 22, 2002 at 10:29:14AM -0700, Ian McKellar wrote: > > On Sun, 2002-04-21 at 07:16, David Luyer wrote: > > > Fast for writes... reiserfs if you have small files which grow, ext2 and > > > ext3 are also pretty fast with a small number of files per directory. > > > > > The big advantage of ext3 over reiserfs is that its just ext2 + > > journalling so its a known quantity. The big disadvantage of ext3 vs > > reiserfs is that its just ext2 + journalling so its slow. > > ext2/ext3's certainly not "slow". Directory operations are slow on > large directories. ext3 in full-data-journalling mode is slow at > writes, not that you'd typically run it that way. Both cream Solaris > UFS and Veritas VxFS, generally speaking. I'm sure that ext[23] are a lot faster than the commercial alternatives. If it does anything well, free software does seem to produce fast filesystems - take a look at the steps Microsoft is going through to try to stop Samba - putting whacky restrictive anti-GPL clauses in the license to their spec. > > (VxFS certainly has its uses - it can do online resizing for example) That sounds nice. > > ReiserFS is very fast at directory operations on large directories (not > as fast as ext3+htree, though ::-) ) and large numbers of small files. htree? that sounds interesting - its tree-based directories for ext[23]? > > > Reiserfs also > > has (at least it will have) some kind of extended attributes system. I > > don't know if/when that'll actually be used in userland. > [...] > > That's definitely got some promise. It's kinda irritating at the moment > because it doesn't have the simple ext2 attributes (immutable bit, > etc), but there is or has been a patch to provide that. What it ought > to get at some stage is more generic extended attributes, eg somewhere > to store ACL's for Samba. The equivalent ext2 support for that ( > http://acl.bestbits.at/ ) sounds like it's going to go into the kernel > at a leisurely pace. XFS should also be able to do it. So I have to get off my arse and do that metadata abstraction in gnome-vfs I was meant to do two years ago... Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020423/1716c761/attachment.pgp From ian at mckellar.org Wed Apr 24 04:13:50 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:25:02 2004 Subject: [tech] A question of File System In-Reply-To: <20020423133019.E269591@morwong.ucc.gu.uwa.edu.au> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <20020423022254.T246118@morwong.ucc.gu.uwa.edu.au> <1019501226.25660.7363.camel@mouse.danger.com> <20020423130114.W246118@morwong.ucc.gu.uwa.edu.au> <20020423133019.E269591@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019592830.10708.27.camel@mouse.danger.com> On Mon, 2002-04-22 at 22:30, David Manchester wrote: > > IDE sucks: if you care about "production platform" quality, why are > you using IDE ? > We aren't any more. But price was the original motivation. Theres no reason why an IDE disk should be less reliable - the mechanics can be identical. The worst that should happen is possibly lower performance. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020423/38a1fde2/attachment.pgp From dave at difference.com.au Wed Apr 24 04:29:29 2002 From: dave at difference.com.au (David Cake) Date: Wed Oct 27 01:25:02 2004 Subject: [tech] A question of File System In-Reply-To: <1019496554.25676.7279.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> Message-ID: > > >> And if you want pretty pink flowers, well, I'm sure Apple will have >> a filesystem with them soon... in five fruity flavours. > >Dom (ex-Be guy who wrote BFS) is working on a new FS at apple. That >should kick ass. BFS had all sorts of really nice things like >journalling and indexed file attributes. If Apple let him implement that >kind of thing it'll be great. The lack of attributes and the lack of >automatic metadata indexing on unix filesystems sucks. If OS X got that >it just might make me give up OS 9. Its about time. A good filesystem has been an obvious lack of Mac OS X for some time, and there was much rejoicing in some circles when Dom was hired. At 2:20 PM +0800 23/4/02, Nick Bannon wrote: >That's definitely got some promise. It's kinda irritating at the moment >because it doesn't have the simple ext2 attributes (immutable bit, >etc), but there is or has been a patch to provide that. What it ought >to get at some stage is more generic extended attributes, eg somewhere >to store ACL's for Samba. Not to mention handling those wacky Apple file attributes (Type, Creator, etc) properly. One of the particularly tragic things about Mac OS X is that old school NeXT people are always getting all worked up about HFS+s use of file attributes etc, and advocate using Apples fairly shocking UFS implementation instead, seemingly completely unaware of the sort of file features that have made it into modern unices. Cheers David From ian at mckellar.org Wed Apr 24 06:48:10 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:25:03 2004 Subject: [tech] A question of File System In-Reply-To: References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> Message-ID: <1019602090.10708.199.camel@mouse.danger.com> On Tue, 2002-04-23 at 13:29, David Cake wrote: > > > > >> And if you want pretty pink flowers, well, I'm sure Apple will have > >> a filesystem with them soon... in five fruity flavours. > > > >Dom (ex-Be guy who wrote BFS) is working on a new FS at apple. That > >should kick ass. BFS had all sorts of really nice things like > >journalling and indexed file attributes. If Apple let him implement that > >kind of thing it'll be great. The lack of attributes and the lack of > >automatic metadata indexing on unix filesystems sucks. If OS X got that > >it just might make me give up OS 9. > > Its about time. A good filesystem has been an obvious lack of > Mac OS X for some time, and there was much rejoicing in some circles > when Dom was hired. A friend of mine (a long-time NeXTStep user) tried running OS X with UFS. It became clear very quickly that Apple just don't test that :-/ > > At 2:20 PM +0800 23/4/02, Nick Bannon wrote: > >That's definitely got some promise. It's kinda irritating at the moment > >because it doesn't have the simple ext2 attributes (immutable bit, > >etc), but there is or has been a patch to provide that. What it ought > >to get at some stage is more generic extended attributes, eg somewhere > >to store ACL's for Samba. > > Not to mention handling those wacky Apple file attributes > (Type, Creator, etc) properly. > One of the particularly tragic things about Mac OS X is that > old school NeXT people are always getting all worked up about HFS+s > use of file attributes etc, and advocate using Apples fairly shocking > UFS implementation instead, seemingly completely unaware of the sort > of file features that have made it into modern unices. Yeah, some of my friends at Apple are frustrated by a lot of that. Some of the NeXT people don't want to have inode monitoring (like linux's dnotify/imon/fam, freebsd's kqueue, irix's imon/fam, BeOS had it, WinNT has it...). I think my housemate (who works on the OS X display server) is just gonna hack it into Darwin :) A couple of my friend who work on the Finder were at Be, one (Pavel) was the guy who did most of the work on the Tracker (their file manager) which exploited extended attributes extensively. Once they get that the Finder might kick ass. Unfortunately Apple seems to move very slowly with technology (based on hearing things from people who work there and having to wait years to see it ship). Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020423/0ead2f48/attachment.pgp From nick at ucc.gu.uwa.edu.au Wed Apr 24 12:02:55 2002 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Wed Oct 27 01:25:03 2004 Subject: [tech] A question of File System In-Reply-To: <1019592708.10707.24.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au> <1019592708.10707.24.camel@mouse.danger.com> Message-ID: <20020424120255.V231762@morwong.ucc.gu.uwa.edu.au> On Tue, Apr 23, 2002 at 01:11:48PM -0700, Ian McKellar wrote: [...] > htree? that sounds interesting - its tree-based directories for ext[23]? Indeedy - very simple, backward compatible, extremely flat trees (ie two levels will cover tens of millions of index entries). Loading two blocks will get you to the index entry you want, making it essentially constant time. http://people.nl.linux.org/~phillips/htree/htree-2.4.18 http://lwn.net/2001/1213/a/directory-index.php3 [...] > So I have to get off my arse and do that metadata abstraction in > gnome-vfs I was meant to do two years ago... Sounds like it... 'Course that's the easy part. Next you have to get to world to fill in their files with enough metadata to make them useful, yet not rely on it to the point that everything breaks if you strip it off. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From dave at difference.com.au Wed Apr 24 16:40:14 2002 From: dave at difference.com.au (David Cake) Date: Wed Oct 27 01:25:04 2004 Subject: [tech] A question of File System In-Reply-To: <1019602090.10708.199.camel@mouse.danger.com> References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <1019602090.10708.199.camel@mouse.danger.com> Message-ID: At 3:48 PM -0700 23/4/02, Ian McKellar scribbled: >On Tue, 2002-04-23 at 13:29, David Cake wrote: >> > > >> >> And if you want pretty pink flowers, well, I'm sure Apple will have >> >> a filesystem with them soon... in five fruity flavours. >> > >> >Dom (ex-Be guy who wrote BFS) is working on a new FS at apple. That >> >should kick ass. BFS had all sorts of really nice things like >> >journalling and indexed file attributes. If Apple let him implement that >> >kind of thing it'll be great. The lack of attributes and the lack of >> >automatic metadata indexing on unix filesystems sucks. If OS X got that >> >it just might make me give up OS 9. >> >> Its about time. A good filesystem has been an obvious lack of >> Mac OS X for some time, and there was much rejoicing in some circles >> when Dom was hired. > >A friend of mine (a long-time NeXTStep user) tried running OS X with >UFS. It became clear very quickly that Apple just don't test that :-/ >> And plenty of open source projects that should know better assume all the worlds case sensitive, too. > > At 2:20 PM +0800 23/4/02, Nick Bannon wrote: >> >That's definitely got some promise. It's kinda irritating at the moment >> >because it doesn't have the simple ext2 attributes (immutable bit, >> >etc), but there is or has been a patch to provide that. What it ought >> >to get at some stage is more generic extended attributes, eg somewhere >> >to store ACL's for Samba. >> >> Not to mention handling those wacky Apple file attributes >> (Type, Creator, etc) properly. >> One of the particularly tragic things about Mac OS X is that >> old school NeXT people are always getting all worked up about HFS+s >> use of file attributes etc, and advocate using Apples fairly shocking >> UFS implementation instead, seemingly completely unaware of the sort >> of file features that have made it into modern unices. > >Yeah, some of my friends at Apple are frustrated by a lot of that. Some >of the NeXT people don't want to have inode monitoring (like linux's >dnotify/imon/fam, freebsd's kqueue, irix's imon/fam, BeOS had it, WinNT >has it...). I think my housemate (who works on the OS X display server) >is just gonna hack it into Darwin :) Some of the NeXT guys seem stuck in a bit of a time warp as regards Unix stuff. Hopefully Jordan Hubbard will set them right. At least he will hopefully make them remove all those man pages that were last updated in 1993 and document things that no longer ship with Darwin. >A couple of my friend who work on the Finder were at Be, one (Pavel) was >the guy who did most of the work on the Tracker (their file manager) >which exploited extended attributes extensively. Once they get that the >Finder might kick ass. Tracker did it right. A similar system would be a good thing. I'm glad to hear some clueful people are working in the area. >Unfortunately Apple seems to move very slowly >with technology (based on hearing things from people who work there and >having to wait years to see it ship). Yes. If you follow some of the Darwin things closely you can see it take 6 months or more from 'finished' to 'ship' sometimes. A lot of Apple seems to currently be stuck in a warring tribes mentality. And the current management of software don't seem to be fixing it*. In at least one case I have satisfied myself that this is because they are an idiot :-) Cheers David *excluding Bud Tribble, who hasn't been at Apple long, and might turn out to be good. From david at luyer.net Wed Apr 24 22:04:48 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:25:04 2004 Subject: [tech] A question of File System In-Reply-To: <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au> Message-ID: <001b01c1eb98$fec7fc40$46943ecb@pacific.net.au> > ext2/ext3's certainly not "slow". Directory operations are slow on > large directories. ext3 in full-data-journalling mode is slow at > writes, not that you'd typically run it that way. Both cream Solaris > UFS and Veritas VxFS, generally speaking. Old crappy Linux box. CVS update or diff takes 2.6 seconds. Same repository. Sun box approx twice the specs of said Linux box (ie. still rather old but at least with some decent hardware redundancy in it). Same CVS operations take approx 29 seconds. Move LockDir to a specially mounted tmpfs partition (not just /tmp because it's a chroot environment I didn't have tmpfs mounted under initially). Same CVS operations happen in under a second. Solaris can usually be made to rock, given enough tuning. The question is when the tuning is worth it, and when it isn't. David. From david at luyer.net Wed Apr 24 22:07:14 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:25:05 2004 Subject: [tech] A question of File System In-Reply-To: <1019592830.10708.27.camel@mouse.danger.com> Message-ID: <002601c1eb99$565f14c0$46943ecb@pacific.net.au> > We aren't any more. But price was the original motivation. Theres no > reason why an IDE disk should be less reliable - the mechanics can be > identical. The worst that should happen is possibly lower performance. Typically they'll use crappy encoding formats on IDE disks. The same encoding formats used to be used on IDE and Seagate Medalist SCSI. Neither lasted more than a day or two in a news server... The hardware encoding on a HDD matters a lot more than the interface, but fortunately they usually put the good ones together :-) David. From adrian at ucc.gu.uwa.edu.au Wed Apr 24 22:51:08 2002 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed Oct 27 01:25:05 2004 Subject: [tech] A question of File System In-Reply-To: <001b01c1eb98$fec7fc40$46943ecb@pacific.net.au> References: <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au> <001b01c1eb98$fec7fc40$46943ecb@pacific.net.au> Message-ID: <20020424225108.B187497@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 25, 2002, David Luyer wrote: > > > ext2/ext3's certainly not "slow". Directory operations are slow on > > large directories. ext3 in full-data-journalling mode is slow at > > writes, not that you'd typically run it that way. Both cream Solaris > > UFS and Veritas VxFS, generally speaking. > > Old crappy Linux box. CVS update or diff takes 2.6 seconds. > > Same repository. Sun box approx twice the specs of said Linux box > (ie. still rather old but at least with some decent hardware redundancy > in it). Same CVS operations take approx 29 seconds. I bet that you had stuff mounted sync (default under solaris, right?) Adrian From ian at mckellar.org Thu Apr 25 02:02:41 2002 From: ian at mckellar.org (Ian McKellar) Date: Wed Oct 27 01:25:07 2004 Subject: [tech] A question of File System In-Reply-To: References: <1019326588.1437.58.camel@Epoch> <014d01c1e93f$3353b5a0$43943ecb@Hyperion> <1019496554.25676.7279.camel@mouse.danger.com> <1019602090.10708.199.camel@mouse.danger.com> Message-ID: <1019671361.10707.262.camel@mouse.danger.com> On Wed, 2002-04-24 at 01:40, David Cake wrote: > At 3:48 PM -0700 23/4/02, Ian McKellar scribbled: > >On Tue, 2002-04-23 at 13:29, David Cake wrote: > > > >A friend of mine (a long-time NeXTStep user) tried running OS X with > >UFS. It became clear very quickly that Apple just don't test that :-/ > >> > > And plenty of open source projects that should know better > assume all the worlds case sensitive, too. I'm sure most will accept a patch :) Apple just shouldn't have made UFS an option if they weren't going to commit the QA resources to it. HFS+ has certainly worked well enough for me when I've used MacOS X. > > >Yeah, some of my friends at Apple are frustrated by a lot of that. Some > >of the NeXT people don't want to have inode monitoring (like linux's > >dnotify/imon/fam, freebsd's kqueue, irix's imon/fam, BeOS had it, WinNT > >has it...). I think my housemate (who works on the OS X display server) > >is just gonna hack it into Darwin :) > > Some of the NeXT guys seem stuck in a bit of a time warp as > regards Unix stuff. Hopefully Jordan Hubbard will set them right. Hopefully, but he is a FreeBSD person :( I had a preliminary interview with the filesystem group at Apple before I came to Danger and they seemed like a bunch of smart people. > At > least he will hopefully make them remove all those man pages that > were last updated in 1993 and document things that no longer ship > with Darwin. Yeah, when I was looking for audio docs all I could find were man pages on drivers for ISA cards that OpenSTEP supported... > > >A couple of my friend who work on the Finder were at Be, one (Pavel) was > >the guy who did most of the work on the Tracker (their file manager) > >which exploited extended attributes extensively. Once they get that the > >Finder might kick ass. > > Tracker did it right. A similar system would be a good thing. > I'm glad to hear some clueful people are working in the area. Yeah, I've got a lot of hope for it. Right now Finder is just not that good. Working on Nautilus raised my expectations of file managers significantly. > > A lot of Apple seems to currently be stuck in a warring > tribes mentality. And the current management of software don't seem > to be fixing it*. In at least one case I have satisfied myself that > this is because they are an idiot :-) > > *excluding Bud Tribble, who hasn't been at Apple long, and might turn > out to be good. Bud kicks ass. He was my manager at Eazel and in spite of being busy doing VPish stuff he still managed to be a decent manager. I hear rumors that Avi will be retiring soon... All rumors I assure you... Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20020424/2e554510/attachment.pgp From proxy at zdlcomputing.com Thu Apr 25 10:08:26 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:25:07 2004 Subject: [tech] NFS Server for NT ?? Message-ID: <1019700520.30439.40.camel@Epoch> Does such a thing exist ?? And is it free ?? If it is free, does it work ?? --davYd From acolyte at ucc.gu.uwa.edu.au Thu Apr 25 10:27:29 2002 From: acolyte at ucc.gu.uwa.edu.au (Andrew Bailey) Date: Wed Oct 27 01:25:07 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <1019700520.30439.40.camel@Epoch> References: <1019700520.30439.40.camel@Epoch> Message-ID: <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 25, 2002 at 10:08:26AM +0800, Riff wrote: > Does such a thing exist ?? And is it free ?? > If it is free, does it work ?? > > --davYd > Yes, Unix services for windows. No, its written by microsoft so its not. Of course there may be an open source NFS server, and if there isn't you could of course write one:) Oh and I think the above is kinda flaky. Andrew. -- "The hot dog eating contest is not only a beautiful display of athleticism, it is a fundamental way for citizens of all nations to display patriotism," - Wayne Norbitz From proxy at zdlcomputing.com Thu Apr 25 10:31:00 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:25:08 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> References: <1019700520.30439.40.camel@Epoch> <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019701862.30438.47.camel@Epoch> On Thu, 2002-04-25 at 10:27, Andrew Bailey wrote: > Does such a thing exist ?? And is it free ?? Yes, Unix services for windows. Ok, which version of NT5 has this included? And if it's only server, can I still install the component into Professional? --davYd From acolyte at ucc.gu.uwa.edu.au Thu Apr 25 10:33:57 2002 From: acolyte at ucc.gu.uwa.edu.au (Andrew Bailey) Date: Wed Oct 27 01:25:08 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> References: <1019700520.30439.40.camel@Epoch> <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> Message-ID: <20020425103357.G315772@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 25, 2002 at 10:27:29AM +0800, Andrew Bailey wrote: > > > Of course there may be an open source NFS server, and if there isn't you > could of course write one:) > > Oh and I think the above is kinda flaky. > Damn repling to my own post, smbmount is probably your friend for mounting Windows shares on a *nix box. I assume thats what you want to do. And that is free, its samba (cha-cha-CHA) Andrew. -- "The hot dog eating contest is not only a beautiful display of athleticism, it is a fundamental way for citizens of all nations to display patriotism," - Wayne Norbitz From proxy at zdlcomputing.com Thu Apr 25 10:44:13 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:25:09 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <20020425103357.G315772@morwong.ucc.gu.uwa.edu.au> References: <1019700520.30439.40.camel@Epoch> <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> <20020425103357.G315772@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019702657.30439.53.camel@Epoch> On Thu, 2002-04-25 at 10:33, Andrew Bailey wrote: smbmount is probably your friend for mounting Windows shares on a *nix box. I assume thats what you want to do. And that is free, its samba (cha-cha-CHA) Yes, I know about samba, and I know I could use it. However I was aiming to be able to do an evil behind the scenes mounting of remote directories. Which then appears as a series of samba shares on the one box. (I'm not sure these people would understand different things on different boxes) I shall have to keep googling it would seem. --davYd (I have a pigeon hole) proXy From acolyte at ucc.gu.uwa.edu.au Thu Apr 25 10:55:01 2002 From: acolyte at ucc.gu.uwa.edu.au (Andrew Bailey) Date: Wed Oct 27 01:25:09 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <1019702657.30439.53.camel@Epoch> References: <1019700520.30439.40.camel@Epoch> <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> <20020425103357.G315772@morwong.ucc.gu.uwa.edu.au> <1019702657.30439.53.camel@Epoch> Message-ID: <20020425105501.J315772@morwong.ucc.gu.uwa.edu.au> On Thu, Apr 25, 2002 at 10:44:13AM +0800, Riff wrote: > On Thu, 2002-04-25 at 10:33, Andrew Bailey wrote: > > Yes, I know about samba, and I know I could use it. However I was aiming > to be able to do an evil behind the scenes mounting of remote > directories. Which then appears as a series of samba shares on the one > box. (I'm not sure these people would understand different things on > different boxes) > Ok, now I am confused. Do you want to: A) mount stuff from a windows box onto a linux box. B) mount stuff from a linux box onto a windows box. either of the above can be done with samba[0] > I shall have to keep googling it would seem. > http://www.microsoft.com/windows2000/sfu/ > --davYd (I have a pigeon hole) proXy Andrew. [0] of course SMB and cifs are an evil protocol:) -- "The hot dog eating contest is not only a beautiful display of athleticism, it is a fundamental way for citizens of all nations to display patriotism," - Wayne Norbitz From proxy at zdlcomputing.com Thu Apr 25 11:01:35 2002 From: proxy at zdlcomputing.com (Riff) Date: Wed Oct 27 01:25:09 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <20020425105501.J315772@morwong.ucc.gu.uwa.edu.au> References: <1019700520.30439.40.camel@Epoch> <20020425102729.E315772@morwong.ucc.gu.uwa.edu.au> <20020425103357.G315772@morwong.ucc.gu.uwa.edu.au> <1019702657.30439.53.camel@Epoch> <20020425105501.J315772@morwong.ucc.gu.uwa.edu.au> Message-ID: <1019703697.30440.57.camel@Epoch> On Thu, 2002-04-25 at 10:55, Andrew Bailey wrote: Ok, now I am confused. I said it was evil. Therefore doesn't have to make sense. --proXy The concepts of Dune has taught us one thing. The ultimate form of propulsion would be a spaceship fitted with an array of tripping hippies. From david at luyer.net Thu Apr 25 11:14:58 2002 From: david at luyer.net (David Luyer) Date: Wed Oct 27 01:25:10 2004 Subject: [tech] A question of File System References: <20020423142027.U231762@morwong.ucc.gu.uwa.edu.au><001b01c1eb98$fec7fc40$46943ecb@pacific.net.au> <20020424225108.B187497@morwong.ucc.gu.uwa.edu.au> Message-ID: <004901c1ec07$618ad820$43943ecb@Hyperion> > I bet that you had stuff mounted sync (default under solaris, right?) Not even an option I'm aware of. They have noatime, but nothing like soft updates or ways to avoid delays with temp files such as deferring creation on disk until the object is pushed out of cache (and I am already using noatime). Remember the reason for tmpfs is that Solaris sucks with temporary files on UFS. Linux doesn't need a fs for /tmp. It handles short-lived files quite well. David. From andrew at ucc.gu.uwa.edu.au Thu Apr 25 11:17:43 2002 From: andrew at ucc.gu.uwa.edu.au (Andrew Williams) Date: Wed Oct 27 01:25:10 2004 Subject: [tech] NFS Server for NT ?? In-Reply-To: <1019702657.30439.53.camel@Epoch> Message-ID: <200204250317.g3P3Hil13762@linseed.longtable.org> On 25 Apr 2002 10:44:13 +0800, Riff wrote: >Yes, I know about samba, and I know I could use it. However I was aiming >to be able to do an evil behind the scenes mounting of remote >directories. Which then appears as a series of samba shares on the one >box. (I'm not sure these people would understand different things on >different boxes) So you want your unix box to mount several Windows shares from different servers, then make them available, via Samba, as a single windows share for clients to mount? You can probably do both with Samba - "mount -t smbfs" the shares, then make that directory available with Samba. However you do it, I imagine the speed will be abysmal... Andrew