From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 12 Nov 93 22:13:30 EST Subject: Linux-Development Digest #222 Linux-Development Digest #222, Volume #1 Fri, 12 Nov 93 22:13:30 EST Contents: Re: Motif - Pay? BAH! (peter j dohm) Re: [Q] Big modem installation for Linux? (Byron A Jeff) Re: [Q] Big modem installation for Linux? (Byron A Jeff) Re: [Q] Big modem install (Byron A Jeff) Re: 16550A handling in serial.c (Harald Koenig) Re: Berkeley Fast Filesystem (Joachim Hoenig) Re: Berkeley Fast Filesystem (Joachim Hoenig) Kernel output to /dev/tty0 (Jan Kasprzak) Mips R3000 board development (Stefan Franziskus) tmpfs Kernal patches? (Ken Wilcox) Re: Berkeley Fast Filesystem (Wayne Schlitt) 4.3 BSD sendmsg/recvmsg (Mark Little) Kernal Compling Soundg [oun[sound] (Debi Reid) Re: Motif - Pay? BAH! (Rainer Klute) Re: Progress on DIP? (Clifton Koch) Threads for Linux (Herve Soulard) Re: Berkeley Fast Filesystem (Jaye Mathisen) ---------------------------------------------------------------------------- From: dohm@cis.ohio-state.edu (peter j dohm) Subject: Re: Motif - Pay? BAH! Date: 12 Nov 1993 09:39:00 -0500 In article <2c03bf$u7@nz12.rz.uni-karlsruhe.de> frerk@tk.telematik.informatik.uni-karlsruhe.de (Frerk Meyer) writes: >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? Personally, i prefer fvwm, and believe it to be the window manager of choice for this project on the basis that it looks virtually identical (within tolerances) to mwm. I didn't personally like gwm when I tried it a few months ago. It just doesn't do much for me (sorry). > >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? It could, but it HAS to be a drop in replacement, or I'm just wasting my time writing YAWS (yet another widget set). >Since I like xmosaic very much, could someone rewrite it for tk/tcl >or Xview? Possible, except that I personally don't like either one all that much... (sorry again to you Xview/tk/tcl fiends :) >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 ;-) Get into it, it's kinda fun ;) >Frerk Meyer -+ >alias or Portnoy@irc "Do the ride thing!" o>o Pete --- +---------------------------------------------------------------------------+ | Peter J. Dohm - Comp. Science Major | The Ohio State University | | ** dohm@magnus.acs.ohio-state.edu ** | ak541@cleveland.freenet.edu | | dohm.1@osu.edu, dohm@cis.ohio-state.edu | dohm@cis.ohio-state.edu | +---------------------------------------------------------------------------+ ------------------------------ From: byron@cc.gatech.edu (Byron A Jeff) Subject: Re: [Q] Big modem installation for Linux? Date: Fri, 12 Nov 1993 14:38:01 GMT In article <1993Nov11.151733.16669@excaliber.uucp>, Joel M. Hoffman wrote: >[who wrote what deleted] >>>>As headline says, I wan't to run a Unix installation, preferable Linux, as i >>>>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.) >> >>>I'm presuming that you want to attach that many modems to 1 machine. For >>>multiple machines you can possibly use 4-6 networked machines with STB >>>4Ports such that each machine has 8 modems attached. > >Why only eight? I'm currently using two modems and a serial line, >having told one of the modems to use com3 (I forget which int.) So at >least 24 should be possible, and probably 32. No? No. Each COM port eats 8 IO slots. There are 1024 total available on the ISA bus and other devices must live on the bus also. In addition you only have 8 slots. The current config of serial ports on a PC will only support 8 serial lines. With specialized hardware (usually external to the PC) this can be bumped up. BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: byron@cc.gatech.edu (Byron A Jeff) Subject: Re: [Q] Big modem installation for Linux? Date: Fri, 12 Nov 1993 14:41:37 GMT In article <2btmvp$qnu@tymix.tymnet.com>, Wayne Flagg wrote: >Carl Boernecke (carlb@hardy.u.washington.edu) wrote: >: byron@cc.gatech.edu (Byron A Jeff) writes: >: >In article <2bo97j$lvs@belfort.daimi.aau.dk>, >: >Jesper Bach Larsen wrote: >: >> >: >>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... > >: >I'm presuming that you want to attach that many modems to 1 machine. For >: >multiple machines you can possibly use 4-6 networked machines with STB >: >4Ports such that each machine has 8 modems attached. > >: Here's an idea... how about getting a terminal server (an easy 12-14 >: hpone lines there), and an ethernet card for the Linux box, and going >: from there?... > >: -- Carl Boernecke (carlb@u.washington.edu or carlb@inex.com) > >How about a linux box with n serial ports and ethernet, no console, no >anything but act as a terminal server. I remember working with Bridge >terminal servers that were just dedicated unix boxes. They booted off a >floppy as I remember. We used 'em to avoid trying to put >256 ports on >a VME box - which was about as attractive as 30-50 serial ports on a >linux box. Probably cheaper than buying a terminal server - anyone know >what they cost these days? What would a floppy only, ethernet, and no >console linux box cost? Depends on the motherboard and memory. About $1300 for a 486DX40 with 16M RAM with case and power supply, floppy and ENET card. >Of course I don't know if linux out of the box >can run without the kbd and console, but then... If the BIOS supports it, linux has no problem with no keyboard or monitor. BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: byron@cc.gatech.edu (Byron A Jeff) Subject: Re: [Q] Big modem install Date: Fri, 12 Nov 1993 14:45:03 GMT In article <2bu54iINN3o2@xs4all.hacktic.nl>, Ron Arts wrote: >Newsgroups: comp.os.linux.development >Subject: Re: [Q] Big modem install > >w> How about a linux box with n serial ports and ethernet, no console, >w> no anything but act as a terminal server. I remember working with >w> Bridge terminal servers that were just dedicated unix boxes. They >w> booted off a floppy as I remember. We used 'em to avoid trying to >w> put >256 ports on a VME box - which was about as attractive as 30-50 >w> serial ports on a linux box. Probably cheaper than buying a terminal >w> server - anyone know what they cost these days? > >Cheapest I could find was 4600 Dutch Guilders (about $2500) > >w> What would a floppy >w> only, ethernet, and no console linux box cost? > >Yeah, that could be a nice solution. But don't forget you need serial ports.. >Can you run Linux from a floppy disk only (and get the rest from the lan)? Yes. In fact it's possible to drom the loader on an EPROM and totally bypass the floppy and have a totally diskless station. The Hardware is the problem no doubt. BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: koenig@ceres.tat.physik.uni-tuebingen.de (Harald Koenig) Subject: Re: 16550A handling in serial.c Date: 12 Nov 93 08:54:44 GMT In <2brcop$g2f@moonshot.west.oic.com> dillon@moonshot.west.oic.com (Matthew Dillon) writes: >In article koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: >:Another UART question (I have 4 16550As): >: >:the normal UARTS do probing for the start bit synchronously with >:16 times the baud rate (for 50 baud this is 800 Hz or 1.25ms). >: >:Are any (pin compatible?) UARTs known which have a better >:time resolution on start bit detection? >: >:if not pin and plug compatible, are there any pc cards with such uarts? >: >:Thanks, >:Harald >: >:-- >:Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) > Not that I know of, and even if they did it would not make the uarts work > any better. The 16x baud start bit synchronization is used to synchronize > to the center of each incomming bit. A 1/16 bit time offset will make > NO difference. > Generally the uart detects the start bit, then counts 8 clocks to move to > the center of the start bit, then checks it again (false start bit > detection), then clocks in the data bits every 16 clocks thereafter. > Some uarts will also check the data to either side of the center to > detect 'noise', but there are very few real world situations nowadays > where that kind of noise detection is meaningful since modems reclock > their data. A long time ago when there were only FSK modems at 600 > baud or less the FSK demodulation would be directly converted and not > reclocked by the modem, so 'noise' detection would be meaningful, but > that is no longer the case. > Detection of a new start bit normally occurs after the center point in the > stop bit is detected, allowing the sender to be as much as 1/2 bit out > of phase with the receiver without the receiver missing a beat. This > feature is a thousand times more important then a 32x sampling rate, > and all UARTs have it. > -Matt 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. Harald -- Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) All SCSI disks will from now on be required to send an email notice 24 hours prior to complete hardware failure! ------------------------------ From: hoenig@immd3.informatik.uni-erlangen.de (Joachim Hoenig) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 1993 10:05:02 GMT nate@bsd.coe.montana.edu (Nate Williams) writes: >Wayne Schlitt wrote: >>The Berkeley FFS also suffers from several other problems on modern >>disk drives. In particular, they made the assumptions that the users >>knew how many heads, tracks and cylinders the disk had, and the the >>number of tracks per sector stayed constant across the disk. With >>SCSI drives, you don't know this information and the tracks per sector >>isn't constant. IDE drives usually lie about the number of heads and >>cylinders in order to work under DOS. >Hmm, I know how many heads, tracks, cylinders and such on my drive. >And, the filesystem knows how to optomize for this. If you don't know >this information, it can't optomize for it but the BSD-FFS doesn't >REQUIRE this information for it to work effeciently. That's right. BSD-FFS uses this info to do some elaborate guessing at the optimal rotational position where to continue allocating blocks for a file after stepping to a different cylinder. Without this information no harm is done, maybe the FS performance is a nifty bit less than optimal. >(And it was pointed out in a followup article that most newer drives use >zones. I've heard that the BSD 4.4 SCSI drivers take this information >into account so that the FS can use them.) And you can try to fit your partition in one of these zones and go with the sector numbers of this zone. Joachim ------------------------------ From: hoenig@immd3.informatik.uni-erlangen.de (Joachim Hoenig) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 1993 10:07:15 GMT hpeyerl@novatel.ca (Herb Peyerl) writes: >Joachim Hoenig (hoenig@immd3.informatik.uni-erlangen.de) wrote: >: imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >: With some reverse engineering the NetBSD file system utilities like >: tunefs, newfs and fsck compile nicely on linux, though. >Why would you have to reverse engineer anything from NetBSD. The source >is free you know... You have to remove the disklabel etc. stuff. Joachim ------------------------------ From: kas@varda.ics.muni.cs (Jan Kasprzak) Subject: Kernel output to /dev/tty0 Date: 9 Nov 1993 13:40:21 GMT Hi all, Last week I have tested robustness of my kernel (ALPHA-pl13p) using "crashme" utility. This program was able to kill/panic/shutdown/crash any of systems I know -- e.g SCO, AT&T SVR3, SUN OS 4.*.*, {NET,386}BSD in few minutes. My linux kernel DIDN'T CRASH for 6hours (!). (Then I've kill all "crashme"s running on my system). But there was one very unpleasant thing: All messages about illegal FPE instructions, etc. from kernel was written to active virtual console :-((((. On some systems (AT&T SVR4, NetBSD with syscons console driver, ...) kernel output goes to one VT (ususally /dev/console or /dev/vt0 or something that). And therefore I decided to make some patch to kernel to enable kernel output to /dev/tty0. In console.c I changed only console_print() in console.c and panic() in panic.c -- panic() should change active vt to /dev/tty0 before kernel enters an infinite loop at the end of panic(). Comments, bug fixes (if any :-), etc welcomed by E-mail. NOTE: -- My kernel didn't crash possibly because it is _very_ small: No network, no SCSI, no soundcards configured in kernel. -Yenya Well, here are diffs (diff -c) *** console.c.new Mon Nov 8 08:55:17 1993 --- console.c.orig Wed Oct 27 14:47:12 1993 *************** *** 53,60 **** #include "vt_kern.h" - #define KERNEL_OUTPUT_TO_CONSOLE /* This probably should be in tty.h */ - #ifdef CONFIG_SELECTION #include --- 53,58 ---- *************** *** 1305,1316 **** void console_print(const char * b) { - #ifdef KERNEL_OUTPUT_TO_CONSOLE - int currcons = 0; - #define kernel_attr 0x0f /* Attribute of kernel output -- underlined */ - #else int currcons = fg_console; - #endif unsigned char c; if (!printable || currcons<0 || currcons>=NR_CONSOLES) --- 1303,1309 ---- *************** *** 1323,1333 **** if (c == 10 || c == 13) continue; } - #ifdef KERNEL_OUTPUT_TO_CONSOLE - *(unsigned short *) pos = (kernel_attr << 8) + c; - #else *(unsigned short *) pos = (attr << 8) + c; - #endif if (x == video_num_columns - 1) { need_wrap = 1; continue; --- 1316,1322 ---- *** panic.c Sun Oct 3 17:33:26 1993 --- panic.c.new Tue Nov 9 13:43:48 1993 *************** *** 13,18 **** --- 13,20 ---- #include #include + #define KERNEL_OUTPUT_TO_CONSOLE /* This should be in tty.h and + tty.h shoud be included here */ asmlinkage void sys_sync(void); /* it's really int */ extern int vsprintf(char * buf, const char * fmt, va_list args); *************** *** 22,27 **** --- 24,34 ---- static char buf[1024]; va_list args; + #ifdef KERNEL_OUTPUT_TO_CONSOLE + extern void update_screen(int new_console); /* From console.c */ + + update_screen(0); + #endif va_start(args, fmt); vsprintf(buf, fmt, args); va_end(args); -- | Jan "Yenya" Kasprzak "... in each system is a security hole, | kas@erebor.ics.muni.cz all security holes will be discovered ..." | kas@muni.cz -- | Jan "Yenya" Kasprzak "... in each system is a security hole, | kas@erebor.ics.muni.cz all security holes will be discovered ..." ------------------------------ From: stefan@bugfix.cs.uni-sb.de (Stefan Franziskus) Crossposted-To: comp.os.linux Subject: Mips R3000 board development Date: 12 Nov 1993 10:50:47 GMT A few months ago the discussion for the development of a MIPS R3000 or R4000 board for LinuX started in this newsgroup, but then nothing was ever posted again. Could someone please post the current state of development, is there a mailing-list or something like that, thanks for any information. - Stefan -- +----------------------------------------+------------------------------------+ | \ / + * + | Stefan Franziskus | | * ______________ MegaMover _ _ | Chaos 11, Uni SB | ------------------------------ From: wilcox@kpw104.rh.psu.edu (Ken Wilcox) Subject: tmpfs Kernal patches? Date: 12 Nov 1993 11:10:12 GMT I was wondering if someone has writen any tmpfs filesystem patches for linux? I wanted to mount my swap partition on /tmp like we do on our sun network but when I tryed to do so, it blew beets. If there is nothing out there, I would like to take this on. I didn't want to step on anyone elses toes so I thought that I would ask. Thanks in advance. -Ken Wilcox ------------------------------ Crossposted-To: comp.os.linux.admin From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Berkeley Fast Filesystem Date: Fri, 12 Nov 1993 14:45:51 GMT In article <2bv856$71v@pdq.coe.montana.edu> nate@bsd.coe.montana.edu (Nate Williams) writes: > In article , > Wayne Schlitt wrote: > > >Fragments are not necessarily a good idea. There are two independent > >values here: > > 1) How big should the block size be when allocating space for a > > file? > > > > > > 2) How much data should you read off the disk at one time? > > > > If you read too little data, then you are going to spend a lot > > of time dealing with the overhead of reading blocks. > > You also > > won't be able to read consecutive tracks, causing rotational > > delays to be added in. > > Huh? I think the end result is that if you read one block at a time, you read > one block at a time. This has very little bearing on disk tracks. If the overhead of reading one block at a time is large enough, you won't be able to read consecutive sectors. > > If you read too much data, then you may well be wasting space on > > I/O buffers that could better be used for programs or data. > > ??? This is irrelavant to the file-system, and is a problem with your buffer > code being overly agressive. how much data should be read at one time depends on how much free memory you currently have. If you have 1MB of free memory, go ahead and read 128k. If memory is tight, only read 8k... This is something that can't be accurately guessed at when you are building the file system. You should check it at run time. > > >The Berkeley Fast Filesystem changed things to use a 8k block size, > >which is better for a disk access size, but horrible for an allocation > >size. In order to "fix" the problem with the allocation size, they > >created fragments, which are 1k. > > >Unfortunately, you can only use a > >fragment if the entire file fits in the fragment, so the FFS wastes, > >on average 4k any time the file is over 1k in size. > > What *ARE* you talking about? The fragments are used for the tail ends > of the files. It was my understanding that framents were used only when the entire file was 1k or less, but you may be right that it is used for the tails of all files. I am fairly sure that you can't uses multiple fragements though, so a 42k file would not be able to use 2 fragements. > A > fragmented file-system will almost invariably use less space than a > non-fragmented file-system. Not if you make the allocation size as small as the fragement size. If you do that, then you won't get any more wasted with a non-fragmented filesystem. > >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. 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 ------------------------------ From: M.C.Little@newcastle.ac.uk (Mark Little) Subject: 4.3 BSD sendmsg/recvmsg Date: Fri, 12 Nov 1993 11:18:52 GMT The latest version of Linux which we have (0.99.13q) supports send/sendto and recv/recvfrom. Are there any plans to support the other 4.3 BSD primitives for sending and receiving scatter/gather buffers, i.e., sendmsg and recvmsg? We have some software which uses these. Thanks in advance, Mark. ------------------------------ From: dreid@mailer.cc.fsu.edu (Debi Reid) Subject: Kernal Compling Soundg [oun[sound] Date: Fri, 12 Nov 1993 11:11:12 GMT I was having a little trouble compiling 0-99p13 a while back, but it seems that I have gotten that problem solved (killed some dir's and re-created a few sym-links....) Anyrate this is great and dandy. It compiles nice and clear, as long as I do not try to and in the SB drivers. I am using snd-driv-2.0.tar.gz for sunsite. Anyrate, all I really want to know is if that have been know problems comiling this with 99p13? Anyrate, let me try it again, I have a dew ideas on what the problem is. Thanks! ------------------------------ From: klute@tommy.informatik.uni-dortmund.de (Rainer Klute) Subject: Re: Motif - Pay? BAH! Date: 12 Nov 1993 12:03:23 GMT In article <2bv87oINNpd@junk.cis.ohio-state.edu>, dohm@cis.ohio-state.edu (peter j dohm) writes: |> I'd like to begin programming a Motif clone that we can pass around |> under GPL to whomever would like it, assuming that we can legally |> get around the naming conventions, etc. (by this I mean, can we call |> the cloned functions the same names as the Motif ones, etc... ?) OSF has given resp. will give (I'm not quite sure) the Motif *specification* to X/OPEN. That means, Motif will be an open standard. Everybody who wants can get the specification and implement his own Motif. -- Dipl.-Inform. I R B : immer richtig beraten Rainer Klute Universität Dortmund, IRB |)|/ Tel.: +49 231 755-4663 D-44221 Dortmund |\|\ Fax : +49 231 755-2386 ------------------------------ From: koch@rtsg.mot.com (Clifton Koch) Subject: Re: Progress on DIP? Date: 12 Nov 93 02:50:59 GMT ccn@underg.ucf.org (Chris Nystrom) writes: >Kenneth Topp (toppk@bray1a.its.rpi.edu) wrote: : Hello, >: Is there anyone working on dip? >: I believe that a feature lacking in this program is the computer >: responding to being giving an IP that is different each time. >: This happens in many cases with a serial link. I think that >: DIP should have support for BOOTP. Any knowledge of work >: towards that end would be appriciated. >The other problem with dip is that it does not use lock files >to share the serial port. I have been working on this, but do not >have as much time as I would like to work on it. I have a version of DIP I modified which has extra script functions to both grab the IP address off of a dynamic server (it grabs it from the serial stream, this is not a bootp implementation) and implements lock files. If anyone is interested, let me know and I'll send it to you. Cliff -- ============================================================================= Cliff Koch Motorola Cellular Infrastructure Division koch@rtsg.mot.com ------------------------------ From: soulard@zorglub.inria.fr (Herve Soulard) Subject: Threads for Linux Date: 12 Nov 1993 09:11:22 GMT Reply-To: soulard@sor.inria.fr Does it exist a threads package on Linux ? I need something like pthreads. The scheduler must be preemptive. Herve Soulard. ------------------------------ From: osyjm@cs.montana.edu (Jaye Mathisen) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 12 Nov 1993 16:25:01 GMT In article , Wayne Schlitt wrote: >In article <2bv856$71v@pdq.coe.montana.edu> nate@bsd.coe.montana.edu (Nate Williams) writes: >> Huh? I think the end result is that if you read one block at a time, you read >> one block at a time. This has very little bearing on disk tracks. > >If the overhead of reading one block at a time is large enough, you >won't be able to read consecutive sectors. Which is the whole point of the rotdelay parameter, which is to tell the driver how long it takes the disk to be ready for another transfer, after the end of one. > >how much data should be read at one time depends on how much free >memory you currently have. If you have 1MB of free memory, go ahead >and read 128k. If memory is tight, only read 8k... This is something >that can't be accurately guessed at when you are building the file >system. You should check it at run time. This seems like a waste of time, and certainly adds more overhead, especially on a heavily used machine. > >Not if you make the allocation size as small as the fragement size. >If you do that, then you won't get any more wasted with a >non-fragmented filesystem. Seems like if the allocation size is small, you add mucho more data that has to be kept track of, more inodes for all those blocks, more chains of inodes to follow, seems like for big, big files you would need quadruple indirection, etc. Kind of sounds like you think the DOS FS is the way to go... -- 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 ------------------------------ ** 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 ******************************