International Business Machines Corporation

Willard A Davis

James C Davis

Felipe Knop

A computer-implemented method according to one embodiment includes receiving data associated with a driver performing actions. At least some of the actions trigger events emitted by an event emitter. Information, from the received data, about the performed actions is logged in an action log. An event observer is instructed to log the events emitted by the event emitter that the event observer observes. The observed events are logged in an event log. The information of the action log and information of the event log is compared based on a rule, and a validity of the event emitter is determined based on results of the comparing. A computer program product according to another embodiment includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a processor to cause the processor to perform the foregoing method.

Determining a validity of an event emitter based on a rule

A computer-implemented method according to one embodiment includes performing a first process for each chunk of data of each file of a snapshot of a file system. The first process includes reading a given chunk of data of a given file of a first snapshot of the file system, and reading shadow records of a shadow file of the first snapshot. The given chunk of data is compared with the shadow records for determining whether a coherent state exists between the given chunk of data and one or more of the shadow records that were recorded in a snapshot creation window. In response to determining that no coherent state exists, an indication is recorded that the given chunk of data is corrupt. In response to determining that a coherent state exist, an indication is recorded that the given chunk of data is accurate.

Verification of the integrity of data files stored in copy-on-write (CoW) based file system snapshots

A computer-implemented method according to one embodiment includes determining a location within a file system that is potentially vulnerable to hardware failures, and injecting one or more simulated hardware failures into the determined location within the file system. The method further includes determining whether the file system was damaged as a result of injecting the simulated hardware failure(s). In response to determining that the injection of the simulated hardware failure(s) resulted in damage to the file system, it is determined whether the damage is repairable. Based on whether the file system was damaged as a result of injecting the simulated hardware failure(s) and/or based on whether or not the damage is determined to be repairable, a tolerance-to-storage-failure score is assigned to the file system.

Injection of simulated hardware failure(s) in a file system for establishing file system tolerance-to-storage-failure(s)

Embodiments include techniques for metadata verification in a distributed file system, the technique including receiving an input for metadata, the metadata being associated with a file, and acquiring a function lock on a designated region of the file based at least in part on the metadata. The technique also includes hashing the input associated with the metadata into a designated region of the file, and updating the designated region corresponding to the input. The technique includes computing a checksum for the metadata associated with the designated region, updating a journal file based at least in part on the metadata, and releasing the function lock.

File metadata verification in a distributed file system

A lock manager configured for locking files is tested. As part of the test and based on a lock assignment plan, a process acquires locks on portions of the files. Based on a lock testing plan, a second process performs a lock verification for a portion of the locked portions. A result of this lock verification is compared to its expected result. Based on an updated lock assignment plan, the process transitions from the locks to other locks on other portions of the files. Based on an updated lock testing plan, the second process performs a second lock verification for a portion of the other locked portions. A result of this second lock verification is compared to its expected result. Based at least in part on the two comparisons, the lock manager is evaluated.

Testing of lock managers in computing environments

Aspects include testing distributed file systems by selecting a file in a multiple writer environment and selecting an offset of a block in the file. Test data is generated for the block by randomly selecting a starting value from a plurality of possible starting values. A test header that includes the starting value and a test data sequence that starts with the starting value is created. A file system that is being tested writes the test header and the test data sequence to the block. Contents of the block are read by the file system that is being tested, and expected contents of the data sequence are determined based on contents of the read header. The expected contents of the data sequence are compared to the read data sequence and an error indication is output based on the expected contents not being equal to the read contents.

Growing community of inventors

Rosendale, NY, United States of America

Willard A Davis