From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Fri, 12 Nov 93 07:13:42 EST Subject: Linux-Admin Digest #151 Linux-Admin Digest #151, Volume #1 Fri, 12 Nov 93 07:13:42 EST Contents: Laptop networking (Maxim Matveev) Re: Berkeley Fast Filesystem (Ian McCloghrie) SLIP FAQ (Debi Reid) Re: Laptop networking (scion@netimage.com) Can I recover form partition table loss? (Yavuz Onder) Re: SunService Supports WEITEK / UFC Crypt (Alec Muffett) Re: Berkeley Fast Filesystem (Joachim Hoenig) Re: Can I recover form partition table loss? (Joachim Hoenig) Re: SLIP: *Almost* working (David Taylor) Re: Berkeley Fast Filesystem (Herb Peyerl) filesystem for archive disks (Davor Cubranic) MS-DOS font for X? (Holger Muenx) Re: Berkeley Fast Filesystem (Wayne Schlitt) Re: Berkeley Fast Filesystem (Piercarlo Grandi) ---------------------------------------------------------------------------- From: mmatveev@boi.hp.com (Maxim Matveev) Subject: Laptop networking Date: Wed, 10 Nov 1993 21:24:22 GMT Hi, Does anybody can give me an advice about Linux networking and laptop parallel port Ethernet adapters. Sure, I've saw smth about D-Link pocket adapter, but all my efforts to find it was in vain. So how about Xircom or smth other? Thanks in advance, Max ================================================================== Max Matveev mmatveev@hpbs669.boi.hp.com (208) 396-7900 (work) (208) 385-9103 (home) ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Subject: Re: Berkeley Fast Filesystem Date: 10 Nov 93 21:13:18 GMT > Reading O'Reilly's "Essential System Administration" (Nutshell serie), >on page 250 of my edition it talks about the BSD Fast filesystem. Compared >to the "Traditional System V filesystem", it sounds quite impressive. I >was wondering where ext2fs stands in comparison to these two? These days, virtually everyone is using an FFS-style filesystem. SVR4's ufs does the same sorts of things, and I'm fairly sure ext2fs does as well. Not positive, but fairly sure :) Now, it would be nice to have an _actual_ BSD FFS for linux, so that one could communicate between the BSD du jour and linux, using something other than DOS :) -- /~> 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: dreid@mailer.cc.fsu.edu (Debi Reid) Subject: SLIP FAQ Date: Wed, 10 Nov 1993 21:30:57 GMT I looked several places (sunsite, tsx-11, etc) but could not find and FAQ's on SLIP via dialup. I remember seeing them port up in serveral inet news linux areas. Could someone mail this FAQ or point me in the right direction? ------------------------------ From: scion@netimage.com Subject: Re: Laptop networking Date: 10 Nov 1993 22:33:45 GMT Reply-To: scion@netimage.com Max Matveev writes: I've saw smth about D-Link pocket adapter, but all my efforts to find it was in vain. Call D-Link at: (714) 455-1688 in the US (081) 203-9900 in the UK 6196-643011 in Germany (416) 828-0260 in Canada (02) 916-1600 in Taiwan (This is from their ad in _LAN TIMES_ ) When I called thei US number, they were very helpful in finding a distributor for me. They even offered to sell me a new multi media adapter which was not in the distribution channel yet. -sam ------------------------------ From: yavuz@bnr.ca (Yavuz Onder) Subject: Can I recover form partition table loss? Date: Wed, 10 Nov 1993 22:16:44 GMT I have left to my son to patch the DOS 6 with 6.2 disks, and he must have done something wrong with fdisk there, so that now I do not see my linux partition on the disk any more. My (IDE) disk was divided into 4 partitions, 40 M DOS, 50M DOS, 16M Linux Swap, and the rest (approx. 145M) Linux Root. Now only the first two are there, both MS-DOS and Linux fdisks show only them. Their starting locations and sizes match to what they were before, which makes me think that if I could patch-up the partition table, i would be able to take my Linux Root Partition back... It is likely that I may not be able to find my notes, about the starting addresses of two missing partitions, which will make my task difficult at best, but I hope not impossible. Please give me any and all advice/suggestions you have. I do not have e-mail but a friend of mine "hilmi@bnr.ca" accepted to receive and forward any input on this. Please post or e-mail, as you see fit... Thanks * (10 ^ 6) -- -- Yavuz Onder | Bell-Northern Research Ltd. | My opinions aren't (613)-763-2294 | P.O. Box 3511 Station C | necessarily BNR's, yavuz@bnr.ca | Ottawa, Ont. CANADA K1Y 4H7 | or vice versa. ------------------------------ From: alecm@uk-usenet.uk.sun.com (Alec Muffett) Crossposted-To: comp.sys.sun.hardware,comp.sys.sun.admin,comp.security.unix Subject: Re: SunService Supports WEITEK / UFC Crypt Date: 11 Nov 1993 10:16:28 GMT Reply-To: alecm@uk-usenet.uk.sun.com In article 2bqebjINNdhf@galaxy.uci.agh.edu.pl, szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes: >Robert Plamondon (robert@weitek.COM) wrote: >: In article <2bdr8h$bc6@newserv.ksu.ksu.edu> rjq@phys.ksu.edu (Rob Quinn) writes: >: >I just read that article. I hope I can talk my boss into shelling out some $$. >: >The one benchmark I didn't see was.... >: >How many ufc-crypts per second do you get on a Weitek chip? Anyone? >: I don't even know what a ufc-crypt is, or I'd measure it for you. >ufc-crypt (Ultra Fast Crypt) is an implementation of crypt(3) function, >by Michael Glad , several times faster than the original >implementation, thus very useful with Alec Muffet's Crack. If anyone can get the figures on this, I'd *love* to know. It's not a particularly USEFUL benchmark except to people who want to use Crack, but then, I have a vested interest. 8-) 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 I was interested to find that my PC at home (Dell EISA 486dx2/66 running Linux) can just about match the SS2's performance, but only in erratic bursts (ie: speedf returns empirical values: 1000, 1050, 1100, 950, 1200, 1280, 1100, 1100, 1050, 850...) I can't be bothered to do a proper statistical evaluation on it. The SS2 is a more constant 1240 +/- 10 or thereabouts. For those who are interested, Eric Young's "libdes" clocks closer to 1400eps on a SS2 but has not (yet) got the same level of plug-in-and-play compatibility with Crack, that UFC has. Also, on Linux, if you use UFC in it's incarnation as the stdlib crypt() in libc.a, rather than obtaining a fresh copy and compiling it into Crack statically, you *LOSE* up to 200eps, presumably due to interrupts cause by the shared-library interface. - alec ------------------------------ From: hoenig@immd3.informatik.uni-erlangen.de (Joachim Hoenig) Crossposted-To: comp.os.linux.development Subject: Re: Berkeley Fast Filesystem Date: Thu, 11 Nov 1993 10:45:39 GMT imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >> Reading O'Reilly's "Essential System Administration" (Nutshell serie), >>on page 250 of my edition it talks about the BSD Fast filesystem. Compared >>to the "Traditional System V filesystem", it sounds quite impressive. I >>was wondering where ext2fs stands in comparison to these two? ext2fs does not yet support fragments (at least as far as I know). > These days, virtually everyone is using an FFS-style >filesystem. SVR4's ufs does the same sorts of things, and I'm fairly >sure ext2fs does as well. Not positive, but fairly sure :) ufs IS BSD-FFS (at least as far as I know). > Now, it would be nice to have an _actual_ BSD FFS for linux, >so that one could communicate between the BSD du jour and linux, using >something other than DOS :) It looks to me as if the linux superblocks have to contain some additional information about file sytem type etc. So I think it would require some major restucturing of the fs code to have a linux-BSD-FFS be compatible with ???BSD or SunOS. And there might be a problem with sector sizes and inode types. With some reverse engineering the NetBSD file system utilities like tunefs, newfs and fsck compile nicely on linux, though. Crossposted to comp.os.linux.development, maybe someone there knows more about this? Joachim ------------------------------ From: hoenig@immd3.informatik.uni-erlangen.de (Joachim Hoenig) Subject: Re: Can I recover form partition table loss? Date: Thu, 11 Nov 1993 10:59:53 GMT yavuz@bnr.ca (Yavuz Onder) writes: >I have left to my son to patch the DOS 6 with 6.2 disks, and he must >have done something wrong with fdisk there, so that now I do not see >my linux partition on the disk any more. >My (IDE) disk was divided into 4 partitions, 40 M DOS, 50M DOS, 16M >Linux Swap, and the rest (approx. 145M) Linux Root. Now only the first >two are there, both MS-DOS and Linux fdisks show only them. Their >starting locations and sizes match to what they were before, which >makes me think that if I could patch-up the partition table, i would >be able to take my Linux Root Partition back... >It is likely that I may not be able to find my notes, about the >starting addresses of two missing partitions, which will make my task >difficult at best, but I hope not impossible. >Please give me any and all advice/suggestions you have. I do not have >e-mail but a friend of mine "hilmi@bnr.ca" accepted to receive and >forward any input on this. I had about the same thing, with the last two logical partitions messed up in the partition table. I just linux-fdisked the partition table to the previous values and got everything working again. As simple as that. I hope it works for you, too. Joachim ------------------------------ From: ddt@daisy.cc.utexas.edu (David Taylor) Subject: Re: SLIP: *Almost* working Date: 11 Nov 1993 06:34:11 -0600 Thank you for your ARP solution! I have a follow-on question regarding SLIP. Our company is small and has a single class C subnet assigned to it (254 addresses- the lower byte basically). There is no way we'll ever need 254 SLIP lines, so it is unreasonable to ask for a new subnet wasting 254 addresses on a handful of SLIP lines. I want to subnet our net down to say, 6 SLIP lines, say for instance what would normally be host addr's 249 to 254. If I set my netmask appropriately (255.255.255.248), should I expect any complications? (like the ones i'm getting, although i haven't tried the arp sugg yet) Thanks for any suggestions. Has anyone else tried subnetting at this fine a granularity? Does anyone else feel guilty about raping 254 addresses for a SLIP line? =-ddt-> ------------------------------ From: hpeyerl@novatel.ca (Herb Peyerl) Crossposted-To: comp.os.linux.development Subject: Re: Berkeley Fast Filesystem Date: 11 Nov 1993 18:21:44 GMT 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... -- hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | ------------------------------ From: cubranic@whale.st.usm.edu (Davor Cubranic) Subject: filesystem for archive disks Date: 11 Nov 1993 19:03:13 GMT Since I don't have a tape drive (and don't have much chance of buying one anytime soon) and do have a stack of HD floppies, I'm using floppies for archiving software packages I get on internet. For example, I FRP some GNU stuff at the computer lab, take it home, install it on my Linux machine, and have it at the same time archived should I need to reinstall it. The question I have is which filesystem should I use on those floppies: with msdos I can't have long filenames, but with 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)? -- Davor Cubranic cubranic@whale.st.usm.edu ------------------------------ From: muenx@heike.informatik.uni-dortmund.de (Holger Muenx) Crossposted-To: comp.windows.x,comp.os.linux.misc Subject: MS-DOS font for X? Date: 11 Nov 1993 18:18:05 GMT Guten Tag! Is there any font for X which resembles the font used in text mode in MS-DOS? The idea behind this on first glance somewhat barbarian question is the following: I'm using Seyon, a terminal programm for Linux, which uses xterm as terminal emulation. When I call a BBS running on a MS-DOS machine lots of it's output gets unreadable due to different graphic characters. Any information will be appreciated. Thank you for your help! Holger Muenx (muenx@heike.informatik.uni-dortmund.de) ------------------------------ Crossposted-To: comp.os.linux.development From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Berkeley Fast Filesystem Date: Thu, 11 Nov 1993 20:42:59 GMT In article <2bt54jE3er@uni-erlangen.de> hoenig@immd3.informatik.uni-erlangen.de (Joachim Hoenig) writes: > imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: > >> Reading O'Reilly's "Essential System Administration" (Nutshell serie), > >>on page 250 of my edition it talks about the BSD Fast filesystem. Compared > >>to the "Traditional System V filesystem", it sounds quite impressive. I > >>was wondering where ext2fs stands in comparison to these two? > > ext2fs does not yet support fragments (at least as far as I know). 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? On average, you will waste about half of the last block allocated, unless you make the block size _way_ too big and most files fit in less than one block, in which case you will waste more than half. 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. If you make the block size too small, then too much space will be wasted keeping track of the blocks. So, the allocation unit should probably be somewhere around 1k, maybe as small as 256, maybe as large as 4k. 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. 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. Typically, 8k-128k should be read at one time, if you detect that the file is being read sequentially. If it is being read randomly, then read the smallest amount possible. The old Version 7 file system used 512 byte blocks, which is great for an allocation size, but horrible for a disk access size. 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. 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. So, what is the solution? Well, allocate things using a 512-2k blocksize, and read/write _many_ blocks at one time. This is known as clustering. It works better than the FFS and the code is simpler to boot. 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. While the Berkeley FFS was much better than the Version 7 file system, it is far from being an ideal filesystem. -wayne ------------------------------ From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Berkeley Fast Filesystem Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Thu, 11 Nov 1993 19:41:35 GMT >>> On 10 Nov 93 21:13:18 GMT, imcclogh@cs.ucsd.edu (Ian McCloghrie) said: Ian> Now, it would be nice to have an _actual_ BSD FFS for linux, so Ian> that one could communicate between the BSD du jour and linux, using Ian> something other than DOS :) Tar floppies/tapes? That's how one communicates between any two Unix machines as a rule. Using filesystem structured floppies/removable cartridges seems rather pointless... ------------------------------ ** 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 ******************************