Solaris Solutions 2e W/Ws
Teaches how to work smart and avoid the many pitfalls of managing Solaris systems\ Covers the latest release of Solaris, Solaris 9, as well as earlier versions\ Written by experts with years of Solaris experience\ Packed with practical, hands-on solutions to tough problems, showing how to avoid costly mistakes\ Tackles managing system performance; the Sun Fire line of Solaris enterprise servers; installing, configuring, and patching Solaris; and ensuring security\
Search in google:
Teaches how to work smart and avoid the many pitfalls of managing Solaris systems Covers the latest release of Solaris, Solaris 9, as well as earlier versions Written by experts with years of Solaris experience Packed with practical, hands-on solutions to tough problems, showing how to avoid costly mistakes Tackles managing system performance; the Sun Fire line of Solaris enterprise servers; installing, configuring, and patching Solaris; and ensuring security
\ \ Chapter 1: Making Smart Decisions about File Systems\ aying out file systems on your servers and clients is one of the most important steps you will take in building a manageable network. How you arrange file systems on individual hosts and across a network can dramatically affect the performance of your systems and network, the reliability of your systems, security, cost, your backup strategy, and the amount of work that you have to do to maintain these file systems and the software and data they house. In fact, your file systems can easily be the single most significant factor in the overall performance and reliability of your network.\ In this chapter, we will look at how file systems are organized and how this organization affects performance. We will offer suggestions on how you might arrange file systems on a network basis to make your network more manageable.\ File Systems from the Roots Up\ The file system that Unix uses to store everything from device drivers to users' data is undoubtedly familiar to you. With a single root from which all branches of the treelike structure derive, the file system provides a degree of consistency across the most divergent variations of Unix. Yet the simplicity of this hierarchical file system (playfully depicted in Figure 1.1) hides an increasing degree of complexity with every major release of Solaris. Early versions of Unix systems employed a single disk-based file system. The current version of Solaris supports many different types of file systems-the customary disk-based fast file system; network-based file systems; compact-disc read-only memory (CDROM) file systems; redundant array of inexpensive disk (RAID) systems, in which many disks combine into one logical file system; file systems on disk operating system (DOS) diskettes; and even pseudo or virtual file systems, which are comprised not of files at all but of processes, network sockets, character device drivers, and the like. Even so, the convenient abstraction of the familiar treelike structure persists, and most Unix users are oblivious to the complex structures upon which this abstraction is built.\ To begin our examination of Solaris file systems and how you can optimize the performance and utility of file systems across your network, let's first examine a traditional Unix file system (UFS) from the ground up. A single file is, first and foremost, a collection of data-whether ASCII or binary-that is stored in contiguous and/or noncontiguous chunks on a disk. These chunks axe sized according to a storage unit called a block (for UFS, the default block size is 8192 bytes). You have probably also noticed that directory files are always some multiple of 512 bytes. When you first create a directory with mkdir, you will notice that it looks something like this:\ This is because space for directory growth is allocated in 512-byte units. By preallocating space in directories, they can grow without as much overhead as if space had to be added each time the contents of a directory changed. Files, of course, don't grow in units of blocks, but by the amount of data they contain. The space allocated for them, however, does grow in units of blocks, which allows them to grow up to the next increment of a block before additional disk space must be allocated. In general, all but the last block of a file is full. Figure 1.2 illustrates disk space allocation for a regular file.\ Some file systems milk this efficiency even further by allocating more than a single additional block when a file grows. These are referred to as extent-based, as opposed to block-based, file systems. By allocating a larger amount of disk space, the files can grow more contiguously. On the other hand, an extentbased file system runs a greater risk of wasting space that is allocated and not used. The separate blocks of data comprising a single file are linked to each other by on-disk record structures, which store the location of each of the blocks. This structure is sometimes referred to as a block map. In a similar manner, the available disk space on a file system is maintained in a free-block list. A more complex record structure is used to store the descriptive data concerning each file, sometimes referred to as metadata (a common term for data that describes data). This metadata includes the file's owner (i.e., the user ID [UID]); the file's associated group (the group ID [GID]); the permissions matrix; the file creation, modification and access times; the size and type of the file; and so on. In fact, the only items not stored in this structure are the contents of the file (as mentioned, this is stored on disk) and the file's name and location within the file system.\ A file's name is stored within another file called the directory file. The inclusion of the filename within a particular directory also determines where it "lives" within the tree structure. This location has almost nothing to do with the location of the data itself. In fact, the same file can exist in any number of locations, even in the same directory more than once if it has more than one name. If a single collection of data blocks comprising a single file has more than one file system identity, this duplication is only expressed through the separate directory entries and in the number of links indicated within the inode. Directory files, as you might suspect, also contain the inode numbers of the files they contain...
Preface.Acknowledgments.About the Authors.Introduction.PART I: SETTING UP YOUR SOLARIS INFRASTRUCTURE.Chapter 1: Making Smart Decisions about File Systems.Chapter 2: Planning Backups and Restores.Chapter 3: Booting and Hardware Diagnostics.Chapter 4: Configuring Run States.Chapter 5: Installing and Patching Your Solaris System.Chapter 6: Exploiting JumpStart and Web Start Flash.Chapter 7: Setting up Name Services.Chapter 8: Network Information Services.PART II: MANAGING YOUR SYSTEMS.Chapter 9: Monitoring Your Environment.Chapter 10: Managing Performance.Chapter 11: Volume Management.Chapter 12: Automating Everything . . . Well, Almost!Chapter 13: Keeping Your Solaris Systems Secure.Chapter 14: Implementing High Availability: Eliminating Single Points of Failure.PART III: LOOKING AFTER YOUR HARDWARE.Chapter 15: Maintaining Your Sun Hardware.Chapter 16: Peripheral Vision: Understanding and Configuring Other Hardware.Chapter 17: The Starfire.Chapter 18: The Sun Fire Servers.PART IV: SURVIVING IN THE REAL WORLD.Chapter 19: Running an Internet Site.Chapter 20: Coexisting with other Empires.Chapter 21: Time Management Techniques for Sysadmins.Glossary.Bibliography and Recommended Reading.Index.
