|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Man Pages | ||||||
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
Your company just bought 30 new machines, and it’s your job to install Linux on them. If you’re using Red Hat Linux, the kickstart install process can save you a lot of time.Kickstart automates the install process, so that it becomes as simple as putting the floppy in, turning the machine on, and coming back 15 minutes later. Kickstart is especially useful if you have a number of machines with similar configurations. In the simplest case, all you need is an up-to-date boot floppy, a kickstart config file, and an installation CD-ROM. For trickier installs, you might also need a DHCP or bootp server, an NFS server, and a DNS server.
A kickstart installation requires that you predefine all necessary installation data in a kickstart config file. The kickstart config file can be split into three parts — the preinstall, the packages, and the post-install.
The preinstall section of the config file is used to answer the questions that are usually asked before the install starts. The options, which will be described below, are: lang, network, {nfs|cdrom|url|harddrive}, {device|noprobe}, keyboard, zerombr, clearpart, part, {install|upgrade}, mouse, timezone, {xconfig|skipx}, rootpw, auth, lilo. See “Configuration Options” for a description of the preinstall section options.
http://metalab.unc.edu/LDP/HOWTO/KickStart-HOWTO.html
Nexus NDG LINUX Page (in Russian)
Josh's Linux Guide -- contains several useful essays
Setting Up Ethernet -- very good. The site Josh's Linux Guide contains other useful documents. Highly recommended.
Linux at CESDIS -- by Donald Becker
Ethernet HOWTO, by Paul Gortmaker <[email protected]>. Information on Ethernet hardware compatibility for Linux. Updated 6 July 1998.
Kernel HOWTO, by Brian Ward <[email protected]>. Upgrading and compiling the Linux kernel. Updated 26 May 1997.
| Three rules for successful repartitioning
Rule 1. Make a full backup of the disk or at least the most
important files Rule 2. Read the instructions Rule 3. Follow the instructions! Do not improvise during repartitioning |
The Multi Disk HOWTO which is very much about tuning in general. It is way to big to quote here so I' rather suggest the interested readers look at the following chapters listed below (straight from the Multi Disk HOWTO homepage):
Note that the swap partiotn limit in old kernels depends on the architecture of the processor, namely if it is a 32- or 64-bits processor.
Ask SlashdotAsk Slashdot Linux and Swap Optimization
by MikeBabcock on Friday July 09, @12:52AM EDT (#79)If you have 128M of ram, for now, create two 64M (or 128M if you can spare the space, but I wouldn't) swap partitions on two different drives. If you have only one drive, make it a 128M partition near the beginning ...
Partitions:
/boot
SWAP
... others ...
... this way your kernel files are always in the first 1024 cylinders but your swap is at the fastest part of older disks (newer disks use scattering to make all reads and writes the same speed).
If you use two disks, and assuming the load on both is about the same, set the priorities to be equal in /etc/fstab:
/dev/hda2 swap swap defaults,pri=1 0 0
/dev/hdc2 swap swap defaults,pri=1 0 0
This way the Linux kernel automatically uses both partitions simultaneously for faster reads and writes. If your hard drive isn't doing anything else, you'll get twice the speed out of this.
Again, with 128M of ram, you only need 128M of swap, even for most mid-level server apps. If you want to run Slashdot on your PC, you might need more :) ...
... leave some unpartitioned space in the middle of your drive to add swap to later if you need to ... (or to quickly partition and back up data to if another partition craps out).
- Michael
There's been a lot of talk about the old limits and why they were there and whatnot. Here's a little technical background as well as my own rules-of-thumb on size and location.
The old "2x" rule of thumb was always silly. What was important was that it was *at least* 1x. Why? Not because the kernel dumped core into the swap (which was true, but almost nobody really cared to grope through the dump so it was usually immaterial), but because every page of physical memory had a shadow page in swap. This was an important performance optimization.
First, realize that in most cases UNIX systems had only about half as much RAM as would be needed to hold everything running in RAM (even ignoring cache). 100% overcommit was *normal*; you just couldn't afford enough memory. On such systems swap performance could make or break a system.
BSD systems (and others) would start writing pages to swap long before memory space was exhausted, but keep the pages in memory as well. If the system suddenly needed more RAM to satisfy a request, any pages already written to disk could be grabbed immediately since they could be restored from swap later if necessary. If the application decided it needed the page before that happened, it was still there. Thus you could seriously overcommit memory without having much impact on performance.
Lots of people get worried about the performance impact of the (possibly) unnecessary page writes. I've never understood that; the way these systems work is you go tell the controller to do the write, then you go back to doing what you were doing and it'll let you know when it's done. Thus unless you're maxing out your controller/disk there is almost no penalty for doing it -- and it's a huge, huge win when you need RAM fast.
Some systems (notably Windows 95) don't start writing pages until they need more RAM. Doing this makes application performance synchronous with swap performance in overcommit situations -- and as we all know, that's going to suck royally. The upside to this approach is that the performance of the machine is maximized when everything *does* fit -- you're not doing any extra work -- and disk footprint of the system is minimized (a big deal when disks were a really big part of the cost of the whole system).
Assuming that what people here have been saying is true, that Linux swap space is additive, then my guess is that it uses a pool system such that it sets a low-water mark on free pages such that it starts shadowing pages when the low-water mark is exceeded. This management system goes under the assumption that there's some number of pages you might need immediately, but that's smaller than the total available page pool. That was usually true even in the old BSD days and is most definitely true today (what with everybody's desktop having 64MB or more, what luxury).
Anyway this approach provides the best of both worlds: if you have enough memory to keep the free page pool below the low-water limit then you don't do any extra work, but if you're running in a tight or overcommit mode you usually have a bunch of pages that you can steal fast if you need them. But beware the situation where total VM use exceeds real memory plus swap minus free page pool size -- you'll start swapping synchronously as the ability of the system to shadow pages disappears.
My rule of thumb, now as always, is to set swap such that the total VM space is roughly twice what I think I'll ever need in day-to-day operations, but at least as large as RAM.
Why that big? Because sometimes you blow right through your typical VM usage and it's better to have the machine respond slowly than to have things fail. Now that disk is cheap there's not much reason not to just pick a pretty big number.
As for why make it as large as RAM, well, call it superstition. Quite a number of VM systems on the market today (most particularly Windows NT) perform quite poorly if you don't have at least as much swap as RAM, and some even limit available RAM to the size of swap if you do that (as BSD used to do). Since I don't always have the time (or sometimes even the documentation) to figure out which ones use which policy I just pick a number large enough that it can't ever be a problem.
Now, about swap location. Ideally you have a whole disk dedicated to swap, but these days disks are so large that you couldn't realistically make use of a whole disk (or even a tenth of one) for swap unless you're working with some really serious datasets.
So pretty much everyone splits up their disk.
So far in replies I've heard recommendations for putting the swap at the low cylinders, middle, and high. There are two things you trade off in position -- data transfer rate and head movement.
If you put the swap at the outside or inside of the disk you're going to be moving the heads a long way any time you need to swap a page, assuming that one or another filesystems on the disk is in regular use (typically the case). On the outside, however, you may get some of that back because data transfer rates are the highest. Putting it on the inside (low cylinder numbers) is idiotic -- they have the slowest transfer rates *and* you usually have to move the heads a lot. Modern disks are so fast that this isn't really much of a problem, but it's so easy to avoid that there's no reason to do it.
I suggest putting it somewhere in the middle, preferably between your two most active partitions. Since the swap partition is usually relatively small compared to filesystems you don't make seek time that much longer between filesystems, and you ensure that you're pretty close to the swap partition all the time.
Lastly, we've heard comments that claiming both that swapping to a file is slower than swapping to a partition, and that that's not true. It *is* true. Large files (eg a swap file) will be fragmented somewhat, forcing additional disk/head movement in some cases, and you'll also have to deal with metadata describing where on the disk the file blocks are. This eats up both in-system filesystem cache and causes additional disk activity while you load metadata that's not in the cache.
Swapping to a file is something I'd do in an emergency or if you need more swap and can't justify repartitioning or adding a new disk. If you can plan ahead of time you should avoid it, it will always be somewhat slower, although realistically speaking with today's systems you might not be able to tell.
(I feel like an old fogey. You wouldn't believe how cool I think it is that I can have pretty much as much memory and disk as I want. Why, when I was a young hacker, we had to swap our programs to paper using a pencil....)
See also:
Home Server with Linux - document that explains how to share a modem and printer with a Windows 95 machine
The following mini-HOWTOs are available:
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: November 13, 2004
