Solaris Internals

Solaris internals can be studied using source code and using the book. Chapter 14, File System Framework is available as free Download  from Solaris Internals, Second Edition page

Solaris Internals(TM)- Solaris 10 and OpenSolaris Kernel Architecture (2nd Edition)

The best source for learning about Solaris internals, July 29, 2006

By  calvinnme (TOP 50 REVIEWER)

This book is actually just one of a two volume set - "Solaris Internals" for developers, and "Solaris Performance and Tools" for system administrators. I will speak of the second edition of "Solaris Internals", since I am not a system administrator by trade. "Solaris Internals" is the badly needed update for the only book that I know of that contains information on how Solaris implements functions behind the application programming interfaces. This information will be most helpful to application developers, device driver and kernel module developers, and advanced system administrators that are responsible for performance tuning and capacity planning. The book reads like a combination computer architecture and operating systems manual, and though it can be a bit dry at times, it was meant to be a reference book that professionals can go to for the details. In that sense, the first edition never failed me. In fact, if you are not familiar with the concepts of computer architecture and operating systems theory in general, this book will probably be over your head. From perusing the second edition, the format seems to be very much the same in the second edition, just with expanded material reflecting the additional features of Solaris 10.

 Also, if you are into Solaris systems programming as I am, another essential volume is "Solaris Systems Programming". That book is also very dry reading, but it has what you need to know in order to write code with system calls to the Solaris operating system. I show the table of contents below:

Part One: Introduction to Solaris Internals
Chapter 1 -- Introduction

Part Two: The Process Model
Chapter 2 -- The Solaris Process Model
Chapter 3 -- Scheduling Classes and the Dispatcher
Chapter 4 -- Interprocess Communication
Chapter 5 -- Process Rights Management

Part Three: Resource Management
Chapter 6 -- Zones
Chapter 7 -- Projects, Tasks, and Resource Controls

Part Four: Memory
Chapter 8 -- Introduction to Solaris Memory
Chapter 9 -- Virtual Memory
Chapter 10 -- Physical Memory
Chapter 11 -- Kernel Memory
Chapter 12 -- Hardware Address Translation
Chapter 13 -- Working with Multiple Page Sizes in Solaris

Part Five: File Systems
Chapter 14 -- File System Framework
Chapter 15 -- The UFS File System

Part Six: Platform Specifics
Chapter 16 -- Support for NUMA and CMT Hardware
Chapter 17 -- Locking and Synchronization

Part Seven: Networking
Chapter 18 -- The Solaris Network Stack

Part Eight: Kernel Services
Chapter 19 -- Clocks and Timers
Chapter 20 -- Task Queues
Chapter 21 -- kmdb Implementation

Older version (2001 is available from Google books Solaris internals core kernel ... - Google Books. It aso can be found as PDF on various sites.

See also slides related to the book:

• solaris_internals
• t2-solaris-slides

NEWS CONTENTS

• 20090416 : Solaris_Filesystem_Choices ( Solaris_Filesystem_Choices, Apr 16, 2009 )
• 20090416 : Adam Leventhals Weblog ( Adam Leventhal's Weblog, )
• 20060122 : Supporting Multiple Page Sizes in the Solaris Operating System ( Supporting Multiple Page Sizes in the Solaris Operating System, Jan 22, 2006 )
• 20060116 : Solaris 8 Memory Architecture ( Solaris 8 Memory Architecture, Jan 16, 2006 )
• 20050325 : http://www.sun.com/bigadmin/features/articles/selfheal.html ( http://www.sun.com/bigadmin/features/articles/selfheal.html, Mar 25, 2005 )
• 20050317 : An interesting option in telnetd for Solaris 10 ( Mar 17, 2005 )
• 20050307 : docs.sun.com: Solaris Tunable Parameters Reference Manual ( docs.sun.com: Solaris Tunable Parameters Reference Manual, Mar 7, 2005 )
• 20020920 : Anatomy of a Read and Write Call by Pat Shuff Linux Journal 2002-09-20 23:00 ( Anatomy of a Read and Write Call , Sep 20, 2002 )

Old News ;-)

[Apr 16, 2009] Solaris_Filesystem_Choices

Solaris Filesystem Choices

posted by John Finigan on Mon 21st Apr 2008 19:00 UTC

When it comes to dealing with storage, Solaris 10 provides admins with more choices than any other operating system. Right out of the box, it offers two filesystems, two volume managers, an iscsi target and initiator, and, naturally, an NFS server. Add a couple of Sun packages and you have volume replication, a cluster filesystem, and a hierarchical storage manager. Trust your data to the still-in-development features found in OpenSolaris, and you can have a fibre channel target and an in-kernel CIFS server, among other things. True, some of these features can be found in any enterprise-ready UNIX OS. But Solaris 10 integrates all of them into one well-tested package. Editor's note: This is the first of our published submissions for the 2008 Article Contest.

The details of the whole Solaris storage stack could fill a book, so in this article I will focus only on filesystems. There are four common on-disk filesystems for Solaris, and my goal is to familiarize the reader with each of them, and to mention a few deployment scenarios where each is appropriate.

UFS

UFS in its various forms has been with us since the days of BSD on VAXen the size of refrigerators. The basic UFS concepts thus date back to the early 1980s and represent the second pass at a workable UNIX filesystem, after the very slow and simple filesystem that shipped with the truly ancient Version 7 UNIX. Almost all commercial UNIX OSs have had a UFS, and ext3 in Linux is similar to UFS in design. Solaris inherited UFS through SunOS, and SunOS in turn got it from BSD.

Until recently, UFS was the only filesystem that shipped with Solaris. Unlike HP, IBM, SGI, and DEC, Sun did not develop a next-generation filesystem during the 1990s. There are probably at least two reasons for this: most competitors developed their new filesystems using third party code which required per-system royalties, and the availability of VxFS from Veritas. Considering that a lot of the other vendors' filesystem IP was licensed from Veritas anyway, this seems like a reasonable decision.

Solaris 10 can only boot from a UFS root filesystem. In the future, ZFS boot will be available, as it already is in OpenSolaris. But for now, every Solaris system must have at least one UFS filesystem.

UFS is old technology but it is a stable and fast filesystem. Sun has continuously tuned and improved the code over the last decade and has probably squeezed as much performance out of this type of FS as is possible. Journaling support was added in Solaris 7 at the turn of the century and has been enabled by default since Solaris 9. Before that, volume level journaling was available. In this older scheme, changes to the raw device are journaled, and the filesystem is not journaling-aware. This is a simple but inefficient scheme, and it worked with a small performance penalty. Volume level journaling is now end-of-lifed, but interestingly, the same sort of system seems to have been added to FreeBSD recently. What is old is new again.

UFS is accompanied by the Solaris Volume Manager, which provides perfectly servicible software RAID.

Where does UFS fit in in 2008? Besides booting, it provides a filesystem which is stable and predictable and better integrated into the OS than anything else. ZFS will probably replace it eventually, but for now, it is a good choice for databases, which have usually been tuned for a traditional filesystem's access characteristics. It is also a good choice for the pathologically conservative administrator, who may not have an exciting job, but who rarely has his nap time interrupted.

ZFS

ZFS has gotten a lot of hype. It has also gotten some derision from Linux folks who are accustomed to getting that hype themselves. ZFS is not a magic bullet, but it is very cool. I like to think that if UFS and ext3 were first generation UNIX filesystems, and VxFS and XFS were second generation, then ZFS is the first third generation UNIX FS.

ZFS is not just a filesystem. It is actually a hybrid filesystem and volume manager. The integration of these two functionalities is a main source of the flexibility of ZFS. It is also, in part, the source of the famous "rampant layering violation" quote which has been repeated so many times. Remember, though, that this is just one developer's aesthetic opinion. I have never seen a layering violation that actually stopped me from opening a file.

Being a hybrid means that ZFS manages storage differently than traditional solutions. Traditionally, you have a one to one mapping of filesystems to disk partitions, or alternately, you have a one to one mapping of filesystems to logical volumes, each of which is made up of one or more disks. In ZFS, all disks participate in one storage pool. Each ZFS filesystem has the use of all disk drives in the pool, and since filesystems are not mapped to volumes, all space is shared. Space may be reserved, so that one filesystem can't fill up the whole pool, and reservations may be changed at will. However, if you don't want to decide ahead of time how big each filesystem needs to be, there is no need to, and logical volumes never need to be resized. Growing or shrinking a filesystem isn't just painless, it is irrelevant.

ZFS provides the most robust error checking of any filesystem available. All data and metadata is checksummed (SHA256 is available for the paranoid), and the checksum is validated on every read and write. If it fails and a second copy is available (metadata blocks are replicated even on single disk pools, and data is typically replicated by RAID), the second block is fetched and the corrupted block is replaced. This protects against not just bad disks, but bad controllers and fibre paths. On-disk changes are committed transactionally, so although traditional journaling is not used, on-disk state is always valid. There is no ZFS fsck program. ZFS pools may be scrubbed for errors (logical and checksum) without unmounting them.

The copy-on-write nature of ZFS provides for nearly free snapshot and clone functionality. Snapshotting a filesystem creates a point in time image of that filesystem, mounted on a dot directory in the filesystem's root. Any number of different snapshots may be mounted, and no separate logical volume is needed, as would be for LVM style snapshots. Unless disk space becomes tight, there is no reason not to keep your snapshots forever. A clone is essentially a writable snapshot and may be mounted anywhere. Thus, multiple filesystems may be created based on the same dataset and may then diverge from the base. This is useful for creating a dozen virtual machines in a second or two from an image. Each new VM will take up no space at all until it is changed.

These are just a few interesting features of ZFS. ZFS is not a perfect replacement for traditional filesystems yet - it lacks per-user quota support and performs differently than the usual UFS profile. But for typical applications, I think it is now the best option. Its administrative features and self-healing capability (especially when its built in RAID is used) are hard to beat.

SAM and QFS

SAM and QFS are different things but are closely coupled. QFS is Sun's cluster filesystem, meaning that the same filesystem may be simultaneously mounted by multiple systems. SAM is a hierarchical storage manager; it allows a set of disks to be used as a cache for a tape library. SAM and QFS are designed to work together, but each may be used separately.

QFS has some interesting features. A QFS filesystem may span multiple disks with no extra LVM needed to do striping or concatenation. When multiple disks are used, data may be striped or round-robined. Round-robin allocation means that each file is written to one or two disks in the set. This is useful since, unlike striping, participation by all disks is not needed to fetch a file - each disk may seek totally independently. QFS also allows metadata to be separated from data. In this way, a few disks may serve the random metadata workload while the rest serve a sequential data workload. Finally, as mentioned before, QFS is an asymmetric cluster filesystem.

QFS cannot manage its own RAID, besides striping. For this, you need a hardware controller, a traditional volume manager, or a raw ZFS volume.

SAM makes a much larger backing store (typically a tape library) look like a regular UNIX filesystem. This is accomplished by storing metadata and often-referenced data on disk, and migrating infrequently used data in and out of the disk cache as needed. SAM can be configured so that all data is staged out to tape, so that if the disk cache fails, the tapes may be used like a backup. Files staged off of the disk cache are stored in tar-like archives, so that potentially random access of small files can become sequential. This can make further backups much faster.

QFS may be used as a local or cluster filesystem for large-file intensive workloads like Oracle. SAM and QFS are often used for huge data sets such as those encountered in supercomputing. SAM and QFS are optional products and are not cheap, but they have recently been released into OpenSolaris.

VxFS

The Veritas filesystem and volume manager have their roots in a fault-tolerant proprietary minicomputer built by Veritas in the 1980s. They have been available for Solaris since at least 1993 and have been ported to AIX and Linux. They are integrated into HP-UX and SCO UNIX, and Veritas Volume Manager code has been used (and extensively modified) in Tru64 UNIX and even in Windows. Over the years, Veritas has made a lot of money licensing their tech, and not because it is cheap, but because it works.

VxFS has never been part of Solaris but, when UFS was the only option, it was a popular addition. VxVM and VxFS are tightly integrated. Through vxassist, one may shrink and grow filesystems and their underlying volumes with minimal trouble. VxVM provides online RAID relayout. If you have a RAID5 and want to turn it into a RAID10, no problem, no downtime. If you need more space, just convert it back to a RAID5. VxVM has a reputation for being cryptic, and to some extent it is, but it's not so bad and the flexibility is impressive.

VxFS is a fast, extent based, journaled, clusterable filesystem. In fact, it essentially introduced these features to the world, along with direct IO. Newer versions of VxFS and VxVM have the ability to do cross-platform disk sharing. If you ever wanted to unmount a volume from your AIX box and mount it on Linux or Solaris, now you can.

VxFS and VxVM are still closed source. A version is available from Symantec that is free on small servers, with limitations, but I imagine that most users still pay. Pricing starts around $2500 and can be shocking for larger machines. VxFS and VxVM are solid choices for critical infrastructure workloads, including databases.

Conclusion

These are the four major choices in the Solaris on-disk filesystem world. Other filesystems, such as ext2, have some degree of support in OpenSolaris, and FUSE is also being worked on. But if you are deploying a Solaris server, you are going to be using one or more of these four. I hope that you enjoyed this overview, and if you have any corrections or tales of UNIX filesystem history, please let me know.

About the Author

John Finigan is a Computer Science graduate student and IT professional specializing in backup and recovery technology. He is especially interested in the history of enterprise computing and in Cold War technology.

Adam Leventhal's Weblog

To give an example of using DTrace on Linux applications, I needed an application to examine. I wanted a well known program that either didn't run on Solaris or operated sufficiently differently such examining the Linux version rather than the Solaris port made sense. I decided on /usr/bin/top partly because of the dramatic differences between how it operates on Linux vs. Solaris (due to the differences in /proc), but mostly because of what I've heard my colleague, Bryan, refer to as the "top problem": your system is slow, so you run top. What's the top process? Top!

Running top in the Linux branded zone, I opened a shell in the global (Solaris) zone to use DTrace. I started as I do on Solaris applications: I looked at system calls. I was interested to see which system calls were being executed most frequently which is easily expressed in DTrace:

bash-3.00# dtrace -n lx-syscall:::entry'/execname == "top"/{ @[probefunc] = count(); }'
dtrace: description 'lx-syscall:::entry' matched 272 probes
^C

[Jan 22, 2006] Supporting Multiple Page Sizes in the Solaris Operating System

Beginning with the Solaris 9 OS, multiple page sizes can be supported on UltraSPARC processors so administrators can optimize performance by changing the page size on behalf of an application. Typical performance measurement tools do not provide sufficient detail for evaluating the impact of page size and do not provide the needed support to make optimal page size choices.

This article explains how to use new tools to determine the potential performance gain. In addition, it explains how to configure larger page sizes using the multiple page size support (MPSS) feature of the Solaris 9 OS. The article addresses the following topics:

• "Understanding Why Virtual-to-Physical Address Translation Affects Performance"
• "Working With Multiple Page Sizes in the Solaris OS"
• "Configuring for Multiple Page Sizes"

[Jan 16, 2006] Solaris 8 Memory Architecture

A common question pre-Solaris 8 users ask is "Where has all my memory gone"? The vmstat command, used to report virtual memory statistics, often reports that free memory (measured in Kbytes in the free column) is zero or close to zero on a pre-Solaris 8 system that has been up and running for a while.

Most likely, memory is being used to cache file system data, since the virtual memory system is shared by applications, data, the kernel, and file system data. By default, any free memory is used to cache data read from or written to the file system (including NFS). The size of the file system cache is dynamic -- it grows or shrinks depending on free memory.

The idea of this memory allocation scheme is to simultaneously enhance file system performance and optimize the use of an important system resource -- virtual memory. The two computing tasks of running applications and reading and writing data compete equally for system memory.

Generally, sharing a pool of memory is not an issue on small memory systems with low compute power, but with today's powerful desktop systems and servers, the file system cache can overwhelm the memory pool and make application performance suffer. Another drawback is that file system performance is tied to how quickly the virtual memory system can free memory.

Even worse, it is difficult to measure memory usage amongst the consumers of memory on the system. The vmstat command is often the first tool users run to examine virtual memory usage, but pre-Solaris 8 versions do a poor job of indicating why a system is paging (running an algorithm that moves data out from physical memory to disk, and back into physical memory from disk).

So, the question becomes: is it because the system is caching file system data, or is it because memory is a bottleneck and the system is struggling to keep up?

[Mar 25, 2005] http://www.sun.com/bigadmin/features/articles/selfheal.html

[Mar 17, 2005] An interesting option in telnetd for Solaris 10

It looks like it now provides a simple "not in DNS, no access" defense via option -U:

-U Refuses connections that cannot be mapped to a name through the getnameinfo(3SOCKET) function.

[Mar 7, 2005] docs.sun.com: Solaris Tunable Parameters Reference Manual

Solaris Internals

This site provides information supporting the Solaris Internals book published by Jim Mauro and Richard McDougall. Our aim is to provide links to pertinent reference material and tools discussed in the book, plus any new and relevant information about the Solaris operating system since publication.

We hope you find this site useful - we have provided contact information for any questions you may have. We also welcome and encourage feedback.

10/21/2004 - mdb's ::memstat ported to Solaris 8!

[Sep 20, 2002] Anatomy of a Read and Write Call - 21k By Pat Shuff Linux Journal 2002-09-20 23:00

A few years ago I was tasked with making the Spec96 benchmark suite produce the fastest numbers possible using the Solaris Intel operating system and Compaq Proliant servers. We were given all the resources that Sun Microsystems and Compaq Computer Corporation could muster to help take both companies to the next level in Unix computing on the Intel architecture. Sun had just announced its flagship operating system on the Intel platform and Compaq was in a heated race with Dell for the best departmental servers. Unixware and SCO were the primary challengers since Windows NT 3.5 was not very stable at the time and no one had ever heard of an upstart graduate student from overseas who thought that he could build a kernel that rivaled those of multi-billion dollar corporations.

Now many years later, Linux has gained considerable market share and is the De facto Unix for all the major hardware manufacturers on the Intel architecture. In this article, I will attempt to take the lessons learned from this tuning exercise and show how they can be applied to the Linux operating system.

As it turned out, the gcc benchmark was the one that everyone seemed to be improving on the most. As we analyzed what the benchmark was doing, we found out that basically it opened a file, read its contents, created a new file, wrote new contents, then closed both files. It did this over and over and over. File operations proved to be the bottleneck in performance. We tried faster processors with insignificant improvement. We tried processors with huge (at the time) level 1 and level 2 cache and still found no significant improvement. We tried using a gigabyte of memory and found little or no improvement. By using the vmstat command, we found that the processor was relatively idle, little memory was being used, but we were getting a significant amount of reads and writes to the root disk. Using the same hardware and same test programs, Unixware was 25% faster than Solaris Intel. Initially, we decided that Solaris was just really slow. Unfortunately, I was working for Sun at the time and this was not the answer that we could take to my management. We had to figure out why it was slow and make recommendations on how to improve the performance. The target was 25% faster than Unixware, not slower.

The first thing that we did was to look at the configurations. It turns out that the two systems were identical hardware,. We just booted a different disk to boot the other operating system. The Unixware system was configured with /tmp as a tmpfs whereas the Solaris system had /tmp on the root file system. We changed the Solaris configuration to use tmpfs but it did not significantly improve performance. Later, we found that this was due to a bug in the tmpfs implementation on Solaris Intel. By braking down the file operation, we decided to focus on three areas; the libc interface, the node/dentry layer, and the device drivers managing the disk. In this article, we will look at the three different layers and talk about how to improve performance and how they specifically apply to Linux.

LISA 2001 Paper LISA 2001 Paper about RUF

This paper describes a utility named ruf that reads filere accessed by reading disk structures directly so the program is peculiar to the specific file system employed. The current implementation supports the *BSD FFS, SunOS/Solaris UFS, HP-UX HFS, and Linux ext2fs file systems. All these file systems derive from the original FFS, but have peculiar differences in their specific implementations.

The utility can read files from a damaged file system. Since the utility attempts to read only those structures it requires, damaged areas of the disk can be avoided. Files can be accessed by their inode number alone, bypassing damage to structures above it in the directory hierarchy.

The functions of the utility is available in a library named libruf. The utility and library is available under the BSD license.

Introduction

There are many important reasons for being able to access unmounted file systems, the prime example being a damaged disk. This paper describes a utility that can be used to read a disk file without mounting the file system. The utility behaves similar to the regular cat utility, and was originally named dog, but was renamed to ruf for reading unmounted filesystems to avoid a name conflict with an older utility.

In order to access an unmounted file system, the utility must read the disk structures directly and perform all the tasks normally performed by the operating system; this requires a detailed understanding of how the file system is implemented. Implementing this utility for a particular file system is an interesting academic exercise and a good way to learn about the file system. The original work on this utility was in fact done in Evi Nemeth's system administration class.

Getting to know the Solaris filesystem, Part 1 - SunWorld - May 1999

Richard starts this journey into the Solaris filesystem by looking at the fundamental reasons for needing a filesystem and at the functionality various filesystems provide. In this first part of the series, you'll examine the evolution of the Solaris filesystem framework, moving into a study of major filesystem features. You'll focus on filesystems that store data on physical storage devices -- commonly called regular or on-disk filesystems. In future articles, you'll begin to explore the performance characteristics of each filesystem, and how to configure filesystems to provide the required levels of functionality and performance. Richard will also delve into the interaction between Solaris filesystems and the Solaris virtual memory system, and how it all affects performance.

Getting to know the Solaris filesystem, Part 3 - SunWorld - July ...

One of the most important features of a filesystem is its ability to cache file data. Ironically, however, the filesystem cache isn't implemented in the filesystem. In Solaris, the filesystem cache is implemented in the virtual memory system. In Part 3 of this series on the Solaris filesystem, Richard explains how Solaris file caching works and explores the interactions between the filesystem cache and the virtual memory system.

www.solarisinternals.com/si/reading/Getting to know the Solaris filesystem, Part 1 - SunWorld - May 1999

[Mar 7, 2005] CacheKit is a collection of freeware perl and shell programs to report on cache activity on a Solaris 8 SPARC server. Tools for older Solaris and Solaris x86 are also included in the kit, as well as some SE Toolkit programs and extra Solaris 10 DTrace programs. The caches the kit reports on are: I$, D$, E$, DNLC, inode cache, ufs buffer cache, segmap cache and segvn cache. This kit assists performance tuning.

These programs have been written for a Solaris 8 (or newer) sparc server. Also included in the kit are programs for older Solaris, Solaris x86, and Solaris 10.

Recommended Links

• Solaris Tunable Parameters Reference Manual

• Solaris Internals

• Solaris 8 Memory Architecture
• Memory and swapping
• Solaris processes
  

• Roadmap to Sun Developer Documentation

  This article provides a roadmap to information sources for Sun products for developers, with links that readers can use to bookmark the sources.

  Contents:

  • Introduction
  • Roadmap to Documentation for Developers Working With the Solaris Operating System
  • Roadmap to the Man Page Collection
  • Roadmap to Documentation for Developers Working With Java Technology
  • Roadmap to Documentation for Developers Working With Sun Java Enterprise System
  • Roadmap to Documentation for Programming With Other Sun Products
  • Other Information Sources for Sun Products
  • About the Author

  Introduction

  A wealth of information is available to developers working with Sun software products. This article, which is an expanded version of the new manual Introduction to the Solaris Development Environment, serves as a general roadmap to the developer documentation for these products, that is, manuals, specifications, and documentation web pages, as well as other sources of information for developers.

  Note that the links provided here connect to the current versions of the collections and manuals as of the publishing of this article. You should always check that you are accessing the version of the manual that is appropriate for the release of the Sun product you are using.

• System Programming for Solaris 2.3, by Steven Hayes Royal Melbourne Institute of Technology

• Unlocking Solaris

• The Solaris process model, Part 2

• The Solaris process model, Part 2

• The Solaris process model, Part 4: More on the kernel
  ... When Solaris boots, a linked list of CPU structures is created for every ... queues is
  rooted in a disp data structure, which is embedded in each CPU ...
  www.sunworld.com/sunworldonline/swol-12-1998/swol-12-insidesolaris.html - 48k - Cached - Similar pages

• The dynamic Solaris kernel
  ... a module. The primary data structures used in ... module structure; the structure definitions
  for modctl ... kernel maintains a linked list of modctl structures ...
  www.sunworld.com/sunworldonline/swol-02-2000/swol-02-insidesolaris.html - 50k - Cached - Similar pages

• Threads libraries in Solaris

• FOCUS on Sun Solaris Default Processes and init.d Pt. II

• Jim Mauro Inside Solaris columns
  • August 1997 Processor utilization and wait I/O -- a look inside
  • September 1997 Shared memory uncovered
  • October 1997 Setting our sights on semaphores
  • November 1997 Demangling message queues
  • December 1997 Swap space implementation, part 1
  • January 1998 Swap space implementation, part 2
  • February 1998 Fiddling around with files, part 1: "How many files can I open?"
  • March 1998 Fiddling around with files, part 2: file APIs and types
  • April 1998 Fiddling around with files, part 3: file access modes
  • May 1998 Fiddling around with files, part 4: descriptor file flags and structure
  • June 1998 Controlling permissions with access control lists
  • July 1998 Asynchronous I/O and large file support in Solaris
  • August 1998 Peeling back the process layers
  • September 1998 The Solaris process model, part 2
  • October 1998 More on the Solaris process model
  • November 1998 Inside Solaris 7
  • December 1998 The Solaris process model, Part 4: More on the kernel
  • January 1999 The Solaris process model, Part 5: The kernel dispatcher
  • February 1999 The Solaris process model, Part 6: Inside the kernel dispatcher
  • March 1999 The Solaris process model, Part 7: Managing thread execution and wait times in the system clock handler
  • April 1999 A primer on signals, Part 1
  • May 1999 A primer on signals, Part 2
  • June 1999 Priorities revisited
  • July 1999 It's time to wake up! The intricacies of sleep and wakeup in Solaris
  • August 1999 Turnstiles and priority inheritance
  • September 1999 Kernel synchronization primitives
  • October 1999 Unlocking Solaris
  • November 1999 Keeping time
  • December 1999 Communicating the POSIX way
  • February 2000 The dynamic Solaris kernel
  • March 2000 Resource utilization and microstate accounting
  • April 2000 The kernel directory
  • June 2000 Threads libraries in Solaris

Etc

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

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: March 12, 2019