From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 13 Nov 93 05:13:27 EST Subject: Linux-Development Digest #223 Linux-Development Digest #223, Volume #1 Sat, 13 Nov 93 05:13:27 EST Contents: Re: Motif - Pay? BAH! (Jaye Mathisen) Re: 16550A handling in serial.c (John C Sager) Re: new Berkeley DB - anyone? (Rene COUGNENC) Re: Motif - Pay? BAH! (Frerk Meyer) Re: Progress on DIP? (Steve Tinney) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (David Leonard) Re: Motif - Pay? BAH! (Matthew F. Ringel) Mounting floppy: Solaris fs? (Thomas J Bilan) Q: mounts via msdos chunks ? (Hermann Dunkel) Re: Berkeley Fast Filesystem (Nils Nieuwejaar) Re: Berkeley Fast Filesystem Re: [Q] Big modem installation for Linux? (Christian Kuhtz) Re: Berkeley Fast Filesystem (Eric Youngdale) Re: Berkeley Fast Filesystem (Wayne Schlitt) ---------------------------------------------------------------------------- From: osyjm@cs.montana.edu (Jaye Mathisen) Subject: Re: Motif - Pay? BAH! Date: 12 Nov 1993 16:28:10 GMT I am not a Mosaic user, but WTF does the choice of window manager have to do with the libraries required to build a program? -- Jaye Mathisen, COE Systems Manager (406) 994-4780 410 Roberts Hall,Dept. of Computer Science Montana State University,Bozeman MT 59717 osyjm@cs.montana.edu ------------------------------ From: jcs@zoo.bt.co.uk (John C Sager) Subject: Re: 16550A handling in serial.c Date: Fri, 12 Nov 93 12:16:00 GMT In article , koenig@ceres.tat.physik.uni-tuebingen.de (Harald Koenig) writes: [...] > > My interesst is not in performance or reliability. > > I'm using a RS232 line to connect a radio clock receiver which sends > one character per second at 50 baud. To adjust the UNIX clock as exact as > possible it is important to know the exact time of the rising edge of the > signal (which is detected as start bit). with the current UARTs I only get > a resolution of 1.25 ms which isn't god enough. > > with some external logic it would be possible to use higher baud rates > but this would result in loosing some of the nice features of the > 50 baud solution. > I presume the 1 per second character sequence conveys useful information, that is, you want to receive the characters at 50 baud anyway. You could trigger a retriggerable monostable with a period > 20ms off the start pulses, so you get a clean (long) single pulse once per second. You can then do one of two things: 1) feed this pulse to the DCD line & hack serial.c to detect & timestamp the DDCD interrupt thus generated. I am going to do this myself, as I have a similar requirement (a 1PPS pulse from a GPS receiver). However, I'm currently chasing some more fundamental kernel problems which lead to lost clock interrupts, so I may be a while on that one. 2) use the leading edge of the pulse to trigger a second monostable generating a start pulse at 19.2kbaud or 38.4kbaud & feed this to a second tty port. At 38.4kb you then only have a 1.6us uncertainty, which is much better than the timing accuracy of your radio clock, and much better than the latency jitter you will get on serial device interrupts in linux. John C Sager Mail: B67 G18, BT Labs Email: jcs@zoo.bt.co.uk Martlesham Heath Tel: +44 473 642623 IPSWICH IP5 7RE Fax: +44 473 637614 England Disclaimer: This is me, not BT. ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: new Berkeley DB - anyone? Date: 11 Nov 1993 20:15:51 GMT Ce brave Tommy Thorn ecrit: > rene@renux.frmug.fr.net (Rene COUGNENC) writes: > >Ce brave Christian Kuhtz ecrit: > >You are right, there is a problem whith the system include files (not the > >program ones), I just hacked features.h to define: > No, you are wrong. The problem lies in the fact that Berkeley DB comes > with system include files, namely cdefs.h as could be seen in what I > posted. The easy fix: remove the symlink to cdefs.h in include. That's true... As I said, I just compiled 'badly' this db stuff, just to link it whith sendmail, for... not using sendmail :-) (It was raining outside...) And after reading this thread, I realized that I've got an old version of this package, I'll get the correct one. Ok, now I'll take your patch, and do it the right way ! (Despite the fact that it does not rain any more now... :- ) -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: frerk@tk.telematik.informatik.uni-karlsruhe.de (Frerk Meyer) Subject: Re: Motif - Pay? BAH! Date: 12 Nov 1993 13:33:34 GMT Someone told me that the gwm (generic window manager) provides Motif look&feel. Since it is programmable (in Lisp), this would be a good starting point to replace the mwm, but I haven't seen gwm in action yet. Experience, objections, anyone? Another starting point would be tk/tcl, that was designed by its inventor intentionaly after the Motif look&feel (but better). So could this software be used instead of the Motif Widget Set? Since I like xmosaic very much, could someone rewrite it for tk/tcl or Xview? Sorry that I don't offer my help in it, but I've never programmed X-Windows at all. I just use and compile it ;-) -- Frerk Meyer -+ alias or Portnoy@irc "Do the ride thing!" o>o ------------------------------ From: sjt@enlil.museum.upenn.edu (Steve Tinney) Subject: Re: Progress on DIP? Date: 12 Nov 93 15:33:33 GMT The other feature that would be useful would be to allow line settings to be given in a dip script. I'm just in the process of setting this stuff up at home, and have had success using minicom to dial, dropping out and then using dip to do the SLIP startup. Only works as root, though, because only root can use ifconfig. Steve ------------------------------ Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc From: c9107786@peach.newcastle.edu.au (David Leonard) Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: Fri, 12 Nov 1993 16:12:20 GMT lih@news.cs.columbia.edu (Andrew "Fuz" Lih) writes: >In article , Patrick Schaaf wrote: >>cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) writes: >>>[on MAC files and their forks, and how they might map to files under Linux] >> >>Would it be a Bad Thing to have files that, in addition to being a normal >>file (the data fork), implement the various directory ops? i.e. access the >>data fork as 'foo`, and other forks as 'foo/thingie` and so on? >> >>having strange ideas... >Not so strange: that's how the Apple UNIX File System in the Columbia >AppleTalk Package does it. It's been in active use for over 5 years now. CAP does that. Its quite a natural thing to do in a UFS, to put things in directories. The macintosh file "foo" would appear as: ./foo (the data fork) ./.resource/foo (the resource fork) ./.finderinfo/foo (other stuff) The group and owner of the file are used for the Sharing stuff (naturally) I dont think you should nasty up the kernel to handle non-flat (bent?) files, just like I dont think you should nasty it up for non-flat memory addr spaces. What would also be tricky is a program similar to AccessPC for the Mac that possibly supplemented the Install program provided with the ALICE project, that would allow you to mount a UFS under MacOS. I guess all this will come in Time. Dave Leonard Regarding MacBSD: I too checked in the cupboard and found a tin of Miracle Whip and a packet of OREOs. Bummer. ------------------------------ From: ringel@news.cs.columbia.edu (Matthew F. Ringel) Subject: Re: Motif - Pay? BAH! Date: 12 Nov 1993 12:47:52 -0500 In article <2c0diq$9ro@pdq.coe.montana.edu>, Jaye Mathisen wrote: > >I am not a Mosaic user, but WTF does the choice of window manager have >to do with the libraries required to build a program? >-- > Jaye Mathisen Absolutely nothing. mwm is merely a window manager that is built with the motif libraries. Therefore you get the Motif look-and-feel without having to own the libraries. The confusion between having the libraries and having the window manager comes up every now and then in the comp.os.unix.* groups. ......Matthew -- |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| Matthew F. Ringel ringel@ground.cs.columbia.edu "I am not a number! I'm three numbers, a hyphen, two numbers, another hyphen, and another four numbers after that! Hah!" -mfr ------------------------------ From: bilan@cps.msu.edu (Thomas J Bilan) Subject: Mounting floppy: Solaris fs? Date: 12 Nov 1993 21:36:42 GMT I am despirately looking for a fs patch so that I can mount floppies formatted on a Sun Sparc 10 (Solaris 2.2) or SVR4. Has anyone been working on this? Thanks, Tom Bilan -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ $ Department of Death by Engineering ^ Surgeon General's Warning: $ $ Michigan State University ^ Graduate School may cause brain $ $ bilan@cps.msu.edu ^ damage and sporadic loss of hair $ ------------------------------ From: dunkel@yoda.cul-ipn.uni-kiel.de (Hermann Dunkel) Crossposted-To: comp.os.linux.misc Subject: Q: mounts via msdos chunks ? Date: 12 Nov 93 18:05:07 GMT My goal is to mount large files from the dos partition as a filesystem on the linux side. Then it could be possible to have some of these smart all-on-one boot floppies together with a special installation procedure, that installs additional disks on these mounts. So it would be possible to give a big LINUX demo (incl. X), without running any fdisk! It could work like this: the dos partition is mounted as /dos and has 50 MB free. An 'empty' file with 40 MB is created as /dos/chunk1 mount -t fileMount /dos/chunk1 /myDir All following actions in /myDir would access blocks within the XX MB chunk. Which gives a full filesystem (longnames etc.) which resides physically on the dos disk space. I once made a test with the 'loop'? filesytem which allows this kind of mounts even with encryption. But as far as I remember it failed for files which were on a dos mount. I think the mount was dead waiting for some io stuff. Finally my question: Did someone else think in this direction ? Has anyone more experience with mounts from files (the 'loop?' fs) ? Is there any reason that this kind of mount/demo is NOT possible ? regards, HeDu -- ////|\\\\ \\\\\\ Hermann Dunkel O O ////// IPN Uni Kiel, Germany | \\\\\\ Tel: +49 431 / 880 3144 \___/ ////// E-mail: dunkel@cul-ipn.uni-kiel.de \_/ \\\\\\ ------------------------------ From: nils@wildcat.dartmouth.edu (Nils Nieuwejaar) Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 1993 17:23:29 GMT nate@bsd.coe.montana.edu (Nate Williams) writes: >In article , >Wayne Schlitt wrote: >> On a typical Unix system, approx 40% of the files will be 1k or >> less, and 90% of the files will be 4k or less. >I think this has changed, but I have no numbers to back it up. from comp.os.research (I think): A static analysis of unix file systems circa 1993 ================================================= In response to a request for file size data I posted on the net I have received data for 6.2 million files, residing on 650 file systems, on over 100 unix machines, and with a total size of 130 gigabytes. File sizes ========== file size #files %files %files disk space %space %space (max. bytes) cumm. (Mb) cumm. 0 87605 1.4 1.4 0.0 0.0 0.0 1 2056 0.0 1.5 0.0 0.0 0.0 2 3030 0.0 1.5 0.0 0.0 0.0 4 6179 0.1 1.6 0.0 0.0 0.0 8 12726 0.2 1.8 0.1 0.0 0.0 16 38803 0.6 2.5 0.5 0.0 0.0 32 172587 2.8 5.3 4.3 0.0 0.0 64 192590 3.2 8.5 9.7 0.0 0.0 128 164424 2.7 11.2 15.3 0.0 0.0 256 316512 5.2 16.4 57.6 0.0 0.1 512 684248 11.3 27.7 302.7 0.2 0.3 1k 764462 12.6 40.3 608.6 0.4 0.7 2k 987236 16.3 56.5 1479.1 1.1 1.8 4k 820540 13.5 70.0 2383.7 1.8 3.6 8k 597291 9.8 79.9 3483.7 2.6 6.2 16k 467633 7.7 87.6 5470.3 4.0 10.2 32k 317034 5.2 92.8 7421.2 5.5 15.7 64k 193656 3.2 96.0 8964.3 6.6 22.3 128k 112459 1.9 97.8 10418.6 7.7 30.0 256k 63876 1.1 98.9 11729.0 8.7 38.6 512k 34198 0.6 99.4 12540.9 9.3 47.9 1M 18282 0.3 99.7 13365.1 9.9 57.7 2M 9233 0.2 99.9 13291.7 9.8 67.5 4M 3955 0.1 100.0 11466.7 8.5 76.0 8M 1310 0.0 100.0 7545.2 5.6 81.6 16M 551 0.0 100.0 6315.4 4.7 86.2 32M 270 0.0 100.0 6377.1 4.7 90.9 64M 119 0.0 100.0 5864.2 4.3 95.3 128M 23 0.0 100.0 2095.4 1.5 96.8 256M 9 0.0 100.0 1819.7 1.3 98.2 512M 7 0.0 100.0 2495.7 1.8 100.0 ------------------------------ Crossposted-To: comp.os.linux.admin From: root@orion.mgen.uni-heidelberg.de () Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 93 18:24:22 GMT Wayne Schlitt (wayne@backbone.uucp) wrote: : In article <2bv856$71v@pdq.coe.montana.edu> nate@bsd.coe.montana.edu (Nate Williams) writes: : > In article , : > Wayne Schlitt wrote: : > >Fragments add : > >additional code and complications when something needs to be moved too : > >or from a fragment. The 8k block size also isn't large enough to get : > >really good throughput from the disk when reading sequentially, and it : > >is too large when reading randomly. : > : > ??? 8K isn't large enough to get really good throughput. Let's see some : > numbers to back that up. I get VERY good performance using an 8K/2K : > BSD-FFS with the 486/33. (1.5MB/sec reading and 1MB/sec writing w/out : > any hardware cache on a 486/33 ISA box. On EISA boxes I've seen numbers : > in the upper 2's and 3's) : The hard disk that has my data is currently in the mail to Quantum to : get fixed. *sigh*. Sorry, all I have is my memory. Note, that I : didn't say that 8k would get really bad throughput, just that reading : an entire track at a time can get better performance than reading just : 8k. A modern drive with a decent size read/write cache will do the track buffering for you. Older drives had much worse performance with 8kb compared to 64kb. With modern drives you still have the problem, that on many drives the write cache is disabled by default, giving bad write performance. : Basically, my point was that fragments get you nothing that just : clustering reads and writes can't also get you. Clustering is simpler : to implement, wastes less disk space and can get even better : performance. This was all discussed recently in comp.arch.storage... : -wayne -- Andreas Helke Institut fuer molekulare Genetik, Universitaet Heidelberg Im Neuenheimer Feld 230 69122 Heidelberg ------------------------------ From: chk@data-hh.Hanse.DE (Christian Kuhtz) Subject: Re: [Q] Big modem installation for Linux? Date: 11 Nov 1993 14:34:03 -0600 jbl@daimi.aau.dk (Jesper Bach Larsen) writes: >As headline says, I wan't to run a Unix installation, preferable Linux, as it >is free, with multiple modem lines. By multiple I mean in the amount of >30-50 modems. I suppose I will have to purchase somekind of hardware support >for this project. My question is: what would be the most effective (measured >in system-resources) installation? What kind of system-resource is required >for this (particular RAM recomendations, special I/O interfaces etc.) My recommendation is that you buy a terminal server and connect it to a UNIX host, maybe running Linux. Terminal servers aren't really expensive anymore. And I do not think that there are I/O interfaces for PC's who could drive 115KB on 30! lines. Regards, Chris -- Christian Kuhtz, Grüner Weg 69c, 22851 Norderstedt, Germany +49-40-5244138, 16-23 MET, 8-16 CST, chk@data-hh.Hanse.DE "route: huh?" [AMIX SVR4 2.1] ------------------------------ Crossposted-To: comp.os.linux.admin From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 1993 19:15:09 GMT In article <1993Nov12.182422.14045@sun0.urz.uni-heidelberg.de> root@orion.mgen.uni-heidelberg.de () writes: >A modern drive with a decent size read/write cache will do the track >buffering for you. Older drives had much worse performance with 8kb >compared to 64kb. With modern drives you still have the problem, >that on many drives the write cache is disabled by default, giving >bad write performance. Indeed this is true, but with SCSI disks there is a large amount of overhead to set up a command and get the data back, so larger data transfers really pay off here. I do not know what the situation is with IDE disks, however. People who read the SCSI channel already know this, but I have diffs to implement clustering with the linux SCSI disk drivers that more than double the I/O throughput while still using the same filesystems. I have also been working with the buffer cache to try and optimize things a bit to reduce the load spikes when the sync() is run, and further improve performance. If anyone wants this stuff, I tend to keep the latest version of the package on tsx-11 in pub/linux/ALPHA/scsi/cluster-*. I am still tinkering with some details, so I do not consider it quite done yet. You really need to be running the development releases of the kernel to make use of this. Note: this is still ALPHA - there have not been any recent reports of data corruption, but I would strongly recommend that you use these with caution. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 1993 22:25:14 GMT In article nils@wildcat.dartmouth.edu (Nils Nieuwejaar) writes: > >In article , > >Wayne Schlitt wrote: > > >> On a typical Unix system, approx 40% of the files will be 1k or > >> less, and 90% of the files will be 4k or less. > > >I think this has changed, but I have no numbers to back it up. > > from comp.os.research (I think): > > A static analysis of unix file systems circa 1993 > ------------------------------------------------- Yes, this was some of the data I went looking for but was on my other hard disk, so I had to use my (faulty) memory. While the 40% number was about right, there are only about 70% of the files that are less than 4k. One interesting thing about this data is that it shows how moving short files into the inode really help. With 11% of _all_ files being 128 bytes or less, I would think that this would be a big win, both in terms of performance, and in terms of disk usage. (You don't have those "big" 1k blocks with only a few bytes used in the beginning of them...) -wayne ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************