From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Sat, 13 Nov 93 13:15:02 EST Subject: Linux-Admin Digest #154 Linux-Admin Digest #154, Volume #1 Sat, 13 Nov 93 13:15:02 EST Contents: Permissions for communications programs? (Jason Robertson) Re: Berkeley Fast Filesystem (Keith Smith) Re: Berkeley Fast Filesystem (Theo de Raadt) Network reliability? (Lawrence Foard) Re: Debugger wants libc source?! (Bruce Thompson 295-5967(w or 229-3370(h))) Re: How to get rid of colors (Zeyd M. Ben-Halim) authd/pidentd (Chuck Fee) Re: MS-DOS font for X? (Savio Lam) Re: Berkeley Fast Filesystem (Piercarlo Grandi) Re: Berkeley Fast Filesystem (Piercarlo Grandi) Re: Berkeley Fast Filesystem (J. Dean Brock) ---------------------------------------------------------------------------- From: jroberts@ux4.cso.uiuc.edu (Jason Robertson) Subject: Permissions for communications programs? Date: 13 Nov 1993 00:08:25 GMT Can somebody please send me a quick message about what my settings should be on communications-related files? I am having problems with Seyon under X and minicom under tty. Sometimes it says the modem device "/dev/modem" (which is linked to /dev/cua1) is locked, when there are actually no other programs running it. Sometimes, the program just sits there trying to locate the modem for awhile until I just give up. root has some luck running it, but any other account can only use it about 1/2 the time. Summary: settings on Communications program itself settings on /dev/modem,/dev/cua1 (by settings, I mean file permissions) Thanks you for any help. -- Jason Robertson jroberts@uiuc.edu Legalize it. ------------------------------ Crossposted-To: comp.os.linux.development From: keith@ksmith.com (Keith Smith) Subject: Re: Berkeley Fast Filesystem Date: Sat, 13 Nov 93 04:12:08 GMT In article <2bv87n$724@pdq.coe.montana.edu>, Nate Williams wrote: >Most of the 'lying' is required because of MS-DOS's 1024 cylinder limit. Actually, Most if the lying is due to the use of ZBR and other fancy tricks to squeeze more data onto the disk. The IDE's and SCSI's you get do NOT have a consistant number of sectors on a given track. Generally speaking there are more sectors on the outside tracks and fewer on the smaller inside tracks. Additionally space is reserved for bad blocks all along the way. 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. -- Keith Smith keith@ksmith.com 5719 Archer Rd. Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201 Somewhere in the Styx of North Carolina ... ------------------------------ From: deraadt@fsa.ca (Theo de Raadt) Crossposted-To: comp.os.linux.development Subject: Re: Berkeley Fast Filesystem Date: 12 Nov 93 21:12:12 In article <1993Nov13.041208.1947@ksmith.com> keith@ksmith.com (Keith Smith) writes: Generally speaking there are more sectors on the outside tracks and fewer on the smaller inside tracks. Additionally space is reserved for bad blocks all along the way. 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. There are still drives with which this optimization is beneficial. A good idea is to leave the geometry sensitive code intact, but only use it if the geometry is known (ie. # of sectors/tracks/heads). If the geometry is not known, then the disk is just a sequence of blocks. For what it's worth, I run with ESDI drives and think the geometry sensitive code helps performance and placement. ------------------------------ From: entropy@world.std.com (Lawrence Foard) Subject: Network reliability? Date: Sat, 13 Nov 1993 06:31:32 GMT How good or bad have the latest versions of the net stuff turned out to be on the internet? I'm at the point where I need to start hooking a number of Linux machines up with TCP/IP and do very large high speed file transfers. The owner of the company keeps asking if we shouldn't be switching to BSD since it has functional networking. BTW- Has anyone hacked sockets that work by calling KA9Q for Linux? -- ====== Legalize: >==--< | have given us jacks. . . \ / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day. . . . \/ The true theory of everything will run on a finite turing machine. . . . ------------------------------ Crossposted-To: comp.os.linux.development From: thompson@indigo.cuug.ab.ca (Bruce Thompson 295-5967(w) or 229-3370(h)) Subject: Re: Debugger wants libc source?! Date: Sat, 13 Nov 1993 05:50:42 GMT In article <2be9at$p5m@fbi-news.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: Guten Tag! Unfortunately, while debugging various pieces of code, I really that my debuggers -- gdb and ups -- demand the sources of libc when libc calls, like printf or whatever, are reached. I can pass it by using "next" instead of "step"ping into the call. However, it's not very comfortable. Moreover, I always get a disturbing little "beep" for each call with a missing source. My libs are from image-4.4.1.tar.gz (or so) from the GCC directory on sunsite. So: what I am doing wrong? Thank you in advance! Any information will be appreciated! Holger Muenx (muenx@heike.informatik.uni-dortmund.de) What are you doing wrong? Nothing. The behavior you're describing is correct, assuming that the libraries you are referring to were compiled with debugging enabled. The debugger is assuming that since you stepped into the library routines, you want to debug them. That is, after all, what the step command is for. The debugger `should' step completely over any routine that is not compiled for debugging unless you specify to step to the next machine instruction. If you have the sources for libc, I'd recommend that you recompile them without debugging, not to mention turning optimization on. If you don't have the sources, I'd suggest looking into finding a libc that is nott compiled with debugging on. In the mean time, here are a couple of things you can do once you've stepped into a routine you don't have source for: 1) Try the `continue -return' command (I think that's it). Check the gdb manual for more info, but I believe there's an option to continue that means continue until this routine is exited. 2) Move up one stack frame and set a one time breakpoint on the next line after the call you're currently in. Hope this helps some. I'd check my own system, but I don't yet have it. Cheers, Bruce. -- Bruce Thompson, |I do not speak for CUUG, ACTC Technologies, Software Development Engineer,|Renegade Legion nor NAPRA, just myself. ACTC Technologies Inc. |"So this is it, we're going to die!" Renegade Legion, NAPRA #473 | -- Dent Arthur Dent -- Bruce Thompson, |I do not speak for CUUG, ACTC Technologies, Software Development Engineer,|Renegade Legion nor NAPRA, just myself. ACTC Technologies Inc. |"So this is it, we're going to die!" Renegade Legion, NAPRA #473 | -- Dent Arthur Dent ------------------------------ From: zmbenhal@netcom.com (Zeyd M. Ben-Halim) Subject: Re: How to get rid of colors Date: Sat, 13 Nov 1993 04:51:01 GMT In article <2c0vqa$872@s1.gov> pcc@s1.gov (Philip C. Cox) writes: >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? Please don't blame ncurses for the color output of ls, ncurses has NOTHING to do with it. Check your man page for ls. Zeyd >Phil >-- >Philip C. Cox | L.L.N.L. 7:^) >E-Mail: pcc@s1.gov | P.O. Box 808 L-287 Livermore, CA 94550 -- --- Zeyd M. Ben-Halim zmbenhal@netcom.com 10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281 ------------------------------ From: fee@cxf111.rh.psu.edu (Chuck Fee) Subject: authd/pidentd Date: 13 Nov 1993 10:36:01 GMT Has anyone successfully compiled authd or identd for Linux? I had marginally more success with pidentd (ie it compiled 3 files before it puked rather than 0) but I'm lost when it comes to kernel access. Pidentd access the kernel for determining which user is connected to the remote host, while authd uses netstat. with pidentd, Operating systems already supported (sunos, 386bsd, hpux, etc) all have a single .c file for accessing kernel structures. The other.c file is not well suited for linux (it expects bsd header files for one thing) and the scope of doing the kernel stuff is over my head. From what I gather, it would seem the proc filesystem provides all the necessary hooks for extracting the information pidentd is looking for. any help will be greatly appreciated. If you've managed to get either of these working, please drop me a line. btw, the source for both of these is available at ftp.uu.net:/networking/ident/servers -- Chuck Fee If we pass NAFTA, Software Patents become fee@cxf111.rh.psu.edu entwined in International Law. ------------------------------ Crossposted-To: comp.windows.x,comp.os.linux.misc From: lam836@cs.cuhk.hk (Savio Lam) Subject: Re: MS-DOS font for X? Reply-To: lam836@cs.cuhk.hk Date: Sat, 13 Nov 1993 11:37:04 GMT Holger Muenx (muenx@heike.informatik.uni-dortmund.de) wrote: > 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! Try look into sipb.mit.edu:/pub/seyon/MISC. There is a font that includes IBM graphics characters and an ANSI compatible xterm (color xterm is not 100% compatible with ANSI emulation, causing messy screen) also. You can also grab your BIOS's fonts and convert it into an X font using evafont.exe (a DOS based font editor) in the following package: sunsite.unc.edu:/pub/Linux/utils/nls/LinuXinterDOS.tar.z Hope this helps. Regards, Savio Lam. -- ############################################################################### # | _ # # ------------------------------- | _| |_ # # Lam Lai Yin, Savio | |_ _| # # | | | # # Internet: lam836@cs.cuhk.hk | / \ Can't live with DOS? # # Department of Computer Science | | DOS | # # Chinese University of Hong Kong | | | Try Linux... # # ------------------------------- | | | # # | ^^^^^^^^^^^^^ # ############################################################################### ------------------------------ 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: Sat, 13 Nov 1993 14:07:07 GMT >>> On 12 Nov 1993 05:49:26 GMT, nate@bsd.coe.montana.edu (Nate >>> Williams) said: [ ... on the issue of BSD FFS vs. The World ... ] Nate> Right. When you read in block-at-a-time mode, you can only read Nate> the blocksize value at a time. True in the BSD FFS; in general this is rather inaccurate. You can read ahead/write behind as many blocks as you want (transfer clustering). If such blocks are laid out contiguously on the disk (allocation clustering) and memory (if you controller supports scatter/gather there is no need for contiguousness in memory), then you need only issue one IO operation to transfer them all. If your controller cannot transfer multiple blocks in one operation, then large fixed block sizes are pointless too, because most disks are sectored to 512B (more rarely 1KB), and thus transferring a single block would still require multiple IO operations. Nate> The larger the blocksize, the more data you read at one time. Yeah, and this can be a big problem too. A large blocksize implies a _fixed & synchronous_ large readahead and writehind factor. If you are not doing sequential accesses this is a big loss, and it is a big loss also if you do sequential transfers at low speed because the application is CPU bound. A large fixed blocksize is also a big loss if you can only allocate full sized blocks in memory, as then you will waste a lot of it. >> 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. Nate> ??? This is irrelavant to the file-system, and is a problem with Nate> your buffer code being overly agressive. If the filesystem code specifies a large fixed blocksize, then that is an effective minimum level on the aggressivity of the buffer code. The classic BSD FFS will only transfer blocks in their entirety, and cannot do partial block transfers for any reason. Nate> ??? 8K isn't large enough to get really good throughput. Let's Nate> see some numbers to back that up. I get VERY good performance Nate> using an 8K/2K BSD-FFS with the 486/33. (1.5MB/sec reading and Nate> 1MB/sec writing w/out any hardware cache on a 486/33 ISA box. On Nate> EISA boxes I've seen numbers in the upper 2's and 3's) The issue of clustering has been discussed in this newsgroup only last week (last month there was a discussion in comp.arch.storage). Eric Youngdale was under the same mistaken impressions as other people in this newsgroup... I kindly rectified them :-), both in this newsgroup and in an email conversation, and as a consequence he has done some nice dynamic clustering mods to the Linux IO subsystem, which don't change the block size away from 1KB. He reports that such mods give the performance you report above, with an unmodified ext2 fs. Amazing facts! I have found he has put them up for BETA testing on funet and its mirrors under ".../BETA/scsi/cluster-04.tar.gz". Try them out... ------------------------------ 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: Sat, 13 Nov 1993 14:29:04 GMT >>> On Fri, 12 Nov 1993 14:45:51 GMT, wayne@backbone.uucp (Wayne >>> Schlitt) said: >> 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. Wayne> If the overhead of reading one block at a time is large enough, Wayne> you won't be able to read consecutive sectors. Nitpicking: yes, but many modern interfaces can; in particular because the disk drive itself normally reads ahead a full track. So the issue is less important. Besides, the loss of performance need not be total; interleaving (which is what the BSD FFS amounts to, BTW) is better than waiting the next revolution for the next block. >>> 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. Wayne> how much data should be read at one time depends on how much free Wayne> memory you currently have. If you have 1MB of free memory, go ahead Wayne> and read 128k. If memory is tight, only read 8k... This is something Wayne> that can't be accurately guessed at when you are building the file Wayne> system. You should check it at run time. This is an hypothesis that I made in the comp.arch.storage discussion, but I must for honesty report that there are also reasons to think that is is as big a win. The main reason is given in Knuth, Vol. 1; if the bandwidth consumed by the program is systematically less than or greater than the bandwidth offered by the peripheral, a lot of buffering does not buy you a lot, simply because one of the two will end up waiting for the other more often than not. If the two are bandwidth matched, two buffers will suffice. The size of each buffer though, that is the transaction size, will have an important impact though if it is _too small_: where too small means that the cost of setting up its transfer is a significant fraction of the cost of transferring or processing it. Then I think that the optimal transfer size is that transfer size for which the setup time is 10% of the smaller of the time needed to transfer it, or to process it. This does not necessarily depend on how much free memory you have got: doing a large cluster to get overheads from 10% to 5% might be a boon, but it is not vital, even if you have lots of free memory; and if you have too little memory, a cluster size that gives you an incidence of overheads greater than 10% is too small. Wayne> It was my understanding that framents were used only when the Wayne> entire file was 1k or less, but you may be right that it is used Wayne> for the tails of all files. He is right... Wayne> I am fairly sure that you can't uses multiple fragements though, Wayne> so a 42k file would not be able to use 2 fragements. Indeed: the fragment is only used the tail. However, if only for the tail, the existence of fragments means that one either has to implements two sizes of incore blocks, and this complicates memory allocation unless one can play tricks with VM, or just one incore block size (the larger...) and this wastes lots of memory. Wayne> Note, that I didn't say that 8k would get really bad throughput, Wayne> just that reading an entire track at a time can get better Wayne> performance than reading just 8k. No necessarily: only if you are reading sequentially, and (blah blah). Also, there is an impact on latency even when sequential access is involved: reading a track at a time means that you cannot start processing the 1st block of a track until the last has arrived (several milliseconds). Dynamic clustering avoid this entirely: perhaps all blocks in a track get transferred, but individually, so (at least in principle) as soon as the first has been transferred it can be processed. Wayne> Basically, my point was that fragments get you nothing that just Wayne> clustering reads and writes can't also get you. Clustering is Wayne> simpler to implement, wastes less disk space and can get even Wayne> better performance. This was all discussed recently in Wayne> comp.arch.storage... Yeah, and on these screens to. See my comments on Nate's own article. ------------------------------ From: brock@cs.unca.edu (J. Dean Brock) Crossposted-To: comp.os.linux.development Subject: Re: Berkeley Fast Filesystem Date: 13 Nov 1993 15:19:42 GMT In article 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. OK, OK. Everybody. Pull out your copy of The Design and Implementation of 4.3BSD Unix Operating Systems and read how fragments are really allocated before posting any more messages on this topic. Files CAN use multiple fragments. A 42k file WILL consist of 8 full blocks followed by 2 fragments. ------------------------------ ** 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 ******************************