lau@desci.wharton.upenn.edu (Yan K. Lau) (06/15/91)
We recently got some new hardware for our DECstation 5000/200. Most of the installation seems straight forward but I have a few of questions. I added two 8 meg memory boards. The memory shows up on the hardware test. What do I need to do to make the operating system aware of the new memory? I couldn't find any doc on this, maybe I'm not looking in the right place. I added 2 RZ57s in an expansion unit to the system. I ran MAKEDEV and newfs. The results were about 950megs total with 850megs available. Is this normal? I read somewhere that the system takes about 10% for (mumble...mumble). Is there a way to change this percentage, would one want to do this? We got an RRD42 CD drive that has the headphone jack and audio LR outs. Does anyone have software that can play music CDs on this drive? I think it's much nicer than the bulky RRD40(?). Oh, we also got Ultrix 4.2 recently. I only recently upgraded the systems to 4.1. and everything was working so well. Another thing, do you have to run lmf on each machine to install the licenses for each product. We only have a half dozen machines with one acting as the server(dms) for the others. Still, it was a bit tedious typing in all the information for each machine to register a product. There's probably a way to type it just once and reuse, no? Sorry if some of these questions seems simple. We've only recently gotten the sys admin doc set and I haven't plowed through all of it yet. Just thought of another thing. Is there a way to set up yellow pages without being a bind server? Sounds like a wierd question. What I want to do is have a common /etc/passwd, /etc/group files for our DECstations and still use our campus-wide name server. Yan. -- )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ Sheenaphile 128.91.11.233 University of Pennsylvania /\ God/Goddess/All that is -- the source of love, light and inspiration!
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (06/16/91)
In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes: > We recently got some new hardware for our DECstation 5000/200. Most of > the installation seems straight forward but I have a few of questions. > > I added two 8 meg memory boards. The memory shows up on the hardware > test. What do I need to do to make the operating system aware of the > new memory? I couldn't find any doc on this, maybe I'm not looking in > the right place. You boot the system. There's nothing special you need to do if the memory is correctly installed. Now if ULTRIX isn't seeing the memory when you boot the system, then you have a problem. Make sure the memory is in contiguous slots. You may also have problems if you're trying to mix the older 8 MB boards with the newer 32 MB boards. If the addition of the new memory takes you over 64 MB then you may want to change the "physmem" parameter in the configuration file, rebuild and boot the new kernel. The value is used to determine the page tables. It seems that only three values are interesting; less than a low water mark, above a high water mark and either side of 64 MB. For DECsystems the files of interest are in /sys/machine/mips/{genassym.c,vmparam.h}. > > I added 2 RZ57s in an expansion unit to the system. I ran MAKEDEV and > newfs. The results were about 950megs total with 850megs available. Is > this normal? I read somewhere that the system takes about 10% for > (mumble...mumble). Is there a way to change this percentage, would one > want to do this? This seems to be normal(*). The difference between the 850 and 950 is the 10% reserved free space. You can change this when you create the file system using the -m option of newfs(8) or later with the tunefs(8) command. You may not want to though, at least until you need to. Early studies of the Fast File System showed that block allocation started becoming slower when the file system was more than 90% full. On the other hand, not being able to allocate a block knowing that there really is free space, is more than a little inconvient. Use the 90% number as a indicator of when you need more disk space. The disadvantage of having the file system that full is that the performance may suffer. Blocks allocated to large files will be scattered all over the disk, instead being kept close together. Small files may also end being scattered all over. Keep the 10% in reserve and if you really need it later you can change it and start looking to get more space or clean up the existing space. If you're using the space for archival on-line storage that won't change much, then you should be able to set the minfree number to whatever is needed. If you're very careful about file placement and allocation the performance might not suffer to badly. I'd guess that you'd want to create the large files first and then do the small ones. (*) I looked around a bit and the RZ57 seems a bit strange. I'll discuss it in a seperate follow-up. > > We got an RRD42 CD drive that has the headphone jack and audio LR outs. > Does anyone have software that can play music CDs on this drive? I > think it's much nicer than the bulky RRD40(?). I know that some people internally have written software for it. All of it has been clearly marked "Internal Use Only", so it's not available to customers. I won't be surprised to see customer written software showing up shortly to do the same thing, if the documentation is reasonable. > > Oh, we also got Ultrix 4.2 recently. I only recently upgraded the systems > to 4.1. and everything was working so well. Read the V4.2 release novel (notes) to see if there is any particular feature or bug fix that you need. Please realize that in about six months the CSC will stop treating V4.1 as a supported version though. If you have a support contract the first words you hear in answer to a problem may be "Please upgrade to V4.mumble". Beyond that, upgrade when it's convient to do so. Now, if you start exercising some mysterious V4.1 bug, then the fix might be upgrade. > > Another thing, do you have to run lmf on each machine to install the licenses > for each product. We only have a half dozen machines with one acting as the > server(dms) for the others. Still, it was a bit tedious typing in all the > information for each machine to register a product. There's probably a way > to type it just once and reuse, no? If you have the PAK online you can use this to register it from a file: # lmf register - < PAK-file Once you've typed in all the LMF data and checksum stuff you may be able to save a copy of the that to a known file before exiting the editor. If you have DECnet installed then you may also be able to use the online PAK as a guide; /usr/lib/dnet_shared/{mumble-something-obvious}. > > Sorry if some of these questions seems simple. We've only recently gotten > the sys admin doc set and I haven't plowed through all of it yet. Please SPR or use the Reader Comments page to let us officially know about any problems you have with the documentation. > > Just thought of another thing. Is there a way to set up yellow pages without > being a bind server? Sounds like a wierd question. What I want to do is > have a common /etc/passwd, /etc/group files for our DECstations and still use > our campus-wide name server. I have many of the system I manage setup to use bind for the hosts and YP for everything else. Just use svcsetup to pick and choose. > > > Yan. > -- > )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School -- Alan Rollow alan@nabeth.cxn.dec.com
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (06/16/91)
In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes: > I added 2 RZ57s in an expansion unit to the system. I ran MAKEDEV and > newfs. The results were about 950megs total with 850megs available. Is > this normal? I read somewhere that the system takes about 10% for > (mumble...mumble). And I responded "This seems to be normal". Well, upon closer examination there's something funny about the RZ57 and perhaps all the DEC SCSI disks. Perhaps it's just an editing error on the part of whoever maintains /etc/disktab, but it none the less curious. From /etc/disktab we can discover that the size of the C partition of an RZ57 is 2,025,788 sectors or 989.15 MB. However if we look at the output of chpt -q we see that ULTRIX really believes there are only 1,954,050 sectors (954.13 MB). If we look at the geometry information in disktab then we get yet a third number. We are led to believe the RZ57 has 71 sectors per track, 15 tracks per cylinder and 1,925 cylinders. This give us 2,050,125 sectors or (1,001.04 MB). Now it might be that the 71 sectors per track includes a sector or two used for bad block replacement. Setting aside a sector on each track for a replacement block can make BBR go faster if you can get the LBN of the replacement block from the sector header. So this may mean that there are really on 70 or perhaps 69 sectors per track. It's also possible a couple of cylinders have been set aside for diagnostic use. Or it might be that we lie about the geometry in /etc/disktab for some reason. Ah, let try a different tact. How do the three different numbers factor into interesting values (*)? Disktab: 2025788 = 2 * 2 * 17 * 31 * 31 * 31 Chpt: 1954050 = 70 * 15 * 1861 Geometry: 2050125 = 71 * 15 * 1925 Now it gets more interesting. The value for the C partition makes no sense at all. It doesn't even divide up into an even number of 8 KB file system size blocks. We'll ignore it for now and submit an SPR later. The value for chpt(8) is much more interesting. If we assume that we keep the same number of surfaces for data, then we have a disk with 70 sectors per track and 1,861 tracks. We already have a plausible explaination for the 70 vs. 71. I guess the missing cylinders are cause for another SPR. If somebody has a better explaination I'd like to hear it. (*) Clearly, we don't want to completely factor the numbers, just find any factors that could part of a disk geometry. p.s. It's worth noting that this exercise tends to work out for DSA disks. We typically use one or two sectors on each track for BBR, but have the track size show up one or two shorter. The exception of which I know is the ESE20 that has 3 less sectors than the geometry indicates. The ESE20 is a solid state disk with a data retention system. The three sectors are used to construct an replacement control table to keep all the DSA disk controllers happy. -- Alan Rollow alan@nabeth.cxn.dec.com
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (06/16/91)
In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes: > I added 2 RZ57s in an expansion unit to the system. I ran MAKEDEV and > newfs. The results were about 950megs total with 850megs available. Is > this normal? I read somewhere that the system takes about 10% for > (mumble...mumble). And I responded "This seems to be normal". But where does all the space go you ask? Well, now that we have resolved the disk size (See "Lies, Damned Lies and ..."), we know just how much we have to begin with and can determine how much is lost to file system overhead. That's the key to it you see; file system overhead. Some file system space goes to superblocks, some to inodes and some to other stuff. For some disks this can be a signifi- cant percentage of the disk. We'll find for the RZ57 that it isn't very much. From the previous discussion we determine that whatever else WE might think about it, ULTRIX believes that an RZ57 has 1,954,050 sectors (977,025 KB). Doing a newfs(8) on an RZ57, letting it take the defaults we find that there are a total of 945,726 KB available, a loss of 3.2%. Looking at the RA82 as another example we find it has 608,332 KB which goes down to 584,102 KB for file system data, a loss of 3.98%. Where's the overhead? First, consider the file system structure. Each file system is made up of groups of cylinder. Each of these groups has it's own superblock, block of inodes, data space and cylinder group data. When left to the default each group consists of 16 cylinders. The first cylinder has a few more things thrown in to use up a little space. Here's a summary of the sizes of things on an RZ57: Bootblock: 8 KB (one only)(+) Superblock: 8 KB (one only) Backup Superblock: 8 KB (one per CG) Cylinder Group data: 8 KB (one per CG) Inodes: 256 KB (one per CG) From the previous discussion we might concluded that there were 1,861 cylinders on an RZ57. Looking at the output of newfs(8) it believes the 71 sectors per track which actually gives us 1835 cylinders (one a bit short). Taking the default of 16 cylinders per group this is 115 cylinder groups. The last one will be short, but have the same overhead. Working through the sizes of things we have: Bootblock: 8 KB = 8 KB Superblocks: 8 KB + (8 KB * 115) = 928 KB CG: 8 KB * 115 = 920 KB Inodes: 256 KB * 115 = 29,440 KB -------------------------------------------- 31,296 KB If we take the difference of chpt(8) size and the total file system size we find the result very close; 977,025 - 945,726 = 31,299 That's only three KB unaccounted for. You might think that it's best left a mystery; perhaps they end up in the same place with socks that go missing from dryers, but I think I know where they are. First, look at the original partition size; 977,025 KB. File systems are made up of File System size blocks of data. This is typically 8 KB. If we view the file system space as 8 KB blocks there are 122,128 of them with one little KB left over. That's the first one. Also included in the file system overhead of an RZ57 is something called the cylinder group summary. On the RZ57 with defaults this is 2 KB (trust me, really). So we have: 945,726 + 31,296 + 2 + 1 = 977,025 The mind boggles. Now, having been through the exercise what can we divine (it's getting late folks...)? The amount of space used up in overhead depends on the number of cylinder groups, which in turn depends on the number of cylinders. If a disk consists of very many small cylinders then lots of space gets used. One benefit of this is that you get lots of space for inodes. On some file systems this can be a big win (News disks for example). You can also control the amount of space used for overhead in various ways. There is a flag to newfs(8), passed onto mkfs(8) that controls the size of the inode part. By making this number greater than the default of 2048 you can allocate fewer inodes and therefore less space. With this comes the risk that you don't have enough inodes. If you KNOW that a disk will have only a few large files, then getting back a few dozen MB might be worthwhile. Another way to control the overhead is to lie about the geometry. Using a contrived (^) example of a disk with 69 sectors/track, 13 tracks/cylinder and 3,279 cylinders we might wish to lie and say it has 23 sectors/track, 13 tracks/cylinder and 9,837 cylinders. Or perhaps, 69 s/t, 39 t/c and 1,093 cylinders. Lying about the geometry might have other affects, but that is a topic for a performance project. (+) Actually there is one per file system of the "one only" blocks. (^) Well, maybe not contrived. -- Alan Rollow alan@nabeth.cxn.dec.com
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (06/16/91)
In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes: > I added 2 RZ57s in an expansion unit to the system. I ran MAKEDEV and > newfs. The results were about 950megs total with 850megs available. Is > this normal? I read somewhere that the system takes about 10% for > (mumble...mumble). And I responded "This seems to be normal". But just to be sure I tried an experiment. We also have a new expansion box with two RZ57s in it with which I've been able to experi ment. The df(1) output for a new file system looks like: Filesystem Total kbytes kbytes % node kbytes used free used Mounted on /dev/rz1c 945726 9 851145 0% /mnt Clearly the amount free and the amount used don't add up to the total. If we take 10% off the total first though: 945,726 - 94,572 = 851,154 = 851,145 + 9 So it does work out. What happens as the file system fills? I don't have the intermediate steps handy, but I do have the end result: Filesystem Total kbytes kbytes % node kbytes used free used Mounted on /dev/rz1c 945726 945726 0 111% /mnt The "kbytes free" went to 0 the same time the %used went to 100%. After that "free" continued to be zero as I slowly filled up the rest of the disk. So a completely full file system will end up at 111% full, which makes sense when you think about it. Finally; getting that last few blocks used up wasn't easy. I create a bunch of large files initially by making copies of /dev/mem into the file system. When I got enough of those I made a another that took up most of the rest and slowly appended stuff onto the end of it until I got file system full messages. At this point I had just a few KB left over. These last few I picked up by creating an appropriate number of small files of 1 KB each. I still had lots of inodes left though. -- Alan Rollow alan@nabeth.cxn.dec.com
yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) (06/16/91)
Edit the "physmem" field located in /sys/conf/mips/HOSTNAME and give it the number of Megabytes of RAM you have, for instance, if you had originally 16 MB and added two 8MB boards, you now have 32MB: physmem 32 Then rebuild your kerel and reboot. -- Philip Yzarn de Louraille Internet: yzarn@chevron.com Research Support Division Unix & Open Systems Chevron Information & Technology Co. Tel: (213) 694-9232 P.O. Box 446, La Habra, CA 90633-0446 Fax: (213) 694-7709
henderson@esvax.hamavnet.com (06/17/91)
In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes: > We recently got some new hardware for our DECstation 5000/200. Most of > the installation seems straight forward but I have a few of questions. > > I added two 8 meg memory boards. The memory shows up on the hardware > test. What do I need to do to make the operating system aware of the > new memory? I couldn't find any doc on this, maybe I'm not looking in > the right place. You need to rebuild the kernel. Bring the machine to single user mode and do: # /etc/doconfig -c HOSTNAME ^^^^^^^^--- must be all caps, even if your machine name has lowercase chars on it Then make sure you move the newly generated vmunix file back to root # mv /sys/MIPS/HOSTNAME/vmunix / . .(stuff deleted as I don't have answers for some of the questions...) . . > > Another thing, do you have to run lmf on each machine to install the licenses > for each product. We only have a half dozen machines with one acting as the > server(dms) for the others. Still, it was a bit tedious typing in all the > information for each machine to register a product. There's probably a way > to type it just once and reuse, no? No. -- Javier Henderson Engineering Services Avnet Computer Los Angeles, CA henderson@hamavnet.com {simpact,asylum,elroy,dhw68k}!hamavnet!henderson