Netapp, Inc.

Akshatha Gangadharaiah

Balamurugan Ramajeyam

Vaiapuri Ramasubramaniam

Raman Madaan

Sisir Shekhar

Saravana Selvarai

Aftab Ahmad Ansari

Subhash Sankuratripati

Aftab Ahman Ansari

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

A client identifies a first data unit to be shared from a first file to a second file and sends an operation to copy that indicates the first data unit to be shared. The operation to copy the first data unit from the first file to the second file is received. In response to receiving the operation to copy the first data unit from the first file to the second file, it is determined whether the first data unit can be shared with the second file. In response to determining that the first data unit cannot be shared with the second file, the first data unit is copied to the second file. In response to determining that the first data unit can be shared with the second file, the first data unit is shared between the first file and the second file.

Deduplicating extents across systems

Deduplicating extents across systems based upon indications of shared extents provided by clients

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.

Growing community of inventors

Bengaluru, India

Akshatha Gangadharaiah