Netapp, Inc.

International Business Machines Corporation

Balamurugan Ramajeyam

Vaiapuri Ramasubramaniam

Akshatha Gangadharaiah

Raman Madaan

Subhash Sankuratripati

Aftab Ahmad Ansari

Aftab Ahman Ansari

Perinkulam I Ganesh

Khalid Filali-Adib

Suresh Eswara Warrier

David W Sheffield

Kavitha Ramalingam

Laurent Dufour

Muthulakshmi Pearl Srinivasan

Avinash Srikrishna Chinchalkar

Systems and methods are disclosed for implementing an event based retention schedule for a read only file. When a regular file is to be converted to an event based retention read only file, an 'event-retain' property may be enabled on the file allowing the feature to be implemented. Then, that file may have its permissions changed to read only. This will allow the file to be changed to a read only file without using a default retention time. Then, once the event is triggered, the retention time may be set so the file can be scheduled for automatic deletion.

Event based retention of read only files

One or more techniques and/or computing devices are provided for data object retention. For example, a data retention policy may specify that files of a volume are to be locked down for a lockdown retention period (e.g., locked into a read only state for 4 months) when such files are not changed within an auto commit time period (e.g., files not changed within 13 hours). Waiting for a data scanner to evaluate files for lockdown may result in files violating the data retention policy until the data scanner evaluates such files. Accordingly, a file may be considered to be in the locked down state (e.g., instantaneous lockdown), such that commands to modify or delete the file are blocked, based upon a difference between a current time of an internal compliance clock and a current value of a data object change field exceeding the auto commit time period.

Data object lockdown

One or more techniques and/or computing devices are provided for implementing resynchronization operations. For example, a disaster recovery relationship may be established between a source storage volume, hosted by a source storage node, and a destination storage volume hosted by a destination storage node, such that data is replicated from the source storage volume to the destination storage volume for disaster recovery purposes. If the disaster recovery relationship breaks, then new compliance data, locked down into a write once read many state, may be created at the destination storage volume. A resynchronization operation may be performed to reestablish the disaster recovery relationship, while preserving the new compliance data so that a compliance policy is not violated. For example, cloned storage volumes, copying compliance data to source storage volumes before resynchronization, and/or moving compliance data to local volumes may be used to implement resynchronization operations while preserving compliance data.

Resynchronization with compliance data preservation

When moving workload partitions (WPARs) from machine to machine, operating systems may encounter errors that prevent successful WPAR migration. Recording and reporting errors can be challenging. To move WPARs, the operating system may employ a plurality of software components, such as code residing in user space (e.g., application programs, OS libraries, and shell scripts), code residing in the operating system's kernel, and code residing on remote machines. Embodiments of the invention include a framework that enables all the software components to record errors. The framework can also report the errors to users and processes.

Error handling in a virtualized operating system

A computer implemented method, a computer program product, and a data processing system trace information about current context and system state for either 32-bit or 64-bit applications. A 32-bit trace executable code and a 64-bit trace executable code are compiled for a trace script. A determination is then made as to whether an application process is a 32-bit process or a 64-bit process. Responsive to determining that the application process is the 32-bit process or the 64-bit process, an internal indicator is set to indicate the application process as either a 32-bit process or a 64-bit process. Subsequently, the internal indicator is identified as either indicating the 32-bit process or the 64-bit process. If the internal identifier indicates the application process is a 32-bit process, an instruction pointer is set to indicate the 32-bit trace executable code, and the 32-bit trace executable code is executed. If the internal identifier indicates the application process is a 64-bit process, an instruction pointer is set to indicate the 64-bit trace executable code, and the 64-bit trace executable code is executed.

Selective execution of trace mechanisms for applications having different bit structures

Growing community of inventors

Chennai, India

Balamurugan Ramajeyam