PatentDe  


Dokumentenidentifikation EP0759592 03.04.1997
EP-Veröffentlichungsnummer 0759592
Titel System und Verfahren zur Verriegelung und Reparatur eines Dateisystems für ein Rechnerbetriebssystem
Anmelder Sun Microsystems, Inc., Mountain View, Calif., US
Erfinder Senator, Steven T., Colorado Springs, Colorado 80920, US
Vertreter derzeit kein Vertreter bestellt
Vertragsstaaten DE, FR, GB, IT, NL
Sprache des Dokument En
EP-Anmeldetag 01.08.1996
EP-Aktenzeichen 966500332
EP-Offenlegungsdatum 26.02.1997
Veröffentlichungstag im Patentblatt 03.04.1997
IPC-Hauptklasse G06F 11/00

Beschreibung[en]
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 system and method for selectably implementing and removing an "error lock" for file system "fix-on-panic" which is of particular utility with respect to computer operating systems incorporating a UNIX® System V File System ("VFS", also known as the "VFSop" or "Vnode") layer or similar OS file system interfaces.

File systems may be defined as groupings of files used to store named objects on persistent computer mass storage media. As such, files systems maintain a set of in-memory and on-disk data structures which must all be consistent with each other for proper functioning of the file system. UNIX operating systems, for example, resort to an enforced total system shutdown (a "panic") when these data structures are not consistent. This "panic" then renders the whole system unavailable for the duration of the time necessary to shut down the computer system, repair all on-disk inconsistencies and resume normal system operation.

Through the addition of the lock FS or ("lockfs") functionality to UNIX, the ability to lock a whole file system was presented which could be then implemented generically for any file system. This feature provides the ability to block selected operations according to differing kinds of locks. For example, a file system may be rendered temporarily and selectively unmodifiable (e.g. wherein a file may be precluded from being removed) with no other operation to it being blocked. A "blocked" operation is one that merely waits until the file system is again unlocked. In this connection, a "delete lock" or "name lock" is a type of lock wherein the file system may still be able to be changed, but only in certain predefined manners. Attempted access to a locked file system results in a perceived delay until the particular file system becomes unlocked.

Alternatively, a "hard lock" is one in which a particular file system is simply precluded from further access. A hard lock may be invoked, for example, when a storage media defect is detected and a data recovery action must then be implemented. Hard locks do not remove the file system from the name space but access to anything within it fails with an error and the only way to clear a hard lock is to unmount the file system. Significantly, if any file system on a given computer has a consistency problem, the computer then "goes down" and all of the services it provides then become unavailable for all users. This is a particularly acute and costly situation with existing client-server computer systems when it is the server computer that happens to be the one on the network to encounter a consistency problem.

In an attempt to avoid system down-time, it has previously been proposed to embed checking algorithms into the file system itself. Exemplary of this technique is the VXFS software from Veritas in which the checking is done in core utilizing a two phase commit protocol and the IBM journalled file system ("JFS") built upon a database-like model. In either case, the additional central processor unit ("CPU") "overhead" added to the file system to implement the checking function results in an overall slower system operation. Still another checking approach implemented by Auspex utilizes an algorithm running on a CPU dedicated solely to providing file system operations. As a consequence, the resultant system is unique to the particular hardware implementation for which it was designed and, therefore, has limited applicability to other architectures.

SUMMARY OF THE INVENTION

The present invention provides a method for selectably error locking a failed file system of a computer operating system, and a computer loaded with such an operating system as laid down in the independent claims. Further enhancements are provided by the dependent claims.

The system and method of the present invention provides an alternative file system locking mechanism to the existing "write" and "hard" locks which may be conveniently denominated an "error lock" which is used to implement file system "fix-on-panic". As disclosed herein, an error lock (like a hard lock) locks everything but may still be unlocked (like a write lock), after the file system has been made consistent. Utilizing the system and method of the present invention, should a particular file system encounter an error, only those specific dependent users who are using that file system service will be impacted, thereby greatly increasing overall system availability to independent users.

The file system fix-on-panic system and method of the present invention is of especial utility as an enhancement to the UNIX file system ("UFS") and serves to increase total computer system availability by detecting file system errors, determining whether on-line repair is possible and then locking, repairing and unlocking the failed file system. The system and method herein disclosed may also be advantageously implemented on any operating system incorporating a VFS layer or its equivalent, any System V-based UNIX system, IBM's AIX or MicroSoft's NT operating system.

The system and method of the present invention has been devised as an adjunct to existing lock mechanisms to provide an approach to on-line file system checking which is implemented on a monolithic kernel and may be run on multiple processors. It allows for file system fixing while in use, may be called out from the user level and also allows for modifications to be made to the UFS lock file system ("lockfs") layer to block only particular threads while being non-intrusive with respect to general file system data structures and algorithms.

In a particular implementation of a method for selectably error locking a failed file system of a computer operating system as disclosed herein, the method comprises the steps of providing for detecting an error in a failed file system of the computer operating system and determining if on-line repair of the failed file system is possible. The method further comprises the steps of providing for locking the failed file system if on-line repair is possible, effectuating the on-line repair of the failed file system and unlocking the failed file system. In a more specific implementation, the step of providing for detecting is carried out by the steps of providing for noting an inconsistency in the failed file system, creating a failure record corresponding to the failed file system inconsistency and placing the failure record on an operating system lock thread.

Also disclosed is a computer including a computer operating system loadable thereon for running application programs, with the operating system having a plurality of file systems incorporated therein accessable from the application programs. The operating system comprises a failed thread for indicating an error in a failed one of the plurality of file systems and a lock thread started in response to the failed thread. An error lock is responsive to the lock thread for selectably locking the failed file system if on-line repair thereof is possible. A block is responsive to the error lock for inhibiting pther threads from accessing the failed one of the plurality of file systems while on-line repair thereof is being effectuated whereby the block is then removed in response to completion of the on-line repair of the failed file system.

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 conceptual illustration of the pertinent UNIX operating system layers underlying a software application running on a computer system made up of one or more of the computers of Fig. 1 and illustrating with particularity the "User", "Kernel" and "UFS" layers with the VFS interface between the latter two on which various operations (e.g. Op1-Op3) may be run;
  • Fig. 3 is a simplified conceptual representation of how internal data structures change during normal operations preceding a UFS failure;
  • Fig. 4 is a follow-on, simplified conceptual representation of a UFS failure having been recognized and resulting in the blocking of other UFS threads at the VFS layer;
  • Fig. 5 is a further follow-on, simplified conceptual representation of the system and method of the file system fix-on-panic wherein the system may be unmounted or left in a locked condition and the lock thread proceeds to initiate repair to run the file system's checker;
  • Fig. 6 is an additional follow-on, simplified conceptual representation of the layers illustrated in the preceding figures wherein file system check ("fsck") completes the repair and the other threads are allowed to continue operations; and
  • Fig. 7 is a representative state diagram illustrating possible transitions between states in the event of a UFS failure in accordance with a particular implementation of the system and method for file system fix-on-panic herein disclosed.

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, a simplified conceptual illustration of the pertinent UNIX operating system layers 20 underlying an application program running on a computer system comprising a network of one or more of the computers depicted in Fig. 1 is shown. Particularity illustrated are the "User" (or system call) layer 22, the "Kernel" 24 and the "UFS" layer 26. Within the kernel 24, there exists the UFS module 28 and, in some instances, a network file system ("NFS") module 30. The UFS module 28 may include, for example, file naming, storage allocation and other services. As shown, a number of operations (Op1, Op2, Op3 and the like) may occur on the UFS module 28 and NFS module 30 at the VFS layer 32. The VFS layer 32 (also known as the VFSop or Vnode layer) is the interface between the kernel 24 and UFS layer 26 on which various operations may be run.

With reference now to Fig. 3, the system layers 20, comprising the user layer 22, kernel. 24 and UFS layer 26, are shown, including the VFS layer 32, as previously depicted in Fig. 2. In addition, a storage device 40 is shown along with a number of UFS threads 38. The UFS threads 38 may be conveniently thought of as a running program or independent "things" which can execute program code. (This is in contrast to a "process" which is an independent thing which can have multiple threads).

In normal operation as depicted, the UFS threads 38 pass from the user layer 22, kernel 24 and through the VFS layer 32 to the UFS layer 26 in response to the running of an application program which requests a particular file system operation.

With reference additionally now to Fig. 4, the system layers 20 and storage device 40 of the preceding figure are shown upon the occurrence of a file system failure. In this connection, the following definitions shall pertain:

("Authoritative System Reference" or "ASR") is a fictitious entity which produces a correct behavior of the system.

("Error") is a difference between the actual system behavior and that produced by an ASR.

("Fault") is a source which has the potential of generating errors.

("Failure") is a manifestation of a fault.

("UFS Failure") is an instance of UFS deviating from its specified behavior. In certain implementations, UFS failures may be either "synchronous failures" (those for which the program code explicitly checks), or "asynchronous failures" (those which are handled by the trap handling mechanism). The problems presented by the latter type of UFS failure are not applicable to the system and method disclosed herein.

Within a particular implementation of the Solaris® operating system developed and licensed by Sun Microsystems, Inc.,

   two types of synchronous failures may be encountered:

("Assertions" or "Asserts") are conditional expressions which are only checked in pre-production software. When true, the system is forcibly shutdown.

("Panics") are conditional expressions which are always checked. They are "permanent assertions" and the word "panic" is often used as a noun to mean "a forced system shutdown" and as a verb to mean "to force the system to shutdown".

("Failing Thread") is the thread in whose context the UFS failure manifests. Dependent (and independent) threads may be defined as threads which do (or do not) depend upon the resources of the failing file system, respectively.

("Availability") is the expected fraction of time that the system is able to provide service within acceptable response times. It is used to describe systems in which service may be delayed or denied for short periods without serious consequences. Quantitatively it can be defined as follows: Availability = Mean Time To Fail / (Mean Time To Fail + Mean Time To Repair)    or alternatively: Availability = 1 / ((1+Mean Time To Repair / (Mean Time To Fail)))

The system and method of the present invention assumes a division of users of a system into those who are not dependent and those who are dependent upon a failed file system and reduces the granularity of availability from that of the whole system to that of a file system service. System Call Failure Semantics: local and remote threads thread system call failure semantic local+remote: failing, dependent returns error (ERESTART) local: dependent block until unlock or unmount remote: dependent returns error (EWOULDBLOCK) local+remote: independent no failure; no delay

In a conventional UFS implementation, a great deal of state is maintained in-core. However, not all of this state is managed by UFS itself. A UFS failure indicates that at least some of this in-core state is untrustworthy. To recover from this, the following actions are necessary:

  • (1) The failed file system must be quiesced;
  • (2) Bad in-core state must be discarded;
  • (3) The on-disk state must be verified to be consistent, at least, and (probably) repaired;
  • (4) In-core state must be re-initialized from consistent values; and
  • (5) Operations that were "frozen" at file system quiesce must be allowed to proceed.

In the UNIX operating system in particular, this problem is addressed by the panic() mechanism and all in-core state is discarded. Repair and reinitialization happen at reboot time. Network file system operations, by the nature of the protocol, are frozen until the necessary daemons are restarted. Local operations, having been discarded, are lost. Lockfs performs all of the above functions, except for repair, which is done by fsck. UFS failures can be encountered at many different logical levels within UFS. As such, there is no guarantee as to what resources or resource locks are held at the time of the failure. This is true for UFS resources and locks as well as other subsystems on which UFS depends, such as VM. The traditional panic() routine addresses this problem by explicit code in the lock granting algorithm. When panicking, lock requests are always granted; other non-panicking threads are prevented from running.

Lockfs is invoked from an ioctl() system call. It, therefore, behaves much more hierarchically with respect to resources and locks. However, putting special-case code into UFS lockfs and all of the other routines possible to be invoked by it would require the introduction of additional mechanisms and intrude upon general UFS data structures and algorithms.

The UFS implementation contains redundant information within the allocation bitmaps and summary structures. An effect of this is that failures tend to occur much later in time than when the actual error occured. Consequently, there is a many-to-one relationship between an error and a failure condition ("the panic string"). Therefore, the proposed mechanism discards all structures detected as bad and re-initializes them to consistent values. As a consequence, it is always as good as the current panic-and-reboot mechanism in addressing the failure.

It would not be appropriate to attempt repair when the effects of the failure are too severe or when the error itself is able to be solved. These effects may be expressed as either the MTTF or MTTR is unacceptably high. Stated another way, the failure is occurring too often or failure causes too much damage, respectively. This is controllable by a set of new tunable variables. If the error is reproducible, then it is correct to fix the bug, rather than to use the file system fix-on-panic of the present invention to mask the error. The utility of the system and method herein disclosed is to address those errors that happen intermittently and are not yet reproducible.

In the general case, attempts to repair a UFS file system should be made. However, some specific UFS file systems have additional constraints imposed upon them. The root ("/") and user ("/usr") file systems are necessary to invoke fsck. As a consequence, locking them would cause a deadlock condition. UFS file systems on which active kernel accounting files reside or to which swapping may occur may also create similar deadlock conditions. Therefore, on these specific file systems, a panic is invoked.

Inodes whose generation number has changed are recognized by lockfs reconciliation algorithms. The old inode is modified to make it appear to reference a file on a file system that has been forcibly unmounted. No new inode modes or algorithms are necessary. If the quota inode (the inode associated with the file system's quota file) is removed, quota enforcement is disabled on this file system (in a manner similar to closedq()) and a warning message is logged. Note that this will never be the case for a "fsck -p" and manual repair is necessary in order to cause an inode to be removed. Files which have been unlinked but are still being referenced are detectable and will not be removed. Fsck's output will be captured by the logger command and sent to the syslog file.

As shown in the representative example of Fig. 4, in the event of a file system failure, a failed thread 42 will pass through the user layer 22, kernel 24 and into the UFS layer 26. Upon detection of the failed thread 42, a UFS failure record is created as indicated at reference numeral 44 and placed on the lock thread 46 work queue. The lock thread 46 is started when a failure occurs and it functions, as will be described hereinafter, to mark the blocks on the storage device 40 which are to be threreafter inaccessible and to cause that file system to become locked.

As indicated at reference numeral 48, the failed thread 42 then returns with an error. In response, the failed file system's superblock's fs_clean flag is marked as bad at reference numeral 50 at the storage device 40 and an error lock 36 is placed on the offending file system as indicated by reference number 52. The error lock 36 serves to block other UFS threads 54 at the VFS layer 32 as indicated. At reference numeral 56, the UFS failure transitions to the state "LOCKED" when lockfs returns.

When a file system inconsistency is detected, the previously described process is invoked. However, the inconsistency may not have happened at that instant and not enough information is available at that point to indicate when it occurred, thus necessitating an application checker. With respect to lockfs, all of the kernel 24 state (or "bookkeeping" related to storage blocks and file names for example) for a given file system is discarded except for a stub. The process of "unlocking" triggers a lock disk function called reconciliation and that retrieves the current state from the storage device 40 and, in fact, it only retrieves the current state from the storage device 40 for all the stubs that were left behind that were for things that were previously in use. Therefore, if a file changed, the state of the file on the storage device 40 would be assumed to be accurate. If the file was somehow removed, an error would be detected later but it will just be an application error and the file could simply be rewritten. The reconciliation enabled by lockfs allows this checking.

In this context, Fig. 4 conceptually illustrates internal data structure, however the process that actually identifies that there is problem provides an error code ("erestart") at reference numeral 48. This error code means that, in some cases applications, a check will be made for that specific error code and the same operation attempted again transparently to the user. Nevertheless, not all operations can be redone. For example, in attempting to create a file, in some cases it would be very hard to create a file depending upon how the file system has been damaged.

With reference additionally now to Fig. 5 the system layers 20 of Fig. 4 are shown in conjunction with the lock thread 46 and an RPC is created as indicated by reference numeral 58 to start the repair process. At reference numeral 60, inetd is notified of the RPC creation and a UFS daemon is started as shown at reference numeral 62. In response, a fsck process is started at reference numeral 64. In the mean time, inetd has returned as indicated at reference numeral 66 since the RPC was asynchronous. At reference numeral 68, fsck marks the superblock on the storage device 40 as fixed and the UFS failure record transitions to the state "FIXING" at reference numeral 70

As previously described, the lock thread 46 initiates the repair process. It calls out of the kernel 24 and makes the file system consistency checker run and then checks to make sure that it actually starts. In other words, if a file system is error locked, there are certain keys left behind on the storage device 40 as has been previously described for lockfs. It is part of the job of the lock thread 46 to never let the computer deadlock. So, if nothing has transpired within a predetermined period of time, the computer is shut down because that will cause errors to occur and be recognized such that a system administrator can give it attention rather than just appearing to be a delay in service. By calling out the consistency checker, the system goes ahead and repairs the file system.

With reference additionally now to Fig. 6, at reference numeral 72, fsck completes the file system repair, marking the file system as "clean" on the storage device 40. Fsck then also issues an "unlock" to the lockfs ioctl at reference numeral 74. In response, the lockfs sub-module calls into a fix-on-panic routine to mark the UFS failure record as "FIXED" at reference numeral 76. Lockfs returns at reference numeral 78 and other threads 80 are allowed to continue into the UFS layer 26 by removal of the error lock 36 (Fig. 4).

With reference now to Fig. 7, a state diagram illustrating possible transitions 100 between states in the event of a UFS failure in accordance with a particular implementation of the system and method of the present invention as previously described with respect to Figs. 3-6 is shown.

At event 102, a UFS failure has been detected. Struct ufs_failure (or typedef uf _t) records are associated with each UFS failure. When a file system has failed, there is a pointer from the ufsvfsp to the current struct ufs_failure. These are put on a queue described by a struct ufs_queue and used by a UFS thread. This thread will only exist while there is a non-terminal ufs_failure on the queue. There is a one-to-one correspondence between a UFS thread and its associated queue. Each failure has an associated state.

Terminal state 104, ("PANIC") implies that either the file system was not allowed to be repaired, unable to be locked or UFS Fix-On-Panic algorithms encountered an internal error. It is a terminal state, for the whole system.

State 106 ("UNDEF") means that these records are freshly allocated and have not yet been initialized. Their existence implies that a failure has occurred. These are allocated in the context of the failing thread.

State 108 ("INIT") means that these records have been initialized. Their existence implies that this file system is allowed to be locked and may be fixable. These are initialized in the context of the failing thread. The following UFS control structures and pointers are copied into the struct ufs_failure

State 110 ("QUEUE") means these records have been put onto the work queue for the lock thread. In some cases, due to lock contention, records will be put on the work queue but unable to be marked in this state. In this case, the lock thread will update the failure record's state. Usually, this state transition will occur in the context of the failing thread.

Terminal state 112 ("REPLICA") implies that a UFS failure has occurred on a file system which has already failed. The lock thread is responsible for moving a record from the QUEUE state 110 into this state, since manipulation of the ufsvfs is required. Once recorded, these records are ignored, as repair is already initiated and associated with the original ufs_failure.

State 114 ("TRY LOCK") means that records have been found by the lock thread and updated with the information necessary to invoke the internal lockfs entry point, ufs_fiolfs(). The ufsvfs of the failed file system is updated at this point to indicate that a failure has occurred on this file system. This is used to detect replicated UFS failures.

State 116 ("UMOUNT") implies that the file system was marked to be unmounted rather than repaired. No actions are taken once a failure record achieves this (or any other) terminal state.

Terminal state 118 ("NOT FIX") implies that this file system was marked not to be repaired or was forcibly unmounted, preventing the fix from occuring automatically.

State 120 ("LOCKED") implies that the failed file system has been succesfully locked. An RPC call is made to a port to initiate repair. The RPC call returns when fsck is succesfully started.

State 122 ("FIXING") implies that fsck has updated the superblock indicating that repair is in progress.

Terminal state 124 ("FIXED") implies that this file system has been successfully repaired and unlocked.

The following are the necessary conditions for the state transitions 100 between certain of the states above described:

From event 102 to terminal state 104 ("PANIC") : a non-UFS panic is already in progress; the file system is not identifiable (vp, ufsvfsp, vfsp are NULL); the fix-on-panic feature has been disabled on this file system; there is an active swap file contained in this file system; and there is an active kernel accounting file contained in this file system.

From state 106 ("UNDEF") to terminal state 104 ("PANIC"): the file system's control structures (ufsvfsp, vfsp, bp containing struct fs) became invalid.

From state 108 ("INIT") to state 110 ("QUEUE"): this struct ufs_failure has been put on the lock thread's work queue.

From state 110 ("QUEUE") to terminal state ("REPLICA"): this is another active UFS failure associated with this file system.

From state 110 ("QUEUE") to state 114 ("TRY LOCK"): file system control structures haven't changed since the failure was recognized.

From state 110 ("QUEUE") to terminal state 104 ("PANIC"): the per-system limit on number of UFS failures has been exceeded; and the per-system limit of minimum time between UFS failures has been exceeded.

From states 110 ("QUEUE")/ 114 ("TRY LOCK") 120 ("LOCKED") and 122 ("FIXING") to terminal state 118 ("NOT FIX"): this file system has been unmounted by some other thread.

From state 114 ("TRY LOCK") to terminal state 104 ("PANIC"): the timeout has been exceeded while trying to error lock the file system; lockfs failed on this file system with the error EDEADLK; there have been too many failures on this file system since boot; and this failure has occurred too soon since the last failure on this file system.

From state 114 ("TRY LOCK") to state 116 ("UMOUNT"): this file system is marked to be unmounted on failure.

From state 116 ("UMOUNT") to terminal state ("NOT FIX"): the unmount of the file system succeeded.

From state 114 ("TRY LOCK") to state 120 ("LOCKED"): the error lock of the file system succeeded; and the error lock of the file system failed, thereby indicating that it is already error-locked.

From state 120 ("LOCKED") to terminal state 104 ("PANIC"): fsck does not or cannot be started.

From state 120 ("LOCKED") to state 122 ("FIXING"): the file system's superblock's fs_clean field has been reset to FSFIX by fsck.

From state 122 ("FIXING") to state 120 ("LOCKED"): the file system's superblock's fs_clean field has been reset to FSBAD by fsck; and the repair daemon detected an error in the execution of fsck.

From state 122 ("FIXING") to terminal state 124 ("FIXED") : the error lock on the file system has been unlocked. (This requires fs_clean == FSCLEAN).

Utilizing the system and method of the present invention herein disclosed, availability of the whole system is increased since the Mean Time To Failure (MTTF) for independent threads is increased by the amount of time up to the next failure. In addition, the MTTF and the Mean Time To Repair (MTTR) for those dependent threads is reduced to just the amount of time necessary for the repair rather than for any system overhead (such as a panic dump, hardware reset, reboot or failover to another node.)

While there have been described above the principles of the present invention in conjunction with specific computer operating systems the foregoing description is made only by way of example and not as a limitation to the scope of the invention.


Anspruch[de]
  1. Verfahren zur auwählbaren Fehlerverriegelung eines fehlerhaften Dateisystems eines Computer-Betriebssystems, in das eines oder eine Vielzahl von Dateisystemen integriert sind, auf die über Anwendungsprogramme zugegriffen werden kann, wobei das Verfahren die folgenden Schritte aufweist:
    • Detektieren eines Fehlers in einem fehlerhaften Dateisystem des Computer-Betriebssystems;
    • Ermitteln, ob eine Online-Reparatur des fehlerhaften Dateisystems möglich ist;
    • Verriegeln des fehlerhaften Dateisystems, falls eine Online-Reparatur möglich ist;
    • Ausführen der Online-Reparatur des fehlerhaften Dateisystems; und
    • Entriegeln des fehlerhaften Dateisystems.
  2. Verfahren nach Anspruch 1, bei dem der Schritt des Detektierens durch folgende Schritte ausgeführt wird:
    • Feststellen einer Inkonsistenz in dem fehlerhaften Dateisystem;
    • Erzeugen einer Fehleraufzeichnung entsprechend der Inkonsistenz des fehlerhaften Dateisystems; und
    • Plazieren der Fehleraufzeichnung auf einem Betriebssystem-Verriegelungs-Prozeßstrang (-Thread) (46).
  3. Verfahren nach Anspruch 2, bei dem die Inkonsistenz in Reaktion auf einen fehlerhaften Prozeßstrang (42) des Betriebssystems festgestellt wird.
  4. Verfahren nach Anspruch 1, bei dem der Schritt des Verriegelns weiterhin folgenden Schritt aufweist:
    • Markieren von mit dem fehlerhaften Dateisystem in Bezug stehenden Datenblöcken auf einer zugeordneten Computer-Massenspeichervorrichtung als nicht zugreifbar.
  5. Verfahren nach Anspruch 1, bei dem das Betriebssystem in Reaktion auf den Schritt des Feststellens abgeschaltet wird, wenn eine Online-Reparatur des fehlerhaften Dateisystems nicht möglich ist.
  6. Verfahren nach Anspruch 1, das weiterhin folgenden Schritt aufweist:
    • Ermöglichen, daß andere Prozeßstränge, die anderen Betriebssystem-Dateisystemen entsprechen, fortfahren, während das fehlerhafte Dateissystem verriegelt ist.
  7. Computer (1) mit einem hierauf ladbaren Computer-Betriebssystem zum Ausführen von Anwendungsprogrammen, wobei das Betriebssystem eines oder eine Vielzahl von in dieses integrierte Dateisysteme aufweist, auf die über die Anwendungsprogramme zugegriffen werden kann, und das so ausgelegt ist, daß es ein fehlerhaftes Dateisystem des Betriebssystems auswählbar fehlerverriegeln kann, wobei das Betriebssystem folgendes aufweist:
    • eine Einrichtung zum Detektieren eines Fehlers in einem fehlerhaften Dateisystem des Computer-Betriebssystems;
    • eine Einrichtung zum Ermitteln, ob eine Online-Reparatur des fehlerhaften Dateisystems möglich ist;
    • eine Einrichtung zum Verriegeln des fehlerhaften Dateisystems, wenn eine Online-Reparatur möglich ist;
    • eine Einrichtung zum Durchführen der Online-Reparatur des fehlerhaften Dateisystems; und
    • eine Einrichtung zum Entriegeln des fehlerhaften Dateisystems.
  8. Computer nach Anspruch 7, bei dem die Detektierungseinrichtung folgendes aufweist:
    • eine Einrichtung zum Feststellen einer Inkonsistenz in dem fehlerhaften Dateisystem;
    • eine Einrichtung zum Erzeugen einer Fehleraufzeichnung entsprechend der Inkonsistenz des fehlerhaften Dateisystems; und
    • eine Einrichtung zum Plazieren der Fehleraufzeichnung auf einem Betriebssystem-Verriegelungs-Prozeßstrang (46).
  9. Computer nach Anspruch 8, bei dem die Einrichtung zum Feststellen einer Inkonsistenz in Reaktion auf einen fehlerhaften Prozeßstrang (42) des Betriebssystems aktiv wird.
  10. Computer nach Anspruch 7, bei dem die Einrichtung zum Verriegeln weiterhin folgendes aufweist:
    • eine Einrichtung zum Markieren von mit dem fehlerhaften Dateisystem in Bezug stehenden Datenblöcken auf einer zugehörigen Computer-Massenspeichervorrichtung als nicht zugreifbar.
  11. Computer nach Anspruch 7, der eine Einrichtung aufweist, um das Betriebssystem in Reaktion auf die Ermittlungseinrichtung abzuschalten, wenn festgestellt wird, daß eine Online-Reparatur des fehlerhaften Dateisystems nicht möglich ist.
  12. Computer nach Anspruch 7, der weiterhin folgendes aufweist:
    • eine Einrichtung zum Ermöglichen, daß andere Prozeßstränge, die anderen Betriebssystem-Dateisystemen entsprechen, fortfahren können, während das fehlerhafte Dateisystem verriegelt ist.
  13. Computer nach Anspruch 7, bei dem das Betriebssystem folgendes aufweist:
    • einen fehlerhaften Prozeßstrang (42) zum Anzeigen eines Fehlers in einem fehlerhaften Dateisystem aus der Vielzahl von Dateisystemen;
    • einen Verriegelungs-Prozeßstrang (46), der in Reaktion auf den fehlerhaften Prozeßstrang gestartet wird;
    • eine Fehlerverriegelungseinrichtung (36), die auf den Verriegelungs-Prozeßstrang anspricht, zum auswählbaren Verriegeln des fehlerhaften Dateisystems, wenn dessen Online-Reparatur möglich ist;
    • einen Block, der auf die Fehlerverriegelung anspricht, um andere Prozeßstränge daran zu hindern, auf das fehlerhafte Dateisystem aus der Vielzahl von Dateisystemen zuzugreifen, während dessen Online-Reparatur durchgeführt wird;
    • wobei der Block in Reaktion auf die Durchführung der Online-Reparatur des fehlerhaften Dateisystems enffernt wird.
  14. Computer nach Anspruch 13, bei dem das Betriebssystem folgendes aufweist:
    • eine Benutzerschicht (22), um eine Schnittstelle vom Betriebssystem zu den Anwendungsprogrammen zu bilden;
    • eine Kernel-Schicht (24), die unterhalb der Benutzerschicht liegt; und
    • eine Dateisystemschicht (26), die unterhalb der Kernel-Schicht liegt und ein Dateisystem-Interface (32) dazwischen definiert.
  15. Computer nach Anspruch 13, bei dem der Block am Dateisystem-Interface (32) implementiert ist.
  16. Computer nach Anspruch 14, bei dem die Dateisystemschicht (32) eine UNIX-Dateisystem-(UFS-)Schicht umfaßt.
  17. Computer nach Anspruch 14, bei dem das Dateisystem-Interface (32) eine UNIX-System-V-Dateisystem-(VFS)-Schicht umfaßt.
  18. Computer nach Anspruch 13, der weiterhin aufweist:
    • eine Computer-Massenspeichervorrichtung (40), die mit dem Computer verbunden ist, um Datenblöcke zu speichern, die mit der Vielzahl von Dateisystemen in Bezug stehen.
  19. Computer nach Anspruch 18, bei dem ausgewählte Datenblöcke in der Computer-Massenspeichervorrichtung (40), die mit dem fehlerhaften Dateisystem in Bezug stehen, in Reaktion auf den Verriegelungs-Prozeßstrang (46) als nicht zugreifbar markiert werden.
Anspruch[en]
  1. A method for selectably error locking a failed file system of a computer operating system having one or a plurality of file systems incorporated therein and accessible from application programs, comprising the steps of:
    • detecting an error in a failed file system of said computer operating system;
    • determining if on-line repair of said failed file system is possible;
    • locking said failed file system if said on-line repair is possible;
    • effectuating said on-line repair of said failed file system; and
    • unlocking said failed file system.
  2. The method of claim 1, wherein said step of detecting is carried out by the steps of:
    • noting an inconsistency in said failed file system;
    • creating a failure record corresponding to said failed file system inconsistency; and
    • placing said failure record on an operating system lock thread (46).
  3. The method of claim 2, wherein said inconsistency is noted in response to an operating system failed thread (42).
  4. The method of claim 1, wherein said step of locking further comprises the step of:
    • marking blocks of data associated with said failed file system as inaccessable on an associated computer mass storage device.
  5. The method of claim 1, wherein said operating system is shut down in response to said step of determining if said on-line repair of said failed file system is not possible.
  6. The method of claim 1, further comprising the step of:
    • allowing other threads corresponding to other operating system file systems to continue while said failed file system is locked.
  7. A computer (1) including a computer operating system loadable thereon for running application programs, said operating system having one or a plurality of file systems incorporated therein accessable from said application programs and being adapted to selectably error lock a failed file system of said operating system, said operating system comprising:
    • means for detecting an error in a failed file system of said computer operating system;
    • means for determining if on-line repair of said failed file system is possible;
    • means for locking said failed file system if said on-line repair is possible;
    • means for effectuating said on-line repair of said failed file system; and
    • means for unlocking said failed file system.
  8. The computer of claim 7, wherein said detecting means comprises
    • means for noting an inconsistency in said failed file system;
    • means for creating a failure record corresponding to said failed file system inconsistency; and
    • means for placing said failure record on an operating system lock thread (46).
  9. The computer of claim 8, wherein said means for noting an inconsistency becomes active in response to an operating system failed thread (42).
  10. The computer of claim 7, wherein said means for locking further comprises:
    • means for marking blocks of data associated with said failed file system as inaccessable on an associated computer mass storage device.
  11. The computer of claim 7, comprising means to shut down said operating system in response to said determining means, if it is determined that on-line repair of said failed file system is not possible.
  12. The computer of claim 7, further comprising:
    • means for allowing other threads corresponding to other operating system file systems to continue while said failed file system is locked.
  13. The computer of claim 7, wherein said operating system comprises:
    • a failed thread (42) for indicating an error in a failed one of said plurality of file systems;
    • a lock thread (46) started in response to said failed thread;
    • an error lock (36) responsive to said lock thread for selectably locking said failed file system if on-line repair thereof is possible;
    • a block responsive to said error lock for inhibiting other threads from accessing said failed one of said plurality of file systems while on-line repair thereof is being effectuated,
    • whereby said block is removed in response to effectuation of said on-line repair of said failed file system.
  14. The computer of claim 13, wherein said operating system comprises:
    • a user layer (22) for interfacing said operating system to said application programs;
    • a kernel layer (24) underlying said user layer; and
    • a file system layer (26) underlying said kernel layer and defining a file system interface (32) therebetween.
  15. The computer of claim 13, wherein said block is implemented at said file system interface (32).
  16. The computer of claim 14, wherein said file system layer (26) comprises a UNIX file system (UFS) layer.
  17. The computer of claim 14, wherein said file system interface (32) comprises a UNIX System V File System (VFS) layer.
  18. The computer of claim 13, further comprising:
    • a computer mass storage device (40) associated with said computer for storing blocks of data associated with said plurality of file systems.
  19. The computer of claim 18, wherein selected blocks of data on said computer mass storage device (40) associated with said failed file system are marked as inaccessable in response to said lock thread (46).
Anspruch[fr]
  1. Procédé de verrouillage sélectif en erreur d'un système de fichiers défaillant d'un système d'exploitation d'ordinateur, dans lequel un ou une pluralité de systèmes de fichiers est incorporé et est accessible à partir de programmes d'application, comprenant les étapes de:
    • détection d'une erreur dans un système de fichiers défaillant dudit système d'exploitation d'ordinateur;
    • détermination de ce que la réparation en fonctionnement dudit système de fichiers défaillant est possible;
    • verrouillage dudit système de fichiers si ladite réparation en fonctionnement est possible;
    • réalisation de ladite réparation en fonctionnement dudit système de fichiers défaillant; et
    • déverrouillage dudit système de fichiers défaillant.
  2. Procédé selon la revendication 1, dans lequel ladite étape de détection est réalisée par les étapes de:
    • repérage d'une incohérence dans ledit système de fichiers défaillant;
    • création d'un enregistrement de défaillance correspondant à ladite incohérence de système de fichiers défaillant; et
    • mise en place dudit enregistrement de défaillance sur une tâche élémentaire de verrouillage de système d'exploitation (46).
  3. Procédé selon la revendication 2, dans lequel l'incohérence est repérée en réponse à une tâche élémentaire de défaillance de système d'exploitation (42).
  4. Procédé selon la revendication 1, dans lequel ladite étape de verrouillage comprend, en outre, l'étape de:
    • marquage de blocs de données associés audit système de fichiers défaillant comme inaccessibles sur un dispositif de mémorisation de masse d'ordinateur associé.
  5. Procédé selon la revendication 1, dans lequel ledit système d'exploitation est arrêté en réponse à ladite étape de détermination, si ladite réparation en fonctionnement dudit système de fichiers défaillant n'est pas possible.
  6. Procédé selon la revendication 1, comprenant, en outre, l'étape de:
    • autorisation de poursuite des autres tâches élémentaires correspondant à d'autres systèmes de fichier de système d'exploitation lorsque ledit système de fichiers défaillant est bloqué.
  7. Ordinateur (1) sur lequel un système d'exploitation d'ordinateur peut être chargé afin d'exécuter des programmes d'application, ledit système d'exploitation comprenant un ou une pluralité de systèmes de fichiers intégrés, accessibles à partir desdits programmes d'application, et étant adapté pour verrouiller en erreur de manière sélective un système de fichiers défaillant dudit système d'exploitation, ledit système d'exploitation comprenant:
    • un moyen destiné à détecter une erreur dans un système de fichiers défaillant dudit système d'exploitation d'ordinateur;
    • un moyen destiné à déterminer si une réparation en fonctionnement dudit système de fichiers défaillant est possible;
    • un moyen destiné à verrouiller ledit système de fichiers défaillant si ladite réparation en fonctionnement est possible;
    • un moyen destiné à réaliser ladite réparation en fonctionnement dudit système de fichiers défaillant; et
    • un moyen destiné à déverrouiller ledit système de fichiers défaillant.
  8. Ordinateur selon la revendication 7, dans lequel ledit moyen de détection comprend
    • un moyen destiné à repérer une incohérence dans ledit système de fichiers défaillant;
    • un moyen destiné à créer un enregistrement de défaillance correspondant à ladite incohérence de système de fichiers défaillant; et
    • un moyen destiné à placer ledit enregistrement de défaillance sur une tâche élémentaire de verrouillage de système d'exploitation (46).
  9. Ordinateur selon la revendication 8, dans lequel ledit moyen destiné à repérer une incohérence devient actif en réponse à une tâche élémentaire de défaillance de système d'exploitation (42).
  10. Ordinateur selon la revendication 7, dans lequel ledit moyen de verrouillage comprend, en outre:
    • un moyen destiné à marquer des blocs de données associés audit système de fichiers défaillant comme inaccessibles sur un dispositif de mémorisation de masse d'ordinateur associé.
  11. Ordinateur selon la revendication 7, comprenant un moyen destiné à arrêter ledit système d'exploitation en réponse audit moyen de détermination, s'il est déterminé qu'une réparation en fonctionnement dudit système de fichiers défaillant n'est pas possible.
  12. Ordinateur selon la revendication 7, comprenant, en outre: un moyen destiné à autoriser la poursuite d'autres tâches élémentaires correspondant à d'autres systèmes de fichiers de système d'exploitation pendant que ledit système de fichiers défaillant est verrouillé.
  13. Ordinateur selon la revendication 7, dans lequel ledit système d'exploitation comprend:
    • une tâche de défaillance (42) destinée à indiquer une erreur dans un système de fichiers défaillant de ladite pluralité de systèmes de fichiers;
    • une tâche de verrouillage (46) démarrée en réponse à ladite tâche de défaillance;
    • un verrou d'erreur (36) réagissant à ladite tâche de verrouillage pour verrouiller de manière sélective ledit système de fichiers défaillant si une réparation en fonctionnement est possible;
    • un bloc réagissant audit verrou d'erreur afin d'interdire l'accès par d'autres tâches audit système de fichiers défaillant de ladite pluralité de systèmes de fichiers pendant que la réparation en fonctionnement de celui-ci est réalisée;
    • après quoi ledit bloc est éliminé en réponse à la réalisation de ladite réparation en fonctionnement dudit système de fichiers défaillant.
  14. Ordinateur selon la revendication 13, dans lequel ledit système d'exploitation comprend:
    • une couche d'utilisateur (22) destinée à réaliser l'interface entre ledit système d'exploitation et lesdits programmes d'application;
    • une couche de noyau (24) au-dessous de ladite couche d'utilisateur; et
    • une couche de système de fichiers (26) au-dessous de ladite couche de noyau et définissant une interface de système de fichiers (32) entre elles.
  15. Ordinateur selon la revendication 13, dans lequel ledit bloc est mis en oeuvre sur ladite interface de système de fichiers (32).
  16. Ordinateur selon la revendication 14, dans lequel ladite couche de système de fichiers (26) comprend une couche de système de fichiers UNIX (UFS).
  17. Ordinateur selon la revendication 14, dans lequel ladite interface de système de fichiers (32) comprend une couche de système de fichiers "UNIX Système V" (VFS).
  18. Ordinateur selon la revendication 13, comprenant en outre: un dispositif de mémorisation de masse d'ordinateur (40) associé avec ledit ordinateur afin de mémoriser des blocs de données associés avec ladite pluralité de systèmes de fichiers.
  19. Ordinateur selon la revendication 18, dans lequel lesdits blocs de données sélectionnés sur ledit dispositif de mémorisation de masse d'ordinateur (40) associés avec ledit système de fichiers défaillant sont marqués comme inaccessibles en réponse à ladite tâche de verrouillage (46).






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com