From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Mon, 15 Nov 93 08:13:22 EST Subject: Linux-Admin Digest #156 Linux-Admin Digest #156, Volume #1 Mon, 15 Nov 93 08:13:22 EST Contents: Re: filesystem for archive disks (Karsten Steffens) Re: Slackware 1.1.0 is good! (Eric W. Sink) lpfilter (Leo Staschover) Re: Berkeley Fast Filesystem (Piercarlo Grandi) Re: Berkeley Fast Filesystem (Ian McCloghrie) Re: XFLOW PROBLEM: HELP! (Mike Horwath) Re: lpfilter (hkennedy@mercury.ncat.edu) Re: filesystem for archive disks (Jogid) Wampes on Linux ..... some problems (Giuseppe Martoni) ---------------------------------------------------------------------------- From: karsten@kshome.ruhr.de (Karsten Steffens) Subject: Re: filesystem for archive disks Date: Sun, 14 Nov 1993 10:09:58 GMT Davor Cubranic (cubranic@whale.st.usm.edu) wrote: : 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)? You say it yourself. mke2fs -m 0, or to change an already filled up floppy, tune2fs -m 0 will do the same. Although I suggest this, I myself prefer raw-written floppies ( tar cvf - > /dev/fd0 ) to create archives. Sure, I admit that I don't then have the lost+found capabilities, but I can take my archives over to SUNs without any trouble. Regards, Karsten -- ==================> Karsten Steffens <===================== karsten@kshome.ruhr.de | steffens@ikp.uni-muenster.de Marl - close to Recklinghausen | Institut fuer Kernphysik North of the Ruhrgebiet | Westf.Wilhelms-Universitaet Muenster ------------------------------ From: eric@spyglass.com (Eric W. Sink) Subject: Re: Slackware 1.1.0 is good! Date: 14 Nov 1993 17:07:55 GMT Reply-To: eric@spyglass.com /* ENVY ON */ philp@universe.digex.net (Phil Perucci) writes: >Just installed Slackware 1.1.0 with ET4000 and NEC IID! >The new XFree86 2.0 is beautiful! Just a quick peek at Xconfig >and I was up. Easiest install yet! I have an ET4000 (Orchid ProDesigner II) and a NEC 3D, and have been fiddling with this thing for days with no luck. I read every man page and README.Config and the long documents on video displays and timing and such. I even printed them all out and took them home to study them. What I don't have yet is X working. SIGH /* ENVY OFF */ -- Eric W. Sink, Spyglass | "Why would anyone write obscure code | Opinions 1800 Woodfield Drive | ON PURPOSE?" | mine Savoy, IL 61826 | -Michael Peirce | only ---- eric@spyglass.com -------|---------- 217-355-6000 ext 237 ---------------- ------------------------------ From: leos@poly.edu (Leo Staschover) Subject: lpfilter Date: Sun, 14 Nov 1993 21:33:08 GMT can someone please email me (or mime me) a copy of "lpfilter" for a laserjet type printer? Thanks, Leo Staschover leos@poly.edu ------------------------------ Crossposted-To: comp.os.linux.development From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Berkeley Fast Filesystem Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Sun, 14 Nov 1993 22:39:17 GMT >>> On 13 Nov 1993 15:19:42 GMT, brock@cs.unca.edu (J. Dean Brock) said: J> OK, OK. Everybody. Pull out your copy of The Design and J> Implementation of 4.3BSD Unix Operating Systems and read how J> fragments are really allocated before posting any more messages on J> this topic. J> Files CAN use multiple fragments. No... J> A 42k file WILL consist of 8 full blocks followed by 2 fragments. No, it will consist of 5 8KB (always assuming an 8KB/1KB fs, instead of any other more or less plausible one) full blocks plus a 2KB fragment; a 2KB fragment is not just 2 consecutive 1KB fragments. Thus the 1KB (in an 8KB/1KB fs) usually mentioned as the "fragment size" is actually the "fragment granularity". The FSS must keep separate lists of free fragments for each of the 8 possible fragment sizes; if the list for the fragment size one need is empty, a full block (or a larger fragment) is broken in two; the two parts are added to the free list for the appropriate fragment size. There might well be many 1KB fragment free, but no 2KB fragment around. The same is true in memory, with the modifications to the availability of VM (if the VM page size is equal to the fragment granularity one only needs a single size of buffers, or perhaps two, as one can make virtually contiguous the granules of a fragment that are physically discontinuous). Just to bury once and for all all this nonsense about blocks and fragments, as if Eric Youngdale's work were not enough, I will mention here the really terrifying details of the consequences of the FFS fragmentation scheme on incore buffers -- if you are under 18 years of age, or you are impressionable, or suffer from a weak heart, don't read on. You were warned! Ok, most files grow by appending at the end of the file. Suppose the file size starts such it is an even multiple of 8. One byte gets written: the FFS buffer manager finds a 1KB buffer and puts the byte into it. Now 1024 bytes are appended. The buffer manager finds a 2KB buffer, and moves the byte in the old 1KB buffer, plus the new 1024 bytes, into it. Every time 1KB more are written, a buffer with the larger size is allocated, the contents of the previous buffer are moved to the new larger and so on. This sad thing happens for all blocks that make up a file, as they are filled they grow from a 1KB frgament to a full 8KB block (if ever), KB by KB. When the buffer that overflows is finally 8KB long, or the file is closed, space for it is allocated on disk, and it scheduled for writing to that space. If the space requested is a full 8KB long, a full block is allocated; if it is 1-7 KB long, the "free list" on disk for that size is searched; if it is empty, a larger fragment or a full 8KB block will be split; as in a 6KB free fragment being split into say one 4KB free and one 2KB newly busy ones. If you have VM pages that are <= 1KB then growing an N KB incore buffer into an N+1 KB buffer can be done without copying by changing page tables. If VM pages are large, as on a Sun3, for example, one might consider copying things around every time a block grows, which is impossibly expensive (for each 8KB written to a file, the first 1KB gets copied 7 times, the second 1B gets copied 6 times, and so on...). The alternative is to resort to using 8KB buffers thruout, which is is only very expensive, as many files are way smaller than 8KB, so the amount of memory devoted to buffers will be in general wasted for well over 50% of its capacity, but this for one thing did not trouble the Sun people, who has ensured that in general memory was over 50% wasted in internal fragmentation anyhow. Now does anyone see why a block/fragment scheme is crazily complicated? ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Crossposted-To: comp.os.linux.development Subject: Re: Berkeley Fast Filesystem Date: 14 Nov 93 21:06:06 GMT keith@ksmith.com (Keith Smith) writes: >Optimizing code _at the computer_ for disk geometry was an interesing >idea that should now be killed. One should now leave the low level data >movement optimizations to the DRIVE. Then a given drive can use it's >cache & knowledge of the drive makeup to optimize on a per drive basis, >probably much more efficiently than you could with the CPU. The obvious >benifits are simplifying filsystem code to block clustering. The problem with this idea is that while the disk controller knows everything about the disk, it doesn't know anything at all about the filesystem structure. Said fs structure information becomes necessary to do cylinder grouping, etc. If the OS can do cylinder/head/sector positioning, it can make much more intelligent choices about what to put where than the controller hardware can. Take as an example a filesystem doing striping in software, if the disk controller remaps your request to somewhere else on one drive, but not on the other, you've lose a lot of the benifit. -- /~> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta. < < /~\ |~\ |~> | | <~ | email: ian@ucsd.edu Net/2, USL 0! \_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club ------------------------------ From: root@jacobs.mn.org (Mike Horwath) Crossposted-To: comp.os.linux.help Subject: Re: XFLOW PROBLEM: HELP! Date: 15 Nov 1993 00:05:57 GMT Jeffrey A Stern (jstern@eclectic.ss.uci.edu) wrote: : This is REALLY VERY ANNOYING!!! I can't find any FAQ answer to this, and : both I and another fellow have posted, without any response. So ANYONE : who knows what's going on, would you please let this clueless guy in : on how to fix this??? [rest deleted] : Jeff Stern Sounds like your problem is with the machine you are calilng in with doing xon/xoff stuff for you. Use hardware handshaking and you should be fine. (also, make sure your modem is setup to do this also) -- Mike Horwath IRC: Drechsau BBS: Drechsau LIFE: lover root@jacobs.mn.org drechsau@jacobs.mn.org Jacob's Ladder 612-588-0201 UUCP, UseNet, Linux files, BBS ------------------------------ From: hkennedy@mercury.ncat.edu Subject: Re: lpfilter Date: Mon, 15 Nov 1993 03:59:32 GMT In article leos@poly.edu (Leo Staschover) writes: > >can someone please email me (or mime me) a copy of "lpfilter" for a laserjet >type printer? >Leo Staschover >leos@poly.edu > Could you please send me any information you have on setting up a laserjet (iip if possible)? I can't get a hp laserjet going for nothing. Thanks, hkennedy@ncat.edu ------------------------------ Subject: Re: filesystem for archive disks From: jprimros@galaxy.csc.calpoly.edu (Jogid) Date: Sun, 14 Nov 93 08:04:53 GMT Reply-To: jprimros@galaxy.csc.calpoly.edu In article <2bvn27$kfe@sun.rhbnc.ac.uk> karsten@lt8.cs.rhbnc.ac.uk ( Karsten Ballueder) writes: > >> >>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)? >> >Why use a filesystem for archiving? If you only want to save backups >in forms of tar-files, you can have it much easier with writing directly >to the disk, which will still work, if filesystems have changed during >time: > >e.g. > >fdformat /dev/fd0H1440 >tar cz[some other options]f /dev/fd0H1440 > >You can tar tell how much bytes to write to the disk (I don't remember >the right option at this time...) and so it writes exactly 1.44MB per >disk. This disk then is readable by all machines who support 1.44MB disks, >you don't need to care for the filesystem. Unfortunately, unless the man page for tar is wrong (imagine that :^), the 'z' option to compress the resulting tar file is incompatible with the option (and I don't remember which one it is either) that lets you specify the output file size... If it wasn't for that, I'd use tar by itself to back up my drive. As it is, I end up making a filesystem on the floppy (usually dos, so I don't have as much trouble remembering which floppy has which filesystem... Funny, I could have sworn I got rid of that problem when I stopped using my Atari... :^). >(You can use the 'dd' program in a similar way.) > > Ciao, Karsten > Jonathan ------------------------------ From: beppe@csr.unibo.it (Giuseppe Martoni) Subject: Wampes on Linux ..... some problems Date: Sat, 13 Nov 1993 14:59:23 GMT Hello, we have a 486 with a linux it's connected with a TNC an we wont possibly to use a Wampes for linux. I get it from ucsd.edu but it'dont go !!! I didn't know how to configure it. My you help me??? please post the reply via E-mail: beppe@csr.unibo.it Thanks in advance. Giuseppe Martoni. ------------------------------ ** 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 ******************************