Single transaction technique for a journaling file system of a computer operating system

Abstract

A single transaction technique for a journaling file system of a computer operating system in which a single file system transaction is opened for accumulating a plurality of current synchronous file system operations. The plurality of current synchronous file system operations are then performed and the single file system transaction closed upon completion of the last of the file system operations. The single file system operation is then committed to a computer mass storage device in a single write operation without the necessity of committing each of the separate synchronous file system operations with individual writes to the storage device thereby significantly increasing overall system performance. The technique disclosed is of especial utility in conjunction with UNIX System V based or other journaling operating systems.

Claims

What is claimed is:

1. A method for writing data from a computer system to a mass storage device comprising the steps of:

implementing a journaling file system operating on the computer system, the journaling file system comprising a logging device and a master device;

processing in the operating system a plurality of file system operations using the computer system, wherein synchronous file system operations are generated by an external application program and refer to data stored at a specified location in the master device;

for each file system operation, providing an in-core copy of data from the master device;

for each file system operation, altering the in-core copy of data from the master device;

writing the altered in-core copy corresponding to each file system operation to the master device;

accumulating a plurality of the file system operations into a single logging transaction; and

performing the single logging transaction by writing the single logging transaction to the logging device.

2. The method of claim 1 wherein each synchronous file system operation comprises a file system operation generated by an external application in which all data must be committed before application program code can continue executing.

3. The method of claim 1 wherein each synchronous file system operation comprises an operation in which each operation is treated as a separate transaction, and wherein each synchronous file operation requires at least one write to the mass storage device per operation.

4. A computer program product comprising:

a propagating signal having computer readable code embodied therein for causing data to be written from a computer system to a mass storage device;

computer readable code segment in the propagating signal comprising code configured to implement a logging device in the mass storage device;

computer readable code segment in the propagating signal comprising code configured to implement a master device in the mass storage device;

computer readable code segment in the propagating signal comprising code configured to process a plurality of file system operations using the computer system, wherein the file system operations are generated by an external application program and refer to data stored at a specified location in the master device;

computer readable code segment in the propagating signal comprising code configured to provide an in-core copy of data from the master device for each file system operation;

computer readable code segment in the propagating signal comprising code configured to alter the in-core copy of data from the master device for each file system operation;

computer readable code segment in the propagating signal comprising code configured to write the altered in-core copy corresponding to each file system operation to the master device;

computer readable code segment in the propagating signal comprising code configured to accumulate a plurality of the file system operations into a single logging transaction; and

computer readable code segment in the propagating signal comprising code configured to perform the single logging transaction by writing the single logging transaction to the logging device.

5. The computer program product of claim 4 wherein the file system operations comprise synchronous file system operations.

6. A computer system having a processor and a memory operatively coupled to the processor, the computer system comprising:

a mass storage device coupled to the processor for receiving data, the mass storage device having a logging device and a master device;

an operating system executing on the processor, the operating system operatively coupled to application programs for performing a plurality of file system operations;

a journaling file system implemented within the operating system, the journaling file system coupled to write log transactions to the logging device and file system transactions to the master device; and

a transaction device within the journaling file system for creating a single log transaction for accumulating log records corresponding to a plurality of file system operations.

7. The computer system of claim 6 wherein the file system operations comprise synchronous file system operations.

8. The computer system of claim 6 wherein each file system transaction is associated with a log record, and each log transaction comprises one or more log records.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present invention is related to the subject matter of U.S. Pat. No. 5,778,168 filed on even date herewith for: "Transaction Device Driver Technique For a Journaling File System to Ensure Atomicity of Write Operations to a Computer Mass Storage Device", assigned to Sun Microsystems, Inc., Mountain View, Calif., assignee of the present invention, the disclosure of which is hereby specifically incorporated by this reference.

BACKGROUND OF THE INVENTION

The present invention relates, in general, to the field of file systems ("FS") of computer operating systems ("OS"). More particularly, the present invention relates to a single transaction technique for a journaling file system of a computer operating system in which a journal, or log, contains sequences of file system updates grouped into atomic transactions which are committed with a single computer mass storage device write operation.

Modern UNIX.RTM. OS file systems have significantly increased overall computer system availability through the use of "journaling" in which a journal, or log, of file system operations is sequentially scanned at boot time. In this manner, a file system can be brought on-line more quickly than implementing a relatively lengthy check-and-repair step.

Unfortunately, journaling may nevertheless serve to decrease a FS performance in synchronous operations, which type of operations are required for compliance with several operating system standards such as POSIX, SVID and NFS. Synchronous file system operations are ones in which each operation is treated as a separate transaction and each such operation requires at least one write to an associated computer mass storage, or disk drive, per operation. Stated another way, a synchronous file system operation is one in which all data must be written to disk, or the transaction "committed", before returning to a particular application program. As such, synchronous operations can decrease a journaling FS performance by creating a "bottleneck" at the logging device as each synchronous operation writes its transaction into the log.

SUMMARY OF THE INVENTION

The single transaction technique for journaling file systems disclosed herein is of especial utility in overcoming the performance degradation which may be experienced in conventional journaling file systems by entering each file system operation into the current active transaction. Consequently, each transaction is composed of a plurality of file system operations which are then simultaneously committed with a single computer mass storage device disk drive "write". In addition to increasing overall file system performance under even light computer system operational loads, even greater performance enhancement is experienced under relatively heavy loads.

In order to effectuate the foregoing, a method is herein disclosed for writing data to a computer mass storage device in conjunction with a computer operating system having a journaling file system. The method comprises the steps of opening a single file system transaction for accumulating a plurality of current synchronous file system operations; performing the plurality of current synchronous file system operations and then closing the single file system transaction upon completion of a last of the current file system operations. The single file system transaction is then committed to the computer mass storage device in a single write operation.

The present invention is implemented, in part, by adding a journal, or log, to the OS file system including any System V-based UNIX.RTM. OS incorporating a UFS layer or equivalent, the IBM AIX.RTM. or Microsoft Windows NT.TM. operating systems. The journal contains sequences of file system updates grouped into atomic transactions and is managed by a novel type of metadevice, the metatrans device. The addition of a journal to the operating system provides faster reboots and fast synchronous writes (e.g. network file system ("NFS"), O.sub.-- SYNC and directory updates).

In the specific embodiment disclosed herein, the present invention is advantageously implemented as an extension to the UFS file system and serves to provide faster synchronous operations and faster reboots through the use of a log. File system updates are safely recorded in the log before they are applied to the file system itself. The design may be advantageously implemented into corresponding upper and lower layers. At the upper layer, the UFS file system is modified with calls to the lower layer that record file system updates. The lower layer consists of a pseudo-device, the metatrans device, that is responsible for managing the contents of the log.

The metatrans device is composed of two subdevices, the logging device, and the master device. The logging device contains the log of file system updates, while the master device contains the file system itself. The existence of a separate logging device is invisible to user program code and to most of the kernel. The metatrans device presents conventional block and raw interfaces and behaves like an ordinary disk device.

Utilizing conventional OS approaches, file systems must be checked before they can be used because shutting down the system may interrupt system calls that are in progress and thereby introduce inconsistencies. Mounting a file system without first checking it and repairing any inconsistencies can cause "panics" or data corruption. Checking is a relatively slow operation for large file systems because it requires reading and verifying the file system meta-data. Utilizing the present invention, file systems do not have to be checked at boot time because the changes from unfinished system calls are discarded. As a result, it is ensured that on-disk file system data structures will always remain consistent, that is, that they do not contain invalid addresses or values. The only exception is that free space may be lost temporarily if the system crashes while there are open but unlinked files without directory entries. A kernel thread eventually reclaims this space.

The present invention also improves synchronous write performance by reducing the number of write operations and eliminating disk seek time. Writes are smaller because deltas are recorded in the log rather than rewriting whole file system blocks. Moreover, there are fewer of the blocks because related updates are grouped together into a single write operation. Disk drive seek time is significantly reduced because writes to the log are sequential.

As described herein with respect to a specific embodiment of the present invention, UFS on-disk format may be retained, no changes are required to add logging to an existing UFS file system and the log can subsequently be removed to return to standard UFS with UFS utilities continuing to operate as before. Additionally, file systems do not have to be checked for consistency at boot time. The driver must scan the log and rebuild its internal state to reflect any completed transactions recorded there. The time spent scanning the log depends on the size of the log device but not on the size of the file system. For reasonably foreseeable configuration choices, scan times on the average of 1-10 seconds per gigabyte of file system capacity may be encountered.

NFS writes and writes to files opened with O.sub.-- SYNC are faster because file system updates are grouped together and written sequentially to the logging device. This means fewer writes and greatly reduced seek time. Significantly improved speed-up may be expected at a cost of approximately 50% higher central processor unit ("CPU") overhead. Also, NFS directory operations are faster because file system updates are grouped together and written sequentially to the logging device. Local operations are even faster because the logging of updates may optionally be delayed until sync(), fsync(), or a synchronous file system operation. If no logging device is present, directory operations may be completed synchronously, as usual.

If a power failure occurs while a write to the master or logging device is in progress, the contents of the last disk sector written is unpredictable and may even be unreadable. The log of the present invention is designed so that no file system metadata is lost under these circumstances. That is, the file system remains consistent in the face of power failures. In the specific embodiment described in detail herein, users may set up and administer the metatrans device using standard MDD utilities while the metainit(1 m), metaparam(1 m), and metastat(1 m) commands have small extensions. Use is therefore simplified because there are no new interfaces to learn and the master device and logging device together behave like a single disk device. Moreover, more than one UFS file system can concurrently use the same logging device. This simplifies system administration in some situations.

In conventional UFS implementations, the file system occupies a disk partition, and the file system code performs updates by issuing read and write commands to the device driver for the disk. With the extension of the present invention, file system information may be stored in a logical device called a metatrans device, in which case the kernel communicates with the metatrans driver instead of a disk driver. Existing UFS file systems and devices may continue to be used without change.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned and other features and objects of the present invention and the manner of attaining them will become more apparent and the invention itself will be best understood by reference to the following description of a preferred embodiment taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a simplified representational drawing of a general purpose computer forming a portion of the operating environment of the present invention;

FIG. 2 is a simplified representational illustration providing an architectural overview of how selected elements of the computer program for effectuating a representative implementation of the present invention interact with the various layers and interfaces of a computer operating system;

FIG. 3 is a more detailed representative illustration of the major functional components of the computer program of FIG. 2 showing in greater detail the components of the metatrans device and its interaction through the Vop or VFS interface of a System V-based computer operating system in accordance with the exemplary embodiment hereinafter described;

FIG. 4 is a simplified logical block diagram illustrative of the fact that the unit structure for the metatrans devices contains the address of the logging device unit structure and vice versa;

FIG. 5 is an additional simplified logical block diagram illustrative of the fact that the logging device's unit structures are maintained on a global linked list anchored by ul.sub.-- list and that each of the metatrans unit structures for the metatrans devices sharing a logging device are maintained on a linked list anchored by the logging device's unit structure;

FIG. 6 is a further simplified logical block diagram showing that the logmap contains a mapentry.sub.-- t for every delta in the log that needs to be rolled to the master device and the map entries are hashed by (metatrans dev, metatrans device offset) and maintained on a linked list in the order that they should be rolled in;

FIG. 7 is a simplified logical block diagram showing that the unit structures for the metatrans device and the logging device contain the address for the logmap;

FIG. 8 is an additional simplified logical block diagram illustrative of the fact that a deltamap is associated with each metatrans device and stores the information regarding the changes that comprise a file system operation with the metatrans device creating a mapentry for each delta which is stored in the deltamap;

FIG. 9 is a further simplified logical block diagram showing that, at the end of a transaction, the callback recorded with each map entry is called and the logmap layer stores the delta plus data in the log's write buffer and puts the map entries into the logmap;

FIG. 10 is a simplified logical block diagram showing that the logmap is also used for read operations and, if the buffer being read does not overlap any of the entries in the logmap, then the read operation is passed down to the master device, otherwise, the data for the buffer is a combination of data from the master device and data from the logging device;

FIG. 11 illustrates that, early in the boot process, each metatrans device records itself with the UFS function, ufs.sub.-- trans.sub.-- set, creates a ufstrans struct and links it onto a global linked list;

FIG. 12 further illustrates that, at mount time, the file system checks its dev.sub.-- t against the other dev.sub.-- t's stored in the ufstrans structs and, if there is a match, the file system stores the address of the ufstrans struct in its file system specific per-mount struct (ufsvfs) along with its generic per-mount struct (vfs) in the ufstrans struct; and

FIG. 13 is an additional illustration of the interface between the operating system kernel and the metatrans driver shown in the preceding figures showing that the file system communicates with the driver by calling entry points in the ufstransops struct, inclusive of the begin-operation, end-operation and record-delta functions.

DESCRIPTION OF A PREFERRED EMBODIMENT

The environment in which the present invention is used encompasses the general distributed computing system, wherein general purpose computers, workstations or personal computers are connected via communication links of various types, in a client-server arrangement, wherein programs and data, many in the form of objects, are made available by various members of the system for execution and access by other members of the system. Some of the elements of a general purpose workstation computer are shown in FIG. 1, wherein a processor 1 is shown, having an input/output ("I/O") section 2, a central processing unit ("CPU") 3 and a memory section 4. The I/O section 2 is connected to a keyboard 5, a display unit 6, a disk storage unit 9 and a compact disk read only memory ("CDROM") drive unit 7. The CDROM unit 7 can read a CDROM medium 8 which typically contains programs 10 and data. The computer program products containing mechanisms to effectuate the apparatus and methods of the present invention may reside in the memory section 4, or on a disk storage unit 9 or on the CDROM 8 of such a system.

With reference now to FIG. 2, s simplified representational view of the architecture 20 for implementing the present invention is shown in conjunction with, for example, a System V-based UNIX operating system having a user (or system call) layer 22 and a kernel 24. With modifications to portions of the user layer 22 (i.e. the MDD3 and mount utilities 28) and kernel 24 (i.e. the UFS layer 30) as will be more fully described hereinafter, the present invention is implemented primarily by additions to the metatrans layer 26 in the form of a metatrans driver 32, transaction layer 34, roll code 36, recovery code 38 and an associated log (or journal) code 40.

The MDD3 Utilities administer the metatrans driver 32 and set up, tear down and give its status. The mount utilities include a new feature ("syncdir") which disables the delayed directory updates feature. The UFS layer 30 interfaces with the metatrans driver 32 at mount, unmount and when servicing file system calls. The primary metatrans driver 32 interfaces with the base MDD3 driver and the transaction layer 34 interfaces with the primary metatrans driver 32 and with the UFS layer 30. The roll code 36 rolls completed transactions to the master device and also satisfies a read request by combining data from the various pieces of the metatrans driver 32. The recovery code scans the log and rebuilds the log map as will be more fully described hereinafter while the log code presents the upper layers of the operating system with a byte stream device and detects partial disk drive write operations.

With reference additionally now to FIG. 3, the major components of the architecture of the present invention is shown in greater detail. The UFS layer 30 is entered via the VOP or VFS interface 42. The UFS layer 30 changes the file system by altering in-core copies of the file system's data. The in-core copies are kept in the buffer or page cache 41. The changes to the in-core copies are called deltas 43. UFS tells the metatrans driver 32 which deltas 43 are important by using the transops interface 45 to the metatrans device 32.

The UFS layer does not force a write after each delta 43. This would be a significant performance loss. Instead, the altered buffers and pages are pushed by normal system activity or by ITS at the end of the VOP or VFS interface 42 call that caused the deltas 43. As depicted schematically, the metatrans driver 32 looks like a single disk device to the upper layers of the kernel 24. Internally, the metatrans driver 32 is composed of two disk devices, the master and log devices 44, 46. Writes to the metatrans device 32 are either passed to the master device 44 via bdev.sub.-- strategy or, if deltas 43 have been recorded against the request via the transops interface 45, then the altered portions of the data are copied into a write buffer 50 and assigned log space and the request is biodone'ed. The deltas 43 are moved from the delta map 48 to the log map 54 in this process.

The write buffer 50 is written to the log device 46 when ITS issues a commit (not shown) at the end of a VOP or VFS layer 42 call or when the write buffer 50 fills. Not every VOP or VFS layer 42 call issues a commit. Some transactions, such as lookups or writes to files *not* opened O.sub.-- SYNC, simply collect in the write buffer 50 as a single transaction.

Reading the metatrans device 32 is somewhat complex because the data for the read can come from any combination of the write buffers 50, read buffers 52, master device 44, and log device 46. Rolling the data from the committed deltas 43 forward to the master device 44 appears generally as a "read" followed by a "write" to the master device 44. The difference is that data can also come from the buffer or page caches 41. The affected deltas 43 are removed from the log map 54. The roll/read code block 56 is coupled to the master and log devices 44, 46 as well as the write and read buffers 50, 52 and interfaces to the buffer or page drivers 58.

With reference now to FIG. 4, it can be seen that early in the boot process, the On-line: Disksuite ("ODS") state databases are scanned and the in-core state for the metadevices is re-created. Each metadevice is represented by a unit structure and the unit structure for the metatrans devices contains the address of its logging device unit structure, and vice versa. The metatrans device 60 unit structure is mt.sub.-- unit.sub.-- t and is defined in md.sub.-- trans.h. The logging device 62 unit structure is ml.sub.-- unit.sub.-- t and is also defined in md.sub.-- trans.h.

Referring additionally now to FIG. 5, the logging device 62 unit structures are maintained on a global linked list anchored by ul.sub.-- list. Each of the metatrans device 60 unit structures for the metatrans devices 60 sharing a logging device 62 are kept on a linked list anchored by the logging device's unit structure.

With reference additionally to FIG. 6, after the unit structures are set up, a scan thread is started for each logging device 62. The scan thread is a kernel thread that scans a log device 62 and rebuilds the logmap 64 for that logging device 62. The logmap 64 is mt.sub.-- map.sub.-- t and is defined in md.sub.-- trans.h. The logmap 64 contains a mapentry.sub.-- t for every delta 43 in the log that needs to be rolled to the master device. The map entries 68 are hashed by the hash anchors 66 (metatrans device, metatrans device offset) for fast lookups during read operations. In order to enhance performance, the map entries 68 are also maintained on a linked list in the order in which they should be rolled in. As shown schematically in FIG. 7, the unit structures for the metatrans device 60 and the logging device 62 contain the address of the logmap 64 (log map 54 in FIG. 3), which is associated with the hashed mapentries 70 and all mapentries 72.

Referring also now to FIG. 8, a deltamap 74 is associated with each metatrans device 60. The deltamap 74 stores the information about the changes that comprise a file system operation. The file system informs the metatrans device 60 about this changes (or deltas 43) by recording the tuple (offset on master device 44, No. of bytes of data and callback) with the device. The metatrans device 60 in conjunction with hash anchors 76 creates a mapentry 78 for each delta 43 which is stored in the deltamap 74 (delta map 48 in FIG. 3). The deltamap 74 is an mt.sub.-- map.sub.-- t like the logmap 64 (FIGS. 6-7) and has the same structure.

With reference also to FIG. 9, at the end of a transaction, the callback recorded with each map entry 68 is called in the case of "writes" involving logged data. The callback is a function in the file system that causes the data associated with a delta 43 to be written. When this "write" appears in the metatrans driver, the driver detects an overlap between the buffer being written 80 and deltas 43 in the deltamap 74. If there is no overlap, then the write is passed on to the master device 44 (FIG. 3). If an overlap is detected, then the overlapping map entries are removed from the deltamap 74 and passed down to the logmap layer.

The logmap layer stores the delta 43+data in the log's write buffer 50 and puts the map entries into the logmap 64. It should be noted that the data for a delta 43 may have been written before the end of a transaction and, if so, the same process is followed. Once the data is copied into log's write buffer 50, then the buffer is iodone'ed.

Among the reasons for using the mt.sub.-- map.sub.-- t architecture for the deltamap 74 is that the driver cannot user kmem.sub.-- alloc. The memory for each entry that may appear in the logmap needs to be allocated before the buffer appears in the driver. Since there is a one-to-one correspondence between deltas 43 in the deltamap 74 and the entries in the logmap 64, it is apparent that the deltamap entries 78 should be the same as the logmap entries 68.

Referring now to FIG. 10, the analogous situation of "reads" involving logged data is illustrated. As can be seen, the logmap 64 is also used for read operations. If the buffer being read does not overlap any of the entries 68 in the logmap 64, then the "read" is simply passed down to the master device 44. On the other hand, if the buffer does overlap entries 68 in the logmap 64, then the data for the buffer is a combination of data from the master device 44 and data from the logging device 46.

With reference to FIGS. 11 and 12, the situation at mount time is illustrated schematically. Early in the boot process, each metatrans device records itself with the UFS function, ufs.sub.-- trans.sub.-- set and creates a ufstrans struct 84 and links it onto a global linked list. At mount time, the file system checks its dev.sub.-- t against the dev.sub.-- t's stored in the ufstrans structs 86. If there is a match, then the file system stores the address of the ufstrans struct 86 its file system specific per-mount struct, the ufsvfs 90. The file system also stores its generic per-mount struct, the vfs 88, in the ufstrans struct 86. This activity is accomplished by mountfs() and by ufs.sub.-- trans.sub.-- get(). The address of the vfs 88 is stored in the ufstrans struct 86 due to the fact that the address is required by various of the callback functions.

The file system communicates with the metatrans driver 32 (FIGS. 2-3) by calling the entry points in the ufstransops 92 struct. These entry points include the begin-operation, end-operation and record-delta functions. Together, these three functions perform the bulk of the work needed for transacting UFS layer 30 operations. FIG. 13 provides a summary of the data structures of the present invention as depicted in the preceding figures and as will be more fully described hereinafter.

The metatrans device, or driver 32 contains two underlying devices, a logging device 46 and a master device 44. Both of these can be disk devices or metadevices (but not metatrans devices). Both are under control of the metatrans driver and should generally not be accessible directly by user programs or other parts of the system. The logging device 46 contains a journal, or log. The log is a sequence of records each of which describes a change to a file system (a delta 43). The set of deltas 43 corresponding to the currently active vnode operations form a transaction. When a transaction is complete, a commit record is placed in the log. If the system crashes, any uncommitted transactions contained in the log will be discarded on reboot. The log may also contain user data that has been written synchronously (for example, by NFS). Logging this data improves file system performance, but is not mandatory. If sufficient log space is not available user data may be written directly to the master device 44. The master device 44 contains a UFS file system in the standard format. If a device that already contains a file system is used as the master device 44, the file system contents will be preserved, so that upgrading from standard UFS to extension of the present invention is straightforward. The metatrans driver updates the master device 44 with completed transactions and user data. Metaclear(1 m) dissolves the metatrans device 32, so that the master device 44 can again be used with standard UFS if desired.

The metatrans device 32 presents conventional raw and block interfaces and behaves like an ordinary disk device. A separate transaction interface allows the file system code to communicate file system updates to the driver. The contents of the device consist of the contents of the master device 44, modified by the deltas 43 recorded in the log.

Through the transaction interface, UFS informs the driver what data is changing in the current transaction (for instance, the inode modification time) and when the transaction is finished. The driver constructs log records containing the updated data and writes them to the log. When the log becomes sufficiently full, the driver rolls it forward. In order to reuse log space, the completed transactions recorded in the log must be applied to the master device 44. If the data modified by a transaction is available in a page or buffer in memory, the metatrans driver simply writes it to the master device 44. Otherwise, the data must be read from the metatrans device 32. The driver reads the original data from the master device 44, then reads the deltas 43 from the log and applies them before writing the updated data back to the master device 44. The effective caching of SunOS.TM. developed and licensed by Sun Microsystems, Inc., assignee of the present invention, makes the latter case occur only rarely and in most instances, the log is written sequentially and is not read at all.

UFS may also cancel previous deltas 43 because a subsequent operation has nullified their effect. This canceling is necessary when a block of metadata, for instance, an allocation block, is freed and subsequently reallocated as user data. Without canceling, updates to the old metadata might be erroneously applied to the user data.

The metatrans driver keeps track of the log's contents and manages its space. It maintains the data structures for transactions and deltas 43 and keeps a map that associates log records with locations on the master device 44. If the system crashes, these structures are reconstructed from the log the next time the device is used (but uncommitted transactions are ignored). The log format ensures that partially written records or unused log space cannot be mistaken for valid transaction information. A kernel thread is created to scan the log and rebuild the map on the first read or write on a metatrans device 32. Data transfers are suspended until the kernel thread completes, though driver operations not requiring I/O may proceed.

One of the principle benefits of the present invention is to protect metadata against corruption by power failure. This imposes a constraint on the contents of the log in the case when the metatrans driver is applying a delta 43 to the master device 44 when power fails. In this case, the file system object that is being updated may be partially written or even corrupted. The entire contents of the object from the log must still be recovered. To accomplish this, the driver guarantees that a copy of the object is in the log before the object is written to the master device 44.

The metatrans device 32 does not attempt to correct other types of media failure. For instance, a device error while writing or reading the logging device 46 puts the metatrans device 32 into an exception state. The metatrans device 32's state is kept in the MDD database. There are different exception states based on when the error occurs and the type of error.

Metatrans device 32 configuration may be performed using standard MDD utilities. The MDD dynamic concatenation feature allows dynamic expansion of both the master and logging devices 44, 46. The device configuration and other state information is stored in the MDD state database, which provides replication and persistence across reboots. The space required to store the information is relatively small, on the order of one disk sector per metatrans device 32.

In a particular implementation of the present invention, UFS checks whether a file system resides on a metatrans device 32 at mount time by calling ufs.sub.-- trans.sub.-- get(). If the file system is not on a metatrans device 32, this function returns NULL; otherwise, it returns a handle that identifies the metatrans device 32. This handle is saved in the mount structure for use in subsequent transaction operations. The functions TRANS.sub.-- BEGIN() and TRANS END() indicate the beginning and end of transactions. TRANS DELTA() identifies a change to the file system that must be logged. TRANS.sub.-- CANCEL() lets UFS indicate that previously logged deltas 43 should be canceled because a file system data structure is being recycled or discarded.

When the file system check ("fsck") utility is run on a file system in accordance with the present invention, it checks the file system's clean flag in the superblock and queries the file system device via an ioctl command. When both the superblock and device agree that the file system is on a metatrans device 32, and the device does not report any exception conditions, fsck is able to skip further checking. Otherwise, it checks the file system in a conventional manner.

When the "quotacheck" utility is run on a file system in accordance with the present invention, it checks the system's clean flag in the superblock and queries the file system device via an ioctl command. When both the superblock and device agree that the file system is on a metatrans device 32, and the device does not report any exception conditions, quotacheck doesn't have to rebuild the quota file. Otherwise, it rebuilds the quota file for the file system in a conventional manner.

The logging mechanism of the present invention ensures file system consistency, with the exception of lost free space. If there were open but deleted files (that is, not referred to by any directory entry) when the system went down, the file system resources claimed by these files will be temporarily lost. A kernel thread will reclaim these resources without interrupting service. As a performance optimization, a previously unused field in the file system's superblock, fs.sub.-- sparecon[53], indicates whether any files of this kind exist. If desired, fsck can reclaim the lost space immediately and fs.sub.-- sparecon[53] will be renamed fs.sub.-- reclaim.

Directories may be changed by a local application or by a daemon running on behalf of a remote client in a client-server computer system. In the standard UFS implementation, both remote and local directory changes are made synchronously, that is, updates to a directory are written to the disk before the request returns to the application or daemon. Local directory operations are synchronous so that the file system can be automatically repaired at boot time. The NFS protocol requires synchronous directory operations. Using the technique of the present invention, remote directory changes are made synchronously but local directory changes are held in memory and are not written to the log until a sync(), fsync(), or a synchronous file system operation forces them out. As a result, local directory changes can be lost if the system crashes but the file system remains consistent. Local directory changes remain ordered.

Holding the local directory updates in memory greatly improves performance. This introduces a change in file system semantics, since completed directory operations may now disappear following a system crash. However, the old behavior is not mandated by any standard, and it is expected that few, if any, applications would be affected by the change. This feature is implemented in conventional file systems, such as Veritas, Episode, and the log-structured file system of Ousterhout and Mendelblum. Users can optionally revert back to synchronous local directory updates.

The MDD initialization utility, metainit(1 m), may be extended to accept the configuration lines of the following form:

    ______________________________________
    mdNN -t master log [-n]
    mdNN  A metadevice name that will represent the metatrans device.
    master
          The master device; a metadevice or ordinary disk device.
    log   The log device; a metadevice or ordinary disk device. The same
          log may be used in multiple metatrans devices, in which case it
          is shared among them.
    ______________________________________

    ______________________________________
    mdXX:      metatrans device
                Master device:mdYY
                Logging device:mdZZ
                <state information>
    mdYY:      metamirror, master device for mdXX
                <usual status>
    mdZZ:      metamirror, logging device for mdXX
                <usual status>
    ______________________________________

    ______________________________________
    <sys/fs/ufs.sub.-- inode.h>
    struct ufsvfs may contain a pointer to struct metatrans to identify the
    metatrans device.
    i.sub.-- doff is added to struct inode.
    <sys/fs/ufs.sub.-- quota.h>
    struct dquot may have the new field dq.sub.-- doff.
    <sys/fs/ufs.sub.-- fs.h>
    The new clean flag value FSLOG is defined here. fs.sub.-- sparecon [53]
    is
    renamed fs-reclaim.
    <sys/fs/ufs.sub.-- trans.h>
    <sys/md.sub.-- trans.h>
    ______________________________________

    ______________________________________
    A metatrans device 32 records itself with UFS when the metatrans
    device 32 is created or is recreated at boot:
      struct ufstrans*
    ufs.sub.-- trans.sub.-- set(
        dev.sub.-- t dev,
        struct ufstransops *ops,
        void *data)
    ______________________________________

    ______________________________________
    struct ufstansops {
     int (*trans.sub.-- begin)(struct ufstrans *, top.sub.-- t,u.sub.-- long,
    u.sub.-- long);
     void (*tran.sub.-- end)(struct ufstrans *, top.sub.-- t, u.sub.-- long,
    u.sub.-- long);
     void (*trans.sub.-- delta)(struct ufstrans *, off.sub.-- t, off.sub.--
    t, delta.sub.-- t,
     int (*)(), u.sub.-- long);
     void (*trans.sub.-- cancel)(struct ufstrans *, off.sub.-- t, off.sub.--
    t, delta.sub.-- t);
     int (*trans.sub.-- log)(struct ufstrans *, char *, off.sub.-- t,
    off.sub.-- t);
     void (*trans.sub.-- mount)(struct ufstrans *, struct fs *);
     void (*trans.sub.-- unmount)(struct ufstrans *, struct fs *);
     void (*trans.sub.-- remount)(struct ufstrans *, struct fs *);
     void (*trans.sub.-- iget)(struct ufstrans *, struct inode *);
     void (*trans.sub.-- free.sub.-- iblk)(struct ufstrans *, struct inode *,
    daddr.sub.-- t);
     void (*trans.sub.-- free)(struct ufstrans *, struct inode *,
    daddr.sub.-- t, u.sub.-- long);
     void (*trans.sub.-- alloc)(struct ufstrans *, struct inode *,
    daddr.sub.-- t;
     u.sub.-- long, int);
    };
    ______________________________________

    ______________________________________
     struct ufstrans {
      struct ufstrans
                *ut.sub.-- next
                             /* next item in list */
      dev.sub.-- t
                ut.sub.-- dev;
                             /* metatrans device no. */
      struct ufstransops
                *ut.sub.-- ops;
                             /* metatrans ops */
      struct vfs
                *ut.sub.-- vfsp;
                             /* XXX for inode pushes */
      void      *ut data;    /* private data (?) */
      void      (*ut.sub.-- onerror)();
                             /* callback ufs on error */
      int       ut.sub.-- onerror.sub.-- state;
                            /* fs specitic state
    };
    ufs.sub.-- trans.sub.-- reset() unlinks and frees the ufstrans
    structure.
    ufs.sub.-- trans.sub.-- reset () is called when a metatrans device is
    cleared.
    ______________________________________

    __________________________________________________________________________
    /*
    * vfs.sub.-- trans == NULL means no metatrans device
    /*
    #define TRANS.sub.-- ISTRANS(ufsvfsp)(ufsvfsp->vfs.sub.-- trans)
    /*
    * begin a transaction
    /*
    #define
        TRANS.sub.-- BEGIN(ufsvfsp, vid, vsize, flag)
        (TRANS.sub.-- ISTRANS(ufsvfsp))?
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- begin)
            (ufsvfsp->vfs.sub.-- trans, vid, vsize, flag): 0)
    /*
    * end a transaction
    /*
    #define
        TRANS.sub.-- END(ufsvfsp, vid, vsize, flag)
        if (TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- end)
            (ufsvfsp->vfs.sub.-- trans, vid, vsize, flag)
    /*
    *record a delta
    /*
    #define
        TRANS.sub.-- DELTA(ufsvfsp, mof, nb, dtyp, func, arg)
        if (TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- delta)
            (ufsvfsp->vfs.sub.-- trans, mof, nb, dtyp, func,
                                        arg)
    /*
    *cancel a delta
    /*
    #define
        TRANS.sub.-- CANCEL(ufsvfsp, mof, nb, dtyp)
        if (TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- cancel)
            (ufsvfsp->vfs.sub.-- trans, mof, nb, dtyp)
    /*
    * log a delta
    /*
    #define
        TRANS.sub.-- LOG(ufsvfsp, va, mof, nb)
        if TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- log)
            (ufsvfsp->vfs.sub.-- trans, va, mof, nb)
    /*
    * The following macros provide a more readable interface to TRANS.sub.--
    DELTA
    /*
    #define
        TRANS.sub.-- BUF(ufsvfsp, vof, nb, bp, type)
        TRANS-DELTA(ufsvfsp,
    dbtob(bp->b.sub.-- blkno) + vof, nb, type,
            ufs.sub.-- trans.sub.-- push.sub.-- buf, bp->b.sub.-- blkno)
    #define
        TRANS.sub.-- BUF.sub.-- ITEM (ufsvfsp, item, base, bp,
                               TRANS.sub.-- DELTA(ufsvfsp,
    (caddr.sub.-- t)&(item) - (caddr.sub.-- t)(base),
    sifecf (item), bp, type)
    #define
        TRANS.sub.-- INODE(ufsvfsp, vof, nb, ip)
        TRANS.sub.-- DELTA(ufsvfsp, ip->i.sub.-- doff +vof,
    nb, DT.sub.-- INODE, ufs.sub.-- trans.sub.-- push.sub.-- inode, ip
    #define
        TRANS.sub.-- INODE.sub.-- ITEM(ufsvfsp, item, ip)
        TRANS-INODE(ufsvfsp,(caddr.sub.-- t)&(item) - (caddr.sub.-- t)&ip->i.s
        ub.-- ic,sizeof (item), ip)
    #define
        TRANS.sub.-- SI(ufsvfsp, fs, cg)
        TRANS.sub.-- DELTA(ufsvfsp,
    dbtob(fsbtodb(fs, fs->fs.sub.-- csaddr)) +
    (caddr.sub.-- t)&fs->fs.sub.-- cs(fs, cg) - (cadr.sub.-- t)fs->fs.sub.--
    csp[0],
    sizeof (struct csum), DT.sub.-- SI, ufs.sub.-- trans.sub.-- push.sub.--
    si, cg)
    #define
        TRANS.sub.-- SB(ufsvfsp, item, fs)
        TRANS.sub.-- DELTA(ufsvfsp,
    dbtob(SBLOCK) + (caddr.sub.-- t)&(item) - (caddr.sub.-- t)fs),
    sizeof (item), DT.sub.-- SB, ufs.sub.-- trans.sub.-- push.sub.-- sb, 0)
    /*
    *   These functions "wrap" functions that are not VOP or VFS
    *   entry points but must still use the TRANS.sub.-- BEGIN/TRANS.sub.--
        END
    *   protocol
    */
    #define
        TRANS.sub.-- SBUPDATE(ufsvfsp, vfsp, topid)
        ufs.sub.-- trans.sub.-- sbupdate(ufsvfsp, vfsp, topid)
    #define
        TRANS.sub.-- SYNCIP(ip, bflags, iflag, topid)
        ufs.sub.-- trans.sub.-- syncip(ip, bflags, iflag, topid)
    #define
        TRANS.sub.-- SBWRITE(ufsvfsp, topid) fs.sub.-- trans.sub.-- sbwrite(uf
        svfsp, topid)
    #define
        TRANS.sub.-- IUPDAT(ip, waitfor) ufs.sub.-- trans.sub.-- iupdat(ip,
                                       waitfor)
    #define
        TRANS.sub.-- PUTPAGES(vp, off, len, flags, cred)
        ufs.sub.-- trans.sub.-- putpages(vp, off, len, flags, cred)
    /*
    Test/Debug ops
    *   The following ops maintain the metadata map.
    #define
        TRANS.sub.-- IGET(ufsvfsp, ip)
        if (TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- iget)
            (ufsvfsp->vfs.sub.-- trans, ip, bno, size)
    #define
        TRANS.sub.-- FREE.sub.-- IBLK(ufsvfsp, ip, bn)
        if TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- free.sub.--
    iblk)
            (ufsvfsp->vfs.sub.-- trans, ip, bn)
    #define
        TRANS.sub.-- ISTRANS(ufsvfsp, ip, bno, size)
        if TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans,->ut.sub.-- ops->trans.sub.-- free)
            (ufsvfsp->vfs.sub.-- trans, ip, bno, size)
    #define
        TRANS.sub.-- ALLOC)ufsvfsp, ip, bno, size, zero)
        if (TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- alloc)
            (ufsvfsp->vfs.sub.-- trans, ip, bno, size, zero)
    #define
        TRANS.sub.-- MOUNT(ufsvfsp, fsp)
        if (TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- mount)
            (ufsvfsp->vfs.sub.-- trans, fsp)
    #define
        TRANS.sub.-- UMOUNT(ufsvfsp, fsp)
        if(TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- umount)
            (ufsvfsp->vfs.sub.-- trans, fsp)
    #define
        TRANS.sub.-- REMOUNT)ufsvfsp, fsp)
        if TRANS.sub.-- ISTRANS(ufsvfsp))
    (*ufsvfsp->vfs.sub.-- trans->ut.sub.-- ops->trans.sub.-- remount)
            (ufsvfsp->vfs.sub.-- trans, fsp)
    __________________________________________________________________________

    ______________________________________
    /* Statistics on inodes */
    struct instats {
    int in.sub.-- hits;
                      /* Cache hits */
    int in.sub.-- misses;
                      /* Cache misses */
    int in.sub.-- malloc;
                      /* kmem.sub.-- allocated */
    int in.sub.-- mfree;
                      /* kmem.sub.-- free'd */
    int in.sub.-- maxsize;
                      /* Largest size reached by cache */
    int in.sub.-- frfront;
                      /* put at front of freelist */
    int in.sub.-- frback;
                      /* put at back of freelist */
    int in.sub.-- dnlclook;
                      /* examined in dnlc */
    int in.sub.-- dnlcpurge;
                      /* purged from dnlc */
    int in.sub.-- inactive;
                      /* inactive calls */
    int in.sub.-- inactive.sub.-- nop;
                      /* inactive calls that nop'ed */
    int in.sub.-- inactive.sub.-- null;
                      /* inactive call with null vfsp */
    int in.sub.-- inactive.sub.-- delay.sub.-- free;
                      /* inactive delayed free's */
    int in.sub.-- inactive.sub.-- free;
                      /* inactive q's to free thread */
    int in.sub.-- inactive.sub.-- idle;
                      /* inactive q's to idle thread */
    int in.sub.-- inactive.sub.-- wakeups;
                      /* wakeups */
    int in.sub.-- scan;
                      /* calls to scan */
    int in.sub.-- scan.sub.-- scan;
                      /* inodes found */
    int in.sub.-- scan.sub.-- rwfail; /*  inode
                      rw.sub.-- tryenter's that failed */
    ______________________________________

    __________________________________________________________________________
    */
    * scan the hash of inodes and call func with the inode locked
    */
    int
    ufs.sub.-- scan.sub.-- inodes(int rwtry, int (*func)(struct inode *,
    void*),   void   *arg)
    struct inode *ip, *lip;
    struct vnode *vp;
    inion ihead *ih;
    int     error;
    int     saverror= 0;
    extern krwlock.sub.-- t icache.sub.-- lock;
    ins.in.sub.-- scan++;
    rw.sub.-- enter(&icache.sub.-- lock, RW.sub.-- READER);
    for (ih = ihead; ih < &ihead[INOHSZ]; ih++) {
    for (ip =ih->ih.sub.-- chain[0], lip = NULL;
    ip ! = (struct inode *)ih;
    ip = lip->i.sub.-- forw)
    ins.in.sub.-- scan.sub.-- scan++;
    vp = ITOV(ip);
    VN-HOLD(vp);
    rw.sub.-- exit(&icache.sub.-- lock);
    if (lip)
    VN.sub.-- RELE (ITOV(lip));
    lip = ip;
    /*
    *   Acquire the contents lock to make sure that the
    *   inode has been initialized in the cache.
    */
    if (rwtry)
    if    (!rw.sub.-- tryenter(&ip->i.sub.-- contents, RW.sub.-- WRITER))
          ins.in.sub.-- scan.sub.-- rwfail++;
          rw.sub.-- enter(&icache.sub.-- lock, RW.sub.-- READER);
          continue;
    }
    }   else
        rw.sub.-- enter(&ip->i.sub.-- contents, RW.sub.-- WRITER);
    rw.sub.-- exit(&ip->i.sub.-- contents);
    */
    * i.sub.-- number == 0 means bad initialization; ignore
    */
    if (ip->i number)
    if (error = (*func)(ip, arg))
    saverror = error;
    rw.sub.-- enter(&icache.sub.-- lock, RW.sub.-- READER);
    }
    if (lip) {
    rw.sub.-- exist(&icache.sub.-- lock);
    VN.sub.-- RELE (ITOV(lip)) ;
    rw.sub.-- enter(&icache.sub.-- lock, RW, READER);
    }
    }
    rw.sub.-- exit(&icache.sub.-- lock);
    return (saverror);
    __________________________________________________________________________

    ______________________________________
    */
    * each ufs thread is managed by this struct (ufs.sub.-- thread.c)
    */
    struct ufs.sub.-- q {
    void      *uq.sub.-- head;
                        /* first entry on q */
    void      *uq.sub.-- tail;
                        /* last entry on q
    long      uq.sub.-- ne;
                        /* # of entries */
    long      uq.sub.-- maxne;
                        /* thread runs when ne==maxne */
    u.sub.-- short
              uq.sub.-- nt;
                        /* # of threads serving this q */
    u.sub.-- short
              uq.sub.-- nf;
                        /* # of flushes requested */
    u.sub.-- short
              uq.sub.-- flags;
                        /* flags */
    kcondvar.sub.-- t
              uq.sub.-- cv;
                        /* for sleep/wakeup */
    kmutex.sub.-- t
              uq.sub.-- mutex;
                        /* protects this struct */
    };
    ______________________________________

    ______________________________________
    SINGLE.sub.-- TRANSACTION:
    If single transaction is closed
    wait for next single transaction to
    open
    Enter transaction
    Perform the synchronous operation
    Close this single transaction
    Wait for all current sync operations
    to finish
    Commit all sync operations with single
    disk write
    Open next single transaction
    Leave transaction
    ______________________________________

                  TABLE 1
    ______________________________________
    System Call          Commit  NFS Commit
    ______________________________________
    TOP.sub.-- OPEN
    TOP.sub.-- CLOSE
    TOP.sub.-- READ
    TOP.sub.-- WRITE             Y
    TOP.sub.-- WRITE.sub.-- SYNC
                         Y       Y
    TOP.sub.-- GETATTR
    TOP.sub.-- SETATTR           Y
    TOP.sub.-- SETATTR.sub.-- TRUNC
                                 Y
    TOP.sub.-- ACCESS
    TOP.sub.-- LOOKUP
    TOP.sub.-- CREATE            Y
    TOP.sub.-- REMOVE            Y
    TOP.sub.-- LINK              Y
    TOP.sub.-- RENAME            Y
    TOP.sub.-- MKDIR             Y
    TOP.sub.-- RMDIR             Y
    TOP.sub.-- READDIR
    TOP.sub.-- SYMLINK           Y
    TOP.sub.-- READLINK
    TOP.sub.-- FSYNC             Y
    TOP.sub.-- INACTIVE
    TOP.sub.-- FID
    TOP.sub.-- GETPAGE
    TOP.sub.-- PUTPAGE
    TOP.sub.-- MAP
    TOP.sub.-- FRLOCK
    TOP.sub.-- SPACE             Y
    TOP.sub.-- PATHCONF
    TOP.sub.-- VGET
    TOP.sub.-- SBUPDATE.sub.-- FLUSH
    TOP.sub.-- SBUPDATE.sub.-- UPDATE
    TOP.sub.-- SBUPDATE.sub.-- MOUNTROOT
    TOP.sub.-- SBUPDATE.sub.-- UNMOUNT
    TOP.sub.-- SYNCIP.sub.-- CLOSEDQ
    TOP.sub.-- SYNCIP.sub.-- TRYPAGE
    TOP.sub.-- SYNCIP.sub.-- FLUSHI
    TOP.sub.-- SYNCIP.sub.-- HLOCK
    TOP.sub.-- SYNCIP.sub.-- SYNC
    TOP.sub.-- SYNCIP.sub.-- FREE
    TOP.sub.-- SYNCIP.sub.-- FSYNC
                                 Y
    TOP.sub.-- SBWRITE.sub.-- FIOSDIO
    TOP.sub.-- SBWRITE.sub.-- CHECKCLEAN
    TOP.sub.-- SBWRITE.sub.-- RECLAIM
                         Y       Y
    TOP.sub.-- SBWRITE.sub.-- T.sub.-- RECLAIM
                         Y       Y
    TOP.sub.-- SBWRITE.sub.-- NOTCLEAN
                         Y       Y
    TOP.sub.-- IFREE
    TOP.sub.-- IUPDAT
    TOP.sub.-- MOUNT
    TOP.sub.-- COMMIT.sub.-- FLUSH
    TOP.sub.-- COMMIT.sub.-- UPDATE
    TOP.sub.-- COMMIT.sub.-- UNMOUNT
    ______________________________________

• Inventors
  Fuller, Billy J.;
• Assignee
  Sun Microsystems, Inc. (Palo Alto, CA)
• Published
  Feb-1-2000
• Current US Classes:
  707/200
  707/201
  707/202
  707/7
  714/15
  718/1
• Application #
  221624
• International Classes
  G06F 017/30
• Field of Search
  707/201 707/8 707/7 707/200 707/202 395/182.13 395/670
• Examiner
  Fetting; Anton W.
• Agent
  Holland & Hart LLP
• US Patent References:
  5001628
  5095421
  5355497
  5359713
  5603020
  5613060