Why aren't you logging?
Solaris 7 and 8 include a native implementation of file system journaling. That feature, known as intent logging or just logging enables faster file system operation and faster system boot. It's trivial to implement, safe to use, and free. Clearly, you should be using it.
The new logging feature is an option to the Unix File System (UFS), which is the standard file system for all disk partitions on Sun machines, except for partitions holding swap space. Logging is enabled on a per file system basis, and it can even be enabled on / and other operating system partitions.
Background
Solaris UFS logging works by allocating space from the file system's free blocks. Within that space, all metadata changes to the file system are written. Metadata includes directory and i-node information but not file data blocks, essentially everything but the actual data within the file. So, for example, a file create modifies the directory structure and allocates a new i-node, and those activities are written to the logging space. Once the metadata changes are made to the logging area, the system is free to perform other operations to the file system. In the background, the information in the log is flushed to the file system and updates the appropriate directory and i-node structures, completing the file system operations.
The logging data is written sequentially within the log space. It's therefore much faster for the operating system to complete metadata changes via logging and background flushing than by directly modifying the metadata (via random I/O) spread across the disk. The size of the logging space is based on the size of the file system, and equals 1 MB per 1 GB of file system space, up to 64 MB. The space is used as a circular log: if the log space is about to fill up, new metadata change requests are paused while the log is emptied. As changes are moved from the log to the file system, that log space is made available, and new metadata changes can be written to the logging space.
Usually with UFS, if the system crashes during any file system operation, the entire system must have its consistency checked via the fsck command. That command can take several minutes per file system because it checks all metadata and file data to ensure the structures are correct, free, and used, and that the i-node block counts are correct. It also confirms that the free space available is current, repairs inconsistencies, and occasionally requires manual intervention to fix large problems. Files and even directories can be lost, depending on the operations occurring at the time of the crash.
Because metadata changes are made first to the log space rather than to the file system, the consistency check for a logged file system after a crash is a simple and fast operation. The system evaluates the logging data and determines which changes had completed against the underlying file system, which had yet to
Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.
Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.
Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.
