From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Sat, 13 Nov 93 07:14:07 EST Subject: Linux-Admin Digest #153 Linux-Admin Digest #153, Volume #1 Sat, 13 Nov 93 07:14:07 EST Contents: Re: Berkeley Fast Filesystem (Wayne Schlitt) Re: Berkeley Fast Filesystem (Jaye Mathisen) Re: SunService Supports WEITEK / UFC Crypt (Alan G. Arndt) Config. Control in Linux Kernels (Karl Keyte, ESOC Darmstadt) Re: Using Linux as server for remote X development (Philip Balister) Re: XFree2.0 and ld.so (Jon Luckey) Re: XFree2.0 and ld.so (Roos van Raadshooven L.A.) TCL 7.1/TK 3.4 on Linux ? (Philip C. Cox) Re: filesystem for archive disks (Stephen Williams) Re: newuser shell script (w/ code) (Mike Sperry) Re: Berkeley Fast Filesystem How to get rid of colors (Philip C. Cox) Re: Berkeley Fast Filesystem (Eric Youngdale) Tunable parameters (Dan Haskell) Re: Berkeley Fast Filesystem (jacobsd@heart.cor.epa.gov) ---------------------------------------------------------------------------- Crossposted-To: comp.os.linux.development 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: osyjm@cs.montana.edu (Jaye Mathisen) Crossposted-To: comp.os.linux.development 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 ------------------------------ Crossposted-To: comp.sys.sun.hardware,comp.sys.sun.admin,comp.security.unix From: aga@Comtech.com (Alan G. Arndt) Subject: Re: SunService Supports WEITEK / UFC Crypt Date: Thu, 11 Nov 1993 17:18:37 GMT In article <2bt3ds$kjp@uk-usenet.uk.sun.com> alecm@uk-usenet.uk.sun.com writes: >Using UFC's SPARC assembler stub, I measure a SS2 as an easy to >remember 1250eps (ie: encryptions per second). > >This was measured on a lightly loaded SS2 using UFC's "speedf" program. > >I can't remember what the ss10%50 managed, I think it was about 3100eps That is rather interesting. I thought a SS2 was about 2x a SS1+. Our measly SS1+ gets 1051 on the speedf test. I guess that doesn't say much for a SS2. Or you have something wrong. Other intersting facts are that the SS10/41 we had in here for demo only got about 1500 as I recall. Something was obviously wrong. The other bit of information I have is on a SGI Indigo, 50Mhz R4000. It gets 3270 on the speedf benchmark. That is with a standard SGI compiler on the generic version, not the hand deon assembly the Sparc's use. So again if a SS10/50 with assembly code only gets 3100 I certainly am not very impressed! ---- Alan Arndt Comtech Labs 415-813-4500 900 Hansen Way aga@Comtech.com Palo Alto, CA 94304 ------------------------------ Date: Fri, 12 Nov 1993 10:42:25 CET From: Karl Keyte, ESOC Darmstadt Subject: Config. Control in Linux Kernels I have a question to which I haven't really seen too much of an answer. I presume that Linus is maintaining the "official" releases of the kernels, 13p, 13q, etc. The question is: How is support for various extensions in the kernel managed? For example, I have applied lots of patches to my 13 (raw) kernel to provide support for quotas, kernel statistics, networking, accounting, etc. How do I know if I get these for free with a new kernel? Do I have to re-apply the patches and hope that they work with new kernel source (which they certainly won't with the number of changes which have been made by now)?? Do I have to try to apply the patches by hand? Do I have to wait until the authors of, say, quotas make patches which I can apply to the newest kernel? It would be useful if each kernel came with a status list of major components such as those listed above. I know some information comes with each, but it is inconsistently updates with each new release. Any ideas? Karl ------------------------------ From: balister@maddog.async.vt.edu (Philip Balister) Subject: Re: Using Linux as server for remote X development Date: 12 Nov 1993 13:52:50 GMT Reply-To: pbaliste@vt.edu Bibhas Bhattacharya (bibhas@pico.engr.mun.ca) wrote: : Hi, : I hope the title makes sense. We have our X development resources in a 486 : running Interactive UNIX (386ix). We are looking forward to using Linux : platforms as display ends for such development work. We plan to use our : existing ethernet to do the networking. Any suggestions or comments while I : do the hardware survey for Linux. Basically we want a stable service from : Linux as the server. Use S3 cards they are cheap (sort of) and provide fantastic server performance. Philip -- Reply to: pbaliste@vt.edu Linux: The choice of a GNU generation! ------------------------------ From: luckey@rtfm.mlb.fl.us (Jon Luckey) Subject: Re: XFree2.0 and ld.so Date: Fri, 12 Nov 1993 15:48:55 GMT tracey@cs.wm.edu (Tracey Beauchat) writes: >The XFree2.0 distribution says that it requires ld.so. I >haven't been able to find it. Could someone please tell >if it is on sunsite or tsx-11, and if so where it is? Look in the GCC distribution area. I belive its /pub/linux/PACKAGES/GCC on tsx-11.mit.edu and /pub/Linux/PACKAGES/GCC on sunsite.unc.edu reading the release notes in that area seemed to imply that you needed to get a fair amount of other stuff besides ld.so ------------------------------ From: roosvanr@athena.research.ptt.nl (Roos van Raadshooven L.A.) Subject: Re: XFree2.0 and ld.so Date: Fri, 12 Nov 1993 18:24:11 GMT tracey@cs.wm.edu (Tracey Beauchat) writes: >The XFree2.0 distribution says that it requires ld.so. I >haven't been able to find it. Could someone please tell >if it is on sunsite or tsx-11, and if so where it is? sunsite.unc.edu:/pub/Linux/GCC/ldso-1.3.tar.z -Leon. ------------------------------ From: pcc@s1.gov (Philip C. Cox) Crossposted-To: comp.lang.tcl Subject: TCL 7.1/TK 3.4 on Linux ? Date: 12 Nov 1993 13:46:44 -0800 Has anyone gotten tcl 7.1 & tk 3.4 to run on linux? I am working on it, but do not want to duplicat effort :-) Phil -- Philip C. Cox | L.L.N.L. 7:^) E-Mail: pcc@s1.gov | P.O. Box 808 L-287 Livermore, CA 94550 ------------------------------ From: sdw@meaddata.com (Stephen Williams) Subject: Re: filesystem for archive disks Date: 12 Nov 1993 19:00:59 GMT Davor Cubranic (cubranic@whale.st.usm.edu) wrote: ... : ext2 (i.e. ext2fs) I'm loosing 5% of disk space that is reserved for : root. On the other hand, e2fs will automatically put lost chains : in lost+found directory on the floppy as at least some form of : protection. This is (and long filenames) are the main reasons why : right now my archive floppies are in ext2 format. : Could somebody suggest which filesystem to use for the purpose of : archiving (maybe mke2fs with '-m 0' option so I use all of the disk)? I think mkisofs -R (iso9660 with Rockridge) is perfect for this. You could even mount this on other OS's.... sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@lig.net CIS 76244.210@compuserve.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 GNU Support ICBM: 39 34N 85 15W I love it when a plan comes together ------------------------------ From: mps@colmiks.com (Mike Sperry) Subject: Re: newuser shell script (w/ code) Date: Fri, 12 Nov 1993 16:59:45 GMT semi@dream.nullnet.fi (Sami-Pekka Hallikas) writes: >Here is my scripts for newusers.. hope that helps >---- Start ---- >#!/bin/bash >defgroup=100 [stuff deleted] You forgot "stty -isig", to prevent users from doing control-c in the shell (unless it is done in /etc/profile?). Mike uunet!colmiks!mps (don't pay attention to my headers...yet) ------------------------------ Crossposted-To: comp.os.linux.development 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: pcc@s1.gov (Philip C. Cox) Subject: How to get rid of colors Date: 12 Nov 1993 13:39:22 -0800 I just installed Slack 1.1.0 and I was introduced to ncurses and those blasted colors. My question is ; How do I get it to not display files on colors, or how can I change the colors? Phil -- Philip C. Cox | L.L.N.L. 7:^) E-Mail: pcc@s1.gov | P.O. Box 808 L-287 Livermore, CA 94550 ------------------------------ Crossposted-To: comp.os.linux.development 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: danh@teleport.com (Dan Haskell) Subject: Tunable parameters Date: 12 Nov 1993 13:46:43 -0800 Is there a way to set the ammount of system resources a user is allowed to allocate. Under SCO, for example, an administrator can set values for maximum user memory (MAXUMEM) and the like (I don't remember the others). Are there equivalent parameters for Linux. *Does* Linux place limits on a user's memory or CPU allocation? What I'm shooting for is a way to configure my system so a single user can run a very large real time application efficiently. I have read about the SVR4 priocntl command (which sounds like it would be helpful), but it is not provided under Linux. Does anyone have suggestions or relevant information? Please note that I have not yet been able to port the application - I'm just thinking ahead... -- "Plague and pestilence stalk the land like two huge stalking things!" - Black Adder III danh@teleport.com Public Access User --- Not affiliated with TECHbooks Public Access UNIX and Internet at (503) 220-0636 (1200/2400, N81) ------------------------------ From: jacobsd@heart.cor.epa.gov Crossposted-To: comp.os.linux.development Subject: Re: Berkeley Fast Filesystem Date: 12 Nov 1993 23:46:46 GMT In wayne@backbone.uucp (Wayne Schlitt) writes: >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. I don't think this is right. Page 199 of "Design and Implementation of 4.3 BSD" says: On a filesystem with a block size of 4096 bytes and a fragment size of 1024 bytes, a file is represented by zero or more 4096-byte blocks of data, possibly plus a single fragmented block. ... If the file needs to be expanded, the request is rounded up to the next fragment size and only that much space is allocated. Many small write requests may expand the file one fragment at a time. The problem with expanding a file one fragment at a time is that data may be copied many times as a fragmented block expands to a full block. Fragmentation reallocation can be minimized if the user process writes a full block at a time, except for a partial block at the end of the file. The single fragmented block can contain 2, 4, or 8 fragments. The file could be 42k long, but that assumes there is a fragmented block around with 2k worth of free fragments (or zero so we make a new fragmented block). Efficiency suffers, but that's the whole point of fragmented blocks to begin with -- trade off efficiency of time versus space. I don't really like the idea of having to do my own buffering to get the best performance however. This doesn't mean that I agree that BSD FFS is the best to shoot for, however. Keep up the discussion -- I'd like to see more filesystem innovations get tried on the smaller systems (Linux, *BSD) where we can look at them, instead of only reading someone's paper about their one- shot implementation. -- Dana Jacobsen jacobsd@solar.cor2.epa.gov Computer Sciences Corp. "Reading the Bible straight through is at least 70 percent discipline, like learning Latin. But the good parts are, of course, simply amazing. God is an extremely uneven writer, but when He's good, nobody can touch Him." -- John Gardner, NYT Book Review, Jan 1983 ------------------------------ ** 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-Admin-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.admin) via: Internet: Linux-Admin@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-Admin Digest ******************************