Linux System Administration
The steps required to add an additional disk drive to a microcomputer system are somewhat more tedious than those needed for larger systems. Most of the complexity comes from the fact that disks can be shared by distinct operating systems on microcomputers.
The terminology related to disk partitions varies somewhat between UNIX and other microcomputer operating systems. For example, DOS distinguishes between the primary partition (the principal, bootable DOS partition) and other extended partitions on the same hard disk; a UNIX disk partition is simply a separately accessible portion of a disk. DOS allows for a maximum of four physical partitions per disk. Under DOS, a physical disk partition can be further subdivided into multiple parts, known as logical drives. The first step in adding a disk to a microcomputer system is to decide how the drive will be split between DOS and UNIX (if applicable). The fdisk utility is used to create physical disk partitions on microcomputer systems (DOS also provides an fdisk utility). The cfdisk utility, a screen-based version of fdisk, is also available under Linux. The following considerations apply to the myriad of fdisk versions that you may encounter:
The conventional wisdom is to use the native version of fdisk to create and operate on the disk partitions for each operating system. In other words, use the DOS version for the DOS partitions, and the UNIX version for the UNIX partitions. In practice, you can often get away with using a different version. Things generally work fine, except when they don't.
Keep records of the partition numbers, starting and ending blocks, total sizes, partition type, and other data for each disk partition table as it is displayed by every version of fdisk that you have. An easy way to do this is to print the partition table from each version. If the table is ever damaged—and this does happen from time to time—you will probably need the information to recreate it and recover your data. Having the data from all the versions ensures that you can redefine partitions following the same alignment patterns and requirements as observed by the various operating systems when they created the partitions initially.
We'll look at the process of attaching a new SCSI disk to a Linux system in detail. The process would be the same for other disk types (for example, IDE), although the special files used to access the device would be different (for example, /dev/hdb).
After attaching the disk to the system, it should be detected when the system is booted. You can use the dmesg command to display boot messages or check /etc/boot.log if you're using the sysvinit facility:
scsi0 : at 0x0388 irq 10 options CAN_QUEUE=32 ... scsi0 : Pro Audio Spectrum-16 SCSI scsi : 1 host. Detected scsi disk sda at scsi0, id 2, lun 0 scsi : detected 1 SCSI disk total.
If necessary, create the device special files for the disk (needed only when you have lots of disks). For example, this command creates the special files used to access the fifth SCSI disk:
# cd /dev; MAKEDEV sde
Note also that disk ordering happens at boot time, so adding a new SCSI disk with a lower SCSI ID than an existing disk will cause special files to be reassigned—and probably break your /etc/fstab setup.
Assuming we have our special files all in order, we will use fdisk or cfdisk (a screen-oriented version) to divide the disk into partitions (we'll be saving about a third of the disk for a DOS partition). The following commands will start these utilities for the first SCSI disk:
# fdisk /dev/sda # cfdisk /dev/sda
We'll need the following subcommands:
Create new partition
Change partition type
Make partition active/bootable
Write partition table to disk
Change size units
Display partition table
cfdisk is more convenient to use as the partition table is displayed continuously. A cfdisk subcommand always operates on the current partition (highlighted). Thus, in order to create a new partition, move the highlight to the line corresponding to Free Space, and then enter an n. cfdisk will prompt for the partition information:
Primary or logical [pl]: p Size (in MB): 110
If you'd rather enter the size in a different set of units, use the u subcommand (cycles among MB, sectors and cylinders).
We use the same procedure to create a second partition, and then activate the first partition with the b subcommand. Then, we use the t subcommand to change the partition types of the two partitions. The most commonly needed type codes are 6 for DOS, 82 for a Linux swap partition, and 83 for a regular Linux partition.
Here is the final partition table (output has been simplified): Don't put any hairspaces in between the dashes below, or they will blow up. They don't have to look separated.
cfdisk 0.8 BETA Disk Drive: /dev/sda Heads: 16 Sectors per Track: 63 Cylinders: 1023 Name Flags Part Type FS Type Size (MB) /dev/sda1 Boot Primary Linux 110.0 /dev/sda2 Primary DOS 52.5 Pri/Log Free Space 0.5
If you've changed the partition layout of the disk—in other words, done anything other than change the types assigned to the various partitions—reboot the system at this point.
Next, use the mkfs command to create a filesystem on the Linux partition. mkfs has been streamlined in the Linux version and requires little input:
# mkfs -t ext2 /dev/sda1
This command creates an ext2-type filesystem. If you want to customize mkfs's operation, the following options may be useful:
-b: Set filesystem block size in bytes (the default is 1024).
-f: Set filesystem fragment size in bytes (the default is 1024).
-c: Check the disk partition for bad blocks before making the filesystem.
-i: Specify bytes/inode value: create one inode for each chunk of this many bytes. The default value of 4096 usually creates more than you'll ever need, but probably isn't worth changing.
-m: Specify the percentage of filesystem space to reserve (accessible only by root). The default is 5% (half of what is typical on other UNIX systems). In these days of multigigabyte disks, even this percentage may be worth rethinking.
Once the filesystem is built, run fsck:
# fsck -f -y /dev/sda1
The -f option is necessary to force fsck to run even though the filesystem is clean. The new filesystem may now be mounted and entered into /etc/fstab, which is the subject of the next section.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide