WO2005045556A2 - Systeme et procede d'enregistrement de date de fin de validite dans un systeme de stockage a disque inscriptible une seule fois - Google Patents

Systeme et procede d'enregistrement de date de fin de validite dans un systeme de stockage a disque inscriptible une seule fois Download PDF

Info

Publication number
WO2005045556A2
WO2005045556A2 PCT/US2004/012378 US2004012378W WO2005045556A2 WO 2005045556 A2 WO2005045556 A2 WO 2005045556A2 US 2004012378 W US2004012378 W US 2004012378W WO 2005045556 A2 WO2005045556 A2 WO 2005045556A2
Authority
WO
WIPO (PCT)
Prior art keywords
worm
file
set forth
storage system
data
Prior art date
Application number
PCT/US2004/012378
Other languages
English (en)
Other versions
WO2005045556A3 (fr
Inventor
William P. Mcgovern
Jeffrey L. Heller
Original Assignee
Network Appliance, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=34551412&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2005045556(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Network Appliance, Inc. filed Critical Network Appliance, Inc.
Priority to CN2004800395759A priority Critical patent/CN101443760B/zh
Priority to JP2006539450A priority patent/JP2007524954A/ja
Priority to EP20040818283 priority patent/EP1690166A4/fr
Priority to CA2544846A priority patent/CA2544846C/fr
Priority to AU2004288444A priority patent/AU2004288444B2/en
Publication of WO2005045556A2 publication Critical patent/WO2005045556A2/fr
Priority to IL175445A priority patent/IL175445A/en
Publication of WO2005045556A3 publication Critical patent/WO2005045556A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
    • G06F16/125—File system administration, e.g. details of archiving or snapshots using management policies characterised by the use of retention policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G06F16/181—Append-only file systems, e.g. using logs or journals to store data providing write once read many [WORM] semantics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G06F3/0623—Securing storage systems in relation to content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2216/00—Indexing scheme relating to additional aspects of information retrieval not explicitly covered by G06F16/00 and subgroups
    • G06F2216/09—Obsolescence
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99955—Archiving or backup

Definitions

  • This invention relates to data storage systems having write-once-read-many ca- pabilities for enhanced data integrity.
  • a file server is a computer that provides file service relating to the organization of information on storage devices, such as disks.
  • the file server ox filer includes a storage operating system that implements a file system to logically organize the informa- tion as a hierarchical structure of directories and files on the disks.
  • Each "on-disk" file may be implemented as a set of data structures, e.g., disk blocks, configured to store information.
  • a directory on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
  • a filer may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer.
  • the client may comprise an application, such as a database application, executing on a computer that "connects" to the filer over a direct connection or computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet.
  • Each client may request the services of the file system on the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
  • a common type of file system is a "write in-place" file system, an example of which is the conventional Berkeley fast file system.
  • file system it is meant generally a structuring of data and metadata on a storage device, such as disks, which permits reading/writing of data on those disks.
  • file system it is meant generally a structuring of data and metadata on a storage device, such as disks, which permits reading/writing of data on those disks.
  • An inode is a data structure used to store information, such as metadata, about a file, whereas the data blocks are structures used to store the actual data for the file.
  • the information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, file type and references to locations on disk of the data blocks for the file.
  • the references to the locations of the file data are provided by pointers in the inode, which may further reference indirect blocks that, in turn, reference the data blocks, depending upon the quantity of data in the file. Changes to the inodes and data blocks are made "in-place" in accordance with the write in-place file system. If an update to a file extends the quantity of data for the file, an additional data block is allocated and the appropriate inode is updated to reference that data block.
  • Another type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block on disk is retrieved (read) from disk into memory and "dirtied” with new data, the data block is stored (written) to a new location on disk to thereby optimize write performance.
  • a write-anywhere file system may initially as- sume an optimal layout such that the data is substantially contiguously arranged on disks.
  • the optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks.
  • a particular example of a write- anywhere file system that is configured to operate on a filer is the Write Anywhere File Layout (WAFLTM) file system available from Network Appliance, Inc. of Sunnyvale, California.
  • the WAFL file system is implemented within a microkernel as part of the overall protocol stack of the filer and associated disk storage. This microkernel is supplied as part of Network Appliance's Data ONTAPTM software, residing on the filer, that processes file-service requests from network-attached clients.
  • the term "storage operating system” generally refers to the computer-executable code operable on a computer that manages data access and may, in the case of a filer, implement file system semantics, such as the Data ONTAPTM storage operating system, implemented as a microkernel, and available from Network Appliance, Inc. of Sunnyvale, California, which implements a Write Anywhere File Layout (WAFLTM) file system.
  • the storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
  • Disk storage is typically implemented as one or more storage "volumes” that comprise physical storage disks, defining an overall logical arrangement of storage space.
  • volume can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof; volume and file system shall generally be used synonymously.
  • the disks within a volume are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID).
  • RALD implementations enhance the reliability/integrity of data storage through the redundant writing of data "stripes" across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data.
  • a RAID 4 implementation is advantageously employed.
  • This implementation specifically entails the striping of data across a group of disks, and separate parity caching within a selected disk of the RAID group.
  • a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity partitions in a single disk) arranged according to a RAID 4, or equivalent high-reliability, implementation.
  • Data storage is an increasingly crucial and central part of many industries dealing in financial transactions and other sensitive tasks, such as banks, government facili- ties/contractors, defense, health care institutions, pharmaceutical companies and securities brokerages. In many of these environments, it is necessary to store selected data in an immutable and unalterable manner.
  • SEC United States Securities and Exchange Commission
  • This rule requires that these entities store e-mails and other documents in connection with a variety of transactions and trades by clients of the entities unchanged and unchangeable for a number of years and to be able to provide these records to the SEC and other regulators on short notice. Failure to comply with these rules can lead to significant sanctions.
  • a variety of prior art approaches involving tape drives, electro-optical recordable media and the like have been employed over the years to implement a WORM storage system.
  • WORM storage employs conventional fault-tolerant (e.g. RAID- based) disk storage (or similar rewritable media) as a platform for a WORM storage system.
  • RAID- based disk storage or similar rewritable media
  • This described system is advantageous in that such disks are large in storage capacity, relatively inexpensive and easily added to an existing storage implementation.
  • these disks are also inherently rewritable and/or erasable, in light of existing operating systems and protocols that are typically designed with semantics that specifically enable the free rewriting and erasure of attached disks.
  • the described WORM storage approach is, therefore, specially configured to absolutely prevent alteration of any WORM-designated data.
  • the described WORM implementation utilizes open protocols such as CLFS and NFS and requires minimal alteration to these protocols or the applications that employ them and a minimal footprint on client applications.
  • the system is, thus, organized around WORM storage volumes that contain files, which when committed to WORM storage, cannot be deleted or modified. Any file path or directory tree structure used to identify the file within the WORM volume is locked and cannot be deleted.
  • an administrator creates a WORM volume (or other WORM-designated data organizational structure), capable of storing designated WORM files (or other "data sets").
  • the client then creates an appropriate WORM file using the appropriate protocol semantics.
  • the file is written to the volume and committed to WORM state by transitioning the file attributes from a not-read-only state to a read-only state.
  • the file system persistently stores the WORM state of a file with the attributes and metadata for the file and uses this persistent WORM state to recognize WORM files on a WORM volume.
  • any attempt to modify the file attrib- utes, write to the file, or delete the file, by clients, administrators or other entities is rejected and a request denied message is returned to the attempting party. Since the file cannot be deleted, conventional file system semantics prevent deletion of the directory path.
  • the file system does not permit renaming of directories in an illustrative embodiment to thereby ensure the reliable and immutable identification of WORM files within the directory structure.
  • Committing of the WORM file to the WORM storage volume can be performed by the client via a command line interface in an interactive manner.
  • applications which are familiar with the WORM semantics, can be adapted to commit the file using an appropriate application program interface or other programmatic com- mand structure.
  • open protocols such as NFS or CLFS, through which the clients communicate with the file server/file system can be modified to enable automatic commit of created files upon a key event, such as closing of the file.
  • the protocols and file system can be adapted to enable specialized WORM directories within the volume.
  • WORM file extension can be provided so that worm files within the volume can be readily identified by the client. Also, selected mirroring and backup functions may be allowed, while other backup functions that enable restoration or reversion of the volume to an earlier point in time may be disabled.
  • Many regulatory schemes governing WORM data storage (for example SEC 240.17a-4) specify provisions for retention periods, after which the WORM data can be discarded. In the absence of a specified retention period, applied to the record on creation, the regulations generally specify permanent retention. In the case of removable media, such as tapes or electro-optical storage, the media are carefully indexed and stored (often in secure sites) during their retention periods. Upon expiration of an applicable retention date, the expired media is retrieved from storage and physically de- stroyed.
  • WORM protection on various on-disk records may carry a retention date, and when the retention date passes, the expired WORM record and associated data may be erased, thus preserving storage resources and ensuring the orderly and predictable removal of expired WORM data — without the material waste evoked by physical media destruction.
  • One commercially available WORM storage system marketed under the trade- name Centera from EMC Corp. of Hopkinton, MA enables basic forms of retention dates for record storage. The system utilizes a network-connected cluster of general- purpose computer systems running a customized variant of the Linux operating system.
  • a proprietary application programming interface (API) and proprietary protocols for interfacing with the storage system, as opposed to the open protocol and open standardized API approach is implemented by these computers.
  • applications can only access the storage and manipulate records through proprietary mechanisms or through a "gateway" interposed between the users and the storage system, which trans- lates an open protocol to the proprietary protocols supported by the storage system.
  • This form of WORM storage system utilizes, so-called “Content Addressable Storage,” (CAS) for management of stored records.
  • CAS Content Addressable Storage
  • CAS relies on computing digital signatures, using an algorithm such as an MD5 hash, of the contents of any WORM- stored records to create a unique key (of "content address”) for each and every record.
  • a representation of the digital signature of a record is used as the "key,” or "content address,” with which any future reference to the stored object must be made. This is often described as similar to a "claim check” system whereby the storage system generates a unique key for every object stored, which it returns to the application. The application is responsible for management and preservation of these content addresses, which must be performed external to the storage system.
  • the proprietary API permits metadata, in a proprietary format, to be associated with a stored object. This metadata information can include retention information for the record.
  • the API supports the ability to extend retention dates further into the future, and in certain configurations, to assign an infinite retention date to those records submitted without retention information.
  • This invention overcomes the disadvantages of the prior art by providing a specified retention date within a data set that is locked against deletion or modification within a WORM storage implementation.
  • This retention date scheme does not utilize any proprietary application program interfaces (APIs) or protocols, but rather, employs native functionality within conventional file (or other data containers, data sets or block-based logical unit numbers) properties available in commonly used operating systems.
  • the retention date/time is calculated by querying the file's last-modified time prior to commit, adding the retention period to this value and thereby deriving a retention date after which the file can be released from WORM.
  • the computed retention date Prior to commit, the computed retention date is stored in the file's "last ac- cess time" property/attribute field, or another metadata field (typically open protocol- based) that remains permanently associated with the file and that, in being used for retention date, does not interfere with file management in a WORM state. Since this field is non-essential and rarely utilized in a WORM context, it can be adapted to store this date. Once stored, the retention date in this field is locked against modification. Where extension (never reduction) of a retention period is desired, the last access time field be updated, wherein the retention period extension is added to the existing last access time value to derive a new, later retention date for the file.
  • the system Upon expiry of the retention date, the system allows deletion of the expired WORM file/data set.
  • the procedure checks whether the retention date provided by the administrator, user or interface is allowed by a particular set of WORM rules governing a volume. To this end, there may be more than one set of WORM rules applicable to a storage system. For storage requiring strict (government regulatory, for example) compliance, a strict or regulatory WORM volume may be employed. Storage in this volume is sub- jected to strict minimum default retention periods or, in the absence of a specified period, infinite periods. No modification or deletion of files is permitted until an applicable retention date expires. ( Conversely an "enterprise" volume, defined under a trusted administrator model may permit flexible setting of retention dates and/or no date as a default.
  • a secure compliance clock is used to gauge the time relative to the retention period.
  • this clock uses a trusted time- base, such as a repetitive file server process to derive its time value.
  • the clock is tamper-proof, and its time value is guaranteed to be no sooner that actual time, but may be slightly longer to further ensure observance of the full retention period.
  • the clock can be based upon a trusted third-party clock (such as a government-based clock) or an additional secure hardware-based clock.
  • the stored retention date/time can overcome certain limitations in bit range for older open protocols by providing a base time date (epoch) that is relatively contempo- rary with the present day.
  • the available date range under such bit range limitations can be extended generally by redefining the epoch (base time) to which the time value is relative.
  • the identical format is used for dates within the epoch while wrap-around encoding of the date (e.g. using dates before the epoch as an extended range) for values appearing within the extended date range.
  • Fig. 1 is a schematic block diagram defining an exemplary network and file server environment including a file server and associated clients within which the prin- ciples of this invention are implemented;
  • Fig. 2 is a schematic block diagram of an exemplary storage operating system in accordance with an illustrative embodiment of the present invention;
  • Fig. 3 is a flow diagram of a WORM volume creation procedure according to an illustrative embodiment of the present invention;
  • Fig. 4 is a schematic diagram of a directory tree showing an exemplary WORM file pathway;
  • Fig. 1 is a schematic block diagram defining an exemplary network and file server environment including a file server and associated clients within which the prin- ciples of this invention are implemented;
  • Fig. 2 is a schematic block diagram of an exemplary storage operating system in accordance with an illustrative embodiment of the present invention;
  • Fig. 3 is a flow diagram of a WORM volume creation procedure according to an illustrative embodiment of the present invention;
  • FIG. 5 is a flow diagram of a WORM file creation and commit procedure for a Windows® client according to an illustrative embodiment of the present invention
  • Fig. 6 is a flow diagram of a WORM file creation and commit procedure for a Unix® client according to an illustrative embodiment of the present invention
  • Fig. 7 is a schematic diagram of a synchronous mirroring procedure according to an illustrative embodiment of the present invention
  • Fig. 8 is a schematic diagram of an asynchronous mirroring procedure according to an illustrative embodiment of the present invention
  • Fig. 9 is a schematic representation of a generic header for a data format used in the asynchronous mirroring procedure of Fig. 8;
  • FIG. 10 is a schematic representation of a WORM flag for a data file transmitted in accordance with the asynchronous mirroring procedure of Fig. 9;
  • Fig. 11 is a flow diagram of a retention date/time setting procedure for WORM files according to an illustrative embodiment of this invention;
  • Fig. 12 is a flow diagram of a procedure for extending a retention date/time in a committed WORM file according to an illustrative embodiment of this invention;
  • Fig. 13 is a timeline for illustrating an exemplary technique for extending the available retention date range for certain open protocols having a limited bit range for dates according to one embodiment of this invention;
  • Fig. 11 is a flow diagram of a retention date/time setting procedure for WORM files according to an illustrative embodiment of this invention.
  • Fig. 12 is a flow diagram of a procedure for extending a retention date/time in a committed WORM file according to an illustrative embodiment of this invention;
  • Fig. 14 is a schematic representation of an exemplary secure compliance clock for use in tracking retention dates/times according to one embodiment of this invention
  • Fig. 15 is a flow diagram of a procedure for determining expiration of a reten- tion date/time of a subject file and unlocking WORM certain restrictions on the subject file according to an illustrative embodiment of this invention.
  • Fig. 1 is a schematic block diagram of a storage system environment 100 that includes a file server 112 that may be advantageously used with the present invention.
  • the source system is a networked computer that manages storage of one or more storage disks 160 (can't find 162 in Fig 1).
  • the file server or "filer” 112 manages one or more volumes 115 and 116, comprising arrays of disks 160.
  • the filer 112 is linked to a network 118 that can comprise a local or wide area network, such as the well-known Internet.
  • An appropriate network adapter 130 facilitates communication over the network 118.
  • the filer 112 generally comprises a processor 120, a memory 125, a network adapter 130 and a storage adapter 140 interconnected by a system bus 145.
  • Filer 112 also includes a storage operating system 200 (Fig. 2) that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks.
  • Fig. 2 storage operating system 200
  • the inventive technique described herein may apply to any type of special-purpose computer (e.g., file serving ap- pliance) or general-purpose computer, including a standalone computer, embodied as a storage system.
  • the filer 112 can be broadly, and alternatively, referred to - l i ⁇
  • the teachings of this invention can be adapted to a variety of storage system architectures including, but not limited to, a network-attached storage environment, a storage area network and disk assembly directly-attached to a client/host computer.
  • storage system should, therefore, be taken broadly to include such arrangements.
  • the memory 125 comprises storage locations that are addressable by the processor and adapters for storing software program code.
  • the memory comprises a form of random access memory (RAM) that is generally cleared by a power cycle or other reboot operation (i.e., it is "volatile" memory).
  • the proces- sor and adapters may, in turn, comprise processing elements and/or logic circuitry configured to execute the software code and manipulate the data structures.
  • the storage operating system 200 portions of which are typically resident in memory and executed by the processing elements, functionally organizes the filer by, inter alia, invoking storage operations in support of a file service implemented by the filer. It will be apparent to those skilled in the art that other processing and memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the inventive technique described herein.
  • the network adapter 130 comprises the mechanical, electrical and signaling circuitry needed to connect the filer 112 to the network 118, which may comprise a point- to-point connection or a shared medium, such as a local area network.
  • a client (170, 172) may interact with the destination filer 112 in accordance with a client/server model of information delivery. That is, the client may request the services of the filer, and the filer may return the results of the services requested by clients 170 and 172 by exchanging packets 155 encapsulating, e.g., the TCP/IP protocol or another network protocol (CIFS 174 and NFS 176, respectively) format over the network 118.
  • the storage adapter 140 cooperates with the operating system 200 (Fig. 2) executing on the filer 112 to access information requested by the client.
  • the information may be stored on the disks 160 that are attached, via the storage adapter 140 to the filer 112 or other node of a storage system as defined herein.
  • the storage adapter 140 includes input/output (I/O) interface circuitry that couples to the disks over an I/O interconnect arrangement, such as a conventional high-performance, Fibre Channel serial link topology.
  • I/O input/output
  • the information is retrieved by the storage adapter and processed by the processor 120 as part of the snapshot procedure, to be described below, prior to being forwarded over the system bus 145 to the network adapter 130, where the information is formatted into packets and transmitted to the destination server as also described in detail below.
  • the filer may also be interconnected with one or more clients 170 via the network adapter 130. The clients transmit requests for file service to the filer 112 respectively, and receive responses to the requests over a LAN or other network (118).
  • the filer 112 can include a nonvolatile random access memory (NVRAM) 135 that provides fault-tolerant backup of data, enabling the integrity of filer transactions to survive a service interruption based upon a power failure, or other fault.
  • NVRAM nonvolatile random access memory
  • the size of the NVRAM depends in part upon its implementation and function in the file server. It is typically sized sufficiently to log a certain time-based chunk of transactions (for example, several seconds worth).
  • the NVRAM is filled, in parallel with the buffer cache, after each client request is completed, but before the result of the request is returned to the requesting client.
  • An administrator's console 190 is also provided in an illustrative embodiment for controlling various file server functions and operations.
  • the console 190 can be a client or terminal connected via a dedicated port to the file server, or it can be networked via the network link 118, and reside at a remote location — potentially a longdistance away from the file server. Certain commands, to be described below, are en- tered through the console in an illustrative embodiment.
  • the disks 160 are arranged into a plurality of volumes, by way of example termed Volume 0 (115) and Volume 1 (116), in which each volume has a file system associated therewith.
  • the volumes 115, 116 each include one or more disks 160.
  • the physical disks 160 are configured into RAID groups. In one embodiment this organization is arranged so that some disks store striped data and some disks store separate parity for the data, in accordance with a preferred RAID 4 configuration. However, other configurations (e.g. RAID 5 having distributed parity across stripes) are also contemplated. In this embodiment, a minimum of one parity disk and one data disk is employed.
  • Volume 0 is a regular storage volume with full read and write access
  • Volume 1 is a write-once- read-many (WORM) volume in which selected files cannot be modified, erased or otherwise deleted once they are committed to storage.
  • WORM write-once- read-many
  • the storage operating system 200 implements a write-anywhere file system that logically organizes the information as a hierarchical structure of directories and files on the disks.
  • Each "on- disk" file may be implemented as a set of disk blocks configured to store information, such as data, whereas the directory may be implemented as a specially formatted file in which references to other files and directories are stored.
  • the storage operating system is the NetApp® Data ONTAPTM operating system available from Network Appliance, Inc., of Sunnyvale, CA that implements the Write Anywhere File Layout (WAFLTM) file system.
  • the exemplary storage operating system 200 comprises a series of software layers, including a media access layer 205 of network drivers (e.g., an Ethernet driver).
  • the operating system further includes network protocol layers, such as the Internet Protocol (IP) layer 210 and its supporting transport mechanisms, the Transport Control Protocol (TCP) layer 215 and the User Datagram Protocol (UDP) layer 220.
  • IP Internet Protocol
  • TCP Transport Control Protocol
  • UDP User Datagram Protocol
  • a file system protocol layer provides multiprotocol data access and, to that end, includes support for the CIFS protocol 225, the iSCSI protocol 224, the NFS protocol 230, the Hypertext Transfer Protocol (HTTP) protocol 235 and other protocols (not shown) that may be open or proprietary in format, such as NFS version 4, etc.
  • HTTP Hypertext Transfer Protocol
  • the storage operating system 200 includes a disk storage layer 240 that implements a disk storage protocol, such as a RAID proto- col, and a disk driver layer 245, that implements a disk control protocol such as the small computer system interface (SCSI).
  • a disk storage protocol such as a RAID proto- col
  • a disk driver layer 245 that implements a disk control protocol such as the small computer system interface (SCSI).
  • SCSI small computer system interface
  • Bridging the disk software layers with the network and file system protocol layers is a file system layer 250 of the storage operating system 200.
  • the file system layer 250 implements a file system having an on-disk format representation that is block-based using, e.g., 4-kilobyte (KB) data blocks and using inodes or another data structure to describe the files.
  • KB 4-kilobyte
  • file or “files” should be taken broadly to include any type of data organization or "data container” including those used by block-level protocols such as SCSI.
  • data container will therefore be used interchangeably herein.
  • the file system layer 250 indexes into the inode file using the inode number to access an appropriate entry and retrieve a volume block number.
  • the file system layer 250 then passes the volume block number to the disk storage (RAID) layer 240, which maps that volume block number to a disk block number and sends the latter to an appropriate driver (for example, an encapsulation of SCSI implemented on a fibre channel disk interconnection) of the disk driver layer 245.
  • the disk driver accesses the disk block number from volumes and loads the requested data in memory 125 for processing by the filer 112 (see Fig. 1).
  • the filer Upon completion of the request, the filer (and storage operating system) returns a reply, e.g., a conventional acknowledgement packet defined by the CLFS specification, to the client 170 over the respective network connection 172.
  • a reply e.g., a conventional acknowledgement packet defined by the CLFS specification
  • the software "path" 270 through the storage operating system layers described above needed to perform data storage access for the client re- quest received at the filer may alternatively be implemented in hardware or a combination of hardware and software. That is, in an alternate embodiment of the invention, the storage access request data path 270 may be implemented as logic circuitry embodied within a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC).
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • This type of hardware implementation increases the performance of the file service provided by the filer 112 in response to a file system request packet issued by the client 170.
  • a brief discussion of backups is appropriate.
  • mirror or replicate some or all of the underlying data and/or the file system that organizes the data.
  • a mirror is established and stored at a remote site, making it more likely that recovery is possible in the event of a true disaster that may physically damage the main storage location or its infrastructure (e.g. a flood, power outage, act of war, etc.).
  • the mirror is updated at regular intervals, typically set by an administrator, in an effort to catch the most recent changes to the file system.
  • One common form of update involves the use of a “snapshot” process in which the active file system at the storage site, consisting of inodes and blocks, is captured and the "snapshot” is transmitted as a whole, over a network (such as the well-known Internet) to the remote storage site.
  • a snapshot is an image (typically read- only) of a file system at a point in time, which is stored on the same primary storage device as is the active file system and is accessible by users of the active file system.
  • active file system it is meant the file system to which current input/output operations are being directed.
  • the primary storage device e.g., a set of disks
  • a secondary storage e.g., a tape drive
  • the primary storage device stores the active file system
  • a secondary storage e.g., a tape drive
  • the snapshot is taken (i.e., the image captured)
  • the active file system is reestablished, leaving the snapshotted version in place for possible disaster recovery.
  • Each time a snapshot is taken the old active file system becomes the new snapshot, and the new active file system carries on, recording any new changes.
  • a set number of snapshots may be retained depending upon various time- based and other criteria.
  • "Snapshot” is a trademark of Network Appliance, Inc. It is used for purposes of this patent to designate a persistent consistency point (CP) image.
  • a persistent consistency point image is a point-in-time representation of the storage system, and more particularly, of the active file system, stored on a storage device (e.g., on disk) or in other persistent memory and having a name or other unique identifier that distinguishes it from other PCPIs taken at other points in time.
  • a PCPI can also include other information (metadata) about the active file system at the particular point in time for which the image is taken.
  • the terms "PCPI” and "snapshot” shall be used interchangeably through out this patent without derogation of Network Appliance's trade- mark rights. A PCPI/snapshotting process is described in further detail in United States Patent Application Serial No.
  • overlying the file system layer 250 is the user interface 285 for the administrator. This can be accessed via the various protocols (CIFS, NFS, etc.) described above.
  • a specialized asynchronous volume and sub-volume (or "qtree") snapshot mirroring (or replication) application 290 is responsible for the generation of the mirrors at a remote destination storage volume based upon changes in snapshots at the source.
  • the snapshot mirroring application 290 operates outside of the storage access request path 270, as shown by the direct links 292 and 294 to the TCP/IP layers 215, 210 and the file system snapshot mechanism (280). This application enables "asynchronous" mirroring of changes in the respective sub-volume.
  • mirroring is written incrementally (and not in real-time with respect to changes occurring on the source sub-volume) to a destination store that can be remote and linked by a network connection.
  • a discussion of asynchronous mirroring at a volume and sub-volume (or q-tree) level is found in U.S. Patent Application Serial No. 10/100,967, entitled SYSTEM AND METHOD FORT DETERMINING CHANGES IN TWO SNAPSHOTS AND FOR TRANSMITTING CHANGES TO A DESTINATION SNAPSHOT by Michael L. Federwisch, et al, which is hereby incorporated by reference.
  • a synchronous volume snapshot mirroring application 298 acting on the RALD layer is provided.
  • This application provides synchronous (real-time) mirror- ing to a mirror store in response to a mirror command initiated by an administrator.
  • This mirroring creates a point-in-time image of the source that copies it as it existed at the time the mirror command is acted upon.
  • Approaches to volume-based remote mirroring of snapshots are described in detail in commonly owned U.S. Patent Application Serial No. 09/127,497, entitled FLLE SYSTEM IMAGE TRANSFER by Steven Klei- man, et al. and U. S. Patent Application Serial No.
  • the storage operating system includes a WORM utility 299 that resides generally in the file system layer 250.
  • this WORM utility is responsible for establishing specialized worm volumes 275 in the file system that are differentiated from conventional file system volumes 276. These volumes are carried respectively into the RAID layer as corresponding, differentiated WORM and non- WORM RAID volumes 277 and 278, respectively.
  • this utility is responsible for establish WORM files or like "WORM data containers" (e.g.
  • the storage operating system 200 also includes a secure compliance clock 279 that, in an illustrative embodiment, is a software-based clock used in connection with the setting, tracking and enforcement of retention periods on WORM files as described in detail below.
  • the compliance clock can be implemented as a further hardware-based clock or a feed from a trusted third party (government-based, for example) clock.
  • all embodiments of a compliance clock can include mechanisms to thwart tam- pering and ensure reliability of the output time value.
  • pathway shall refer to the route taken by the storage operating system through the directory structure in addressing the data container.
  • teachings of this invention can be applies to a variety of storage environments and data types including, but not limited to, file data, database data, block-level data, etc..
  • WORM Volume Creation With reference to the flowchart in Fig. 3, a generalized procedure 300 for creating a WORM volume and the results of its creation is described. This procedure is implemented typically by the administrator using the administrative console and interface to input the appropriate volume create command. The file system is modified to recognize a new semantic relative to the conventional (pre- WORM) volume create command that designates a WORM volume.
  • the administrator initially creates the WORM volume having some general parameters such as for size in terms of number of disks. In one embodiment this is accomplished by typing in the following exemplary command including the volume name "volname" and the "-L", the number of disks: vol create ⁇ volname> -L ⁇ number ofdisks>.
  • the volume is assigned the requested name (volname) on the file server. As such, it is identified as /vol/volname.
  • the disks that are associated with the volume are marked with a WORM attribute on their RALD labels in persistent storage so that they are identified as WORM volumes. This may require a modification of the conventional RALD layer structure to account for this added label. While WORM is enforced primarily at the file system layer, this tag serves both to identify the as- signed disk as a WORM store. Here, the WORM designation is stored in non-volatile memory in the persistent label of a WORM disk.
  • the label contains identification information regarding the disk that permits the storage operating system to map the disk to particular volumes, and is stored in a standardized location on the disks (for example, the beginning). In this manner, the WORM designation is maintained on the disk itself containing the WORM file. Additionally, the WORM designation can be stored in NVRAM or other persistent/battery-backup memory structures and to prevent the inadvertent or deliberate destruction of the volume as discussed further below.
  • step 304 does not require user interaction as the volume name is assigned as part of the creation process for WORM volumes. This can be handled internally by the system.
  • the volume is then exported (for NFS clients) or shared (for CIFS clients) or otherwise made available for use by outside clients.
  • the export/share step is a conventional process that gives appropriate use permissions to clients.
  • the simplified syntax of a suitable command is: exporfs f-o options] /vol/volname
  • the syntax is: cifs shares -add ⁇ sharename> /vol/volume
  • Exports and shares may include appropriate access controls and privileges to clients so that only certain users may access the volume. Permissions are also entered. These generally control what can be done on and to the volume (aside from WORM) functionality. For example it is possible to create a read-only volume, but this would limit future writing to the volume.
  • the WORM status is not revocable under any circumstance by a user, administrator or other so as to maintain the integrity of the WORM data.
  • the WORM volume is now on-line and accessible by clients.
  • the WORM functionality is in operation and in force, and the restrictions it imposes are present. In one embodiment these restrictions can include: 1. WORM disables the volume destroy command — in an illustrative embodi- 5 ment WORM volume destruction permitted so that a WORM volume is immutable.
  • WORM disables conventional restoration of WORM volume or parts thereofo from a snapshot — prevents improper reconstruction from an earlier point-in-time image that obliterates later modifications to files and WORM files committed after the point- in-time. It should be noted that the WORM principles described herein can apply in at least two different scenarios, a more strict scenario in which the administrator is un-5 trusted (a government-regulated scenario) and one established upon the trusted administrator or "enterprise" model.
  • Permissions (Set Attributes command “SETATTR” in NFS) (Set File Information “TRANS2_SET_FrLE_INFORMATION” command in CLFS) require that any file (or data container) within the volume be a WORM file if it is set to "read-only" from an initial not-read-only state — he file system layer distills all permissions from5 their respective protocols to cause WORM state to be assigned to files which undergo this not-read-only to read-only transition. 4. Any WORM file modifications (e.g. write, rename, delete (subject to retention dates, below), file attribute change, etc.) within the volume that modify the state of the file, including attempted modification of date stamps, read-only status, etc.
  • WORM file modifications e.g. write, rename, delete (subject to retention dates, below), file attribute change, etc.
  • the file system first checks the WORM state of the volume and then the target file's individual WORM state (described below) is checked before modification is permitted. If the file is WORM, then the modification is restricted, and the file server returns an appropriate file error message such as "read-only” or "access-denied” denying the modification request.
  • the setting of a retention date employs the last access time property field, which is set prior to commit. This set value is used to track retention periods for particular files. Upon expiration, other properties, such as deletion of the particular expired file, may be unlocked, allowing limited access for this purpose.
  • conventional file attributes can include: the hidden file flag, read-only flag, archive flag (set before backup performed but after writing to file), creation timestamp, modification timestamp, access timestamp, access control lists (ACLs) and NT streams. These attributes are typically locked against modification where such modification may allow improper changes to a file.
  • conventional file attributes that are locked can include access control and other permissions related to the file owner, group, etc.
  • NFSv4 has many similar attributes to be locked to those in CIFS described above. 5.
  • Directory renaming is not permitted in a WORM volume in one embodi- ment. This prevents the directory from being altered to potentially misplace a WORM file.
  • directory renaming is allowed as long as the renaming does not misplace any WORM files, however, in many instances, the basic rule of preventing directory renaming in a WORM volume reduces overhead and increases performance by eliminating the need to check for the displace- ment of any WORM files in a directory tree whenever a directory renaming command is entered. 6.
  • Directory deletion is not permitted where a WORM file is present. As shown generally in Fig. 4, the committing of a WORM file 402 to a directory tree 400 of a WORM volume makes it immutable and not subject to deletion or modification.
  • WORM volume is created by the administrator as described above, it is available for use by permitted clients.
  • the WORM volume allows all conventional volume operations on non-WORM files and directories (e.g. create directories and files, write to files and delete directories and files) subject to the general restrictions above.
  • the volume allows the one-time writing of WORM files and the reading or copying of WORM files.
  • WORM files are specialized files (or data sets/data containers) within the overall WORM volume. In other words, not all files within a volume are necessarily WORM files.
  • WORM files are created by client and file server appli- cations where needed to store or archive information that must remain immutable.
  • One such application may be an e-mail archive program that gathers desired e-mail records on a continuous or periodic basis and stores the records in an archive file.
  • a client running the well-known Windows® operating system (available from Microsoft Corporation of Redmond, WA)
  • the procedure 500 for crea- tion of a file and its commitment to WORM is shown in Fig. 5.
  • the client adds a network share for the WORM volume into which a WORM file is to be stored.
  • this volume can be named "drive W.” This drive then appears in the list of shared drives shown to the client.
  • step 504 the file is saved to the WORM drive W using standard Windows commands.
  • step 505 the user is allowed to enter a relevant retention period.
  • entry of retention dates into the appropriate attribute of the file is carried out either programmatically using a standard Windows application program interface (API) by the client application that handles storage of the file, or using an available, non- Windows command line utility capable of setting the attribute for the file.
  • API Windows application program interface
  • step 506 the client calls up the "file properties" dialog and sets the read-only attribute for the WORM file on drive W.
  • the file server's file system recognizes the transition of the file from not-read-only to read-only state and thenceforth designates the file as WORM and all the above restrictions or modification, changes in attribute, etc. are enforced. Significantly, any subsequent attempt by the client to modify the read-only state of the file is denied, and a permission denied message is returned to the client from the file server. In this manner, the final step 506 is termed the "commit" of the file to WORM state. For any protocol, the commit step is needed to imbue the file with WORM characteristics.
  • the commit process is dependent not simply upon the storage of a read-only file in a WORM volume, but rather the transition of the file within the WORM volume from a not-read-only state to a read-only state.
  • Copy utilities and other file-creating applications that do not transition the file to read-only from a not-read-only state may not render a file as WORM.
  • the commit process involves the transition of a file attribute from a not-read-only to a read-only state
  • other transitions of other conventional attributes such as the renaming of a file to a WORM file-type
  • setting of other specialized attributes or metadata can be used to trigger commit.
  • the storage of the data or file (or movement thereof) into a WORM-designated portion or structure of storage could act as the trigger for commit.
  • the procedure 600 in Fig. 6 outlines the associated WORM file creation and commitment steps.
  • step 602 the WORM volume is mounted using conventional volume-mounting procedures.
  • the exemplary command "mount filer:/vol/volname /worm " can be used.
  • the file is then copied (step 604), and the typical command line shell command would be: cpfile.txt /worm.
  • the WORM file is saved or copied onto the appropriate WORM volume, the user is allowed to enter a relevant retention period (step 605).
  • the process for entering and handling such retention periods is described in detail below.
  • the retention period can be set interactively in a Unix system environment by the "touch" command with appropriate options to set the file attribute.
  • a variety of available "touch" utilities, running n a Windows or other platform, can be used to set the attribute.
  • the exemplary command is: touch -a -t ⁇ date> ⁇ le>.
  • Commit is then accomplished by removing all write permissions from all owners, groups and users, thereby transitioning the file from a not-read-only to read-only state, and hence, WORM.
  • the shell exemplary command for removal of permissions would be: chmod -w /worm/file. txt.
  • the commit is simply the expression: ATTRIB + R ⁇ filename>.
  • Each of the above command line expressions are specifically used in interactive sessions at the client. In other words, the client user physically enters the command and awaits the appropriate response from the file server.
  • WORM volumes are used only with applications that recognize and can employ a WORM volume's special properties and modified semantics.
  • Win32 Windows-based C++
  • the application function call would be: fchmod ( ⁇ file>, 0444)
  • fchmod ( ⁇ file>, 0444)
  • the creation of WORM volumes as well as the storage of WORM files (data containers) requires minimal alteration to the open protocols (CIFS, NFS, etc.), and similarly, minimal alteration of specific applications using the WORM functionality. This is because the majority of new functionality is contained within the file system layer, and that file system layer is adapted to recognize simple modifications to volume-create commands and preexisting file attribute transitions (i.e. not-read-only to read-only) to implement WORM within the file system layer.
  • an automatic commit function can be incorporated into the open protocols according to an alternate embodiment.
  • a procedure can be implemented that causes a commit to WORM upon closing of a created WORM file. That is, the protocol recognizes the worm create dialog and proceeds with a commit (e.g. not-read-only to read-only attribute change) when the file is closed. This is more challenging in a stateless protocol such as NFS.
  • NFSv4 supports a number of stateful operations and may provide a ready platform for automatic commit like CIFS.
  • Other protocols may also be provided with automatic commit upon file closure.
  • WORM-directory In one imple- mentation, only WORM files may have access to the worm directory.
  • a ".worm" file extension is provided so as to allow a user to view all files having a worm commit.
  • any section of a file can be written only once.
  • an automatic commit mechanism can be employed, which would allow data to be appended to an existing file or to fill any "holes" in the file, but would disallow attempted modifications to the existing written data in the file.
  • Such a so called “incremental WORM commit” lends itself to applications like a WORM log file in which existing records in the file are WORM, but new records may be appended to the file end in the "unwritten" space.
  • WORM volume activity such as volume creation and volume destruction (if permitted), WORM file writes, etc.
  • Fig. 7 details a synchronous mirroring procedure 700 in which WORM volume data 702 is transmitted to a destination volume 706 in real-time as it is created and stored on the source WORM volume 704.
  • the transmis- sion generally occurs over a high-speed link 710 using a transport protocol (Fibre Channel, iSCSI, etc.) capable of supporting a high-speed, real-time data transfer from source to destination.
  • a transport protocol Fibre Channel, iSCSI, etc.
  • the mirror is another disk array, being filled at the same time as the source.
  • whatever enters the source volume also enters the mirror destination volume. Since the majority of the mirror function is handled at the storage (RAID) layer, little intervention from the higher level file system on the source is needed.
  • the destination volume Before the destination volume is used, it is first created on the destination storage system.
  • a mirror volume, or other structure is automatically created via the RAID level in the same filer or file server as the source. It transfers all the WORM functionality from the source to the destination in this instance.
  • the destination volume is typically accomplished by act of an administrator using an appropriate volume create command.
  • the destination volume is created as a WORM volume, requiring that the backup storage system, upon which the destination volume resides, have a file system that includes the WORM functionality.
  • WORM mirror volume By using a WORM mirror volume, the integrity of the stored data is further protected and it com- plies with the general requirements for secure backup storage. It is possible and may sometimes be desirable to establish a non-WORM destination volume, but such a volume may violate rules for secure backup store. Because the destination volume is a WORM volume, any interruption in the mirroring process may be irreparable.
  • the system may be required to reinitialize the mirror including transferring all stored records, i.e., a level zero transfer to a newly created destination volume.
  • the WORM nature of the source may impose limits on the reconstruction of a source from a destination (e.g. a restore process) in the event of a disaster. Since WORM files in the source WORM volume are, by definition, non-rewritable, the preferred procedure to repair the source volume is to replace it with the mirrored destination volume. Partial reconstruction of the source using the destination may be prohibited.
  • FIG. 8 shows a simplified diagram of an asynchronous mirroring procedure 800.
  • This approach is described in detail in the above-incorporated U.S. Patent Application Serial No. 10/100,967, entitled SYSTEM AND METHOD FORT DETERMINING CHANGES IN TWO SNAPSHOTS AND FOR TRANSMITTING CHANGES TO A DESTINATION SNAPSHOT by Michael L. Federwisch, et al. , and should be referenced in conjunction with the following description.
  • the file system of the source volume 802 is adapted to generate time-separated point-in-time images or "snapshots" (280 in Fig. 2) of the source volume data structure or the data structures of certain sub-volumes (for example q-trees).
  • one such sub-volume can be a worm (a ".worm” extension, for example) directory structure as described above.
  • the snapshots are scanned by the asynchronous snapshot mirroring application to detect changes in files based upon noted differences between snapshots taken at different times.
  • the changes are transmitted in a formatted data stream 806 over a conventional (typically lower-speed) network connection 810 — hat may include the well-known Internet. Because of the lower-speed connection, the changes are not generally changes occurring in real-time, but are written to the destination "asynchronously" or in lazy write fashion at periodic intervals.
  • the data is formatted as a series of metadata (in the form of inodes in one embodiment) and associated file data. To make this data meaningful to the destination file system, it is formatted using recognizable headers that separate various portions of the data transfer (e.g.
  • Fig. 9 details a simplified version of the header described in detail in the above-referenced Federwisch, et al. application.
  • This header includes a generic part 902 of 1KB, a non- generic part 904 of 2 KB and an expansion segment 906 of 1 KB.
  • a worm volume transfer flag 908 that signals the destination file system that WORM volume information is being transmitted in the data stream to follow. This flag is located in the "public" portion of the header so as to be recognized by open protocols. Similarly, as shown in Fig.
  • each data file 1000 in the stream contains a WORM flag bit 1002.
  • This bit in combination with the header information is used to reconstruct new inodes (metadata) in the destination WORM volume with an appropriate WORM state information about the file (or other data set/data container) to which the inode/metadata points.
  • the destination file system's mirroring application is adapted to translate the encoded flags appropriately. More specific details regarding the procedure by which inodes are constructed in the destination volume are provided in the above-referenced application.
  • security between a source and destination file server may be enhanced by employing conventional encryption and/or authentication techniques or other security-enhancing measures in order to establish a trust relationship between the source and destination.
  • certain restoration functions otherwise considered undesirable may be employed with safety.
  • a retention period may be set in connection with a WORM file (or other data set/data container).
  • This retention period basically sets a file attribute before commit of the file to WORM that causes the system to observe all WORM properties described above (no deletion, modification, etc.) for the WORM file during the applicable retention period, but after expiration of the period allows the user to perform a limited set of non- WORM actions on the now-expired WORM file. Namely, the expired WORM file may be deleted from the WORM volume, thereby freeing space for new storage.
  • FIG. 11 shows a generalized procedure 1100 for setting retention periods (with the effective date/time after the period elapses being termed a "retention date") in connection with WORM files.
  • a file, intended to be stored as WORM is initially created or copied onto the worm volume (step 1102) as described generally in step 504 (for exemplary Windows® systems) and/or step 604 (for exemplary Unix® systems).
  • step 1102 the worm volume
  • step 1104 for exemplary Windows® systems
  • step 604 for exemplary Unix® systems
  • the utility determines whether the retention period falls within an acceptable range. As described below, the period may be limited based upon the number of bits available in a given attribute.
  • a minimum retention date may be specified. Assuming the period falls within the acceptable range, then the period is accepted (decision step 1105). Otherwise, the period may be rejected and the system returns an invalid value error code. If the user or administrator opts for no period or the period is not a valid one, this is interpreted by the utility as a default value retention period (step 1110). The nature of this default value may depend upon a variety of factors. For example, where the WORM volume is based upon an "enter- prise" model with a relatively trusted administrator, the default may be set to an arbitrarily defined value, or an infinite value or zero (no retention period), as appropriate.
  • a minimum or infinite retention period defined by the applicable rules and practice, assigned to the file by default.
  • an infinite value a particular bitcode is written in the property or attribute to signify an indefinite retention period, such as zero.
  • a minimum retention date may be specified.
  • a finite minimum default retention date can be specified should no date be provided by the user. This may also de- pend upon the nature of the WORM volume into which the file is stored.
  • some volumes may be set to an "enterprise" default environment wherein the administrator is trusted and the rules provide more leniency in assigning retention dates.
  • absence of a retention date may be presumed to assign an indefinite date or a particular finite date based upon the rules governing the particular enterprise WORM volume.
  • the procedure 1100 queries the metadata file attributes or properties to determine the last modified time on the file (step 1106).
  • the last modified date is used as the base data from which the retention date is computed.
  • the last modified date is fixed once the file is committed to WORM — the file cannot be modified after commit, given the recognition in a WORM volume of a read-only as a WORM.
  • the queried last-modified time, prior to commit is the creation or copy time for the file.
  • the last modified data is just one possible basis for the computation of retention date.
  • a variety of other base time values that are considered reliable such as a direct query of the compliance clock 279 or another trusted clock (e.g. a client clock) can be employed in alternate embodiments.
  • the procedure Having received a valid non-infinite retention period, the procedure then attempts to ensure that the period is sufficiently far in the future to account for clock s skew and other factors that may affect the reporting of time by the compliance clock 279 (Fig. 2).
  • the retention period must be set to a minimum future time value following the last-modified time (for example one or two days in the future).
  • the system assumes a default retention period is to be applied (step 1110).
  • a retention period is chosen (finite or infinite)
  • the procedure 1100 computes the time value to be observed in determining the data at which the file is to be released from WORM (step 1112). This entails adding the retention period time (for example, "retain file for 10 years") to the last modified time, and thereby deriving a future release date for the file.s This computed retention date/time value is then applied to the last access time property or attribute in the file (step 1114). This attribute is also rarely, if ever, used in a WORM context, and even in a non-worm context, is not particularly critical.
  • the last access time property/attribute is used by the WORM utility as the vehicle to store the critical retention date bitcode (if any). Having applied a retention date into the last access time field, the file can now be made immutable. Accordingly the read-only attribute us set as described above, causing the WORM utility to refuse any further modifications to the file.
  • the5 file's attributes/properties including last access time are fixed. In this manner the future retention date is fixed in the last access time field, and made immutable. There are circumstances in which the retention period must be extended after initially setting it.
  • the WORM utility includes provision for a limited modi- fication of the committed WORM file's properties to account for the extension of a retention period.
  • Fig. 12 details a retention date/time extension procedure 1200.
  • a user or administrator typically initiates a request to extend the retention period of a particular file (step 1202).
  • the extension period date must fall within a value that is supported by the last access time field. If so, the procedure then queries the last access time to retrieve the existing field value (step 1204).
  • Step 1206 verifies that the requested date or period is further in the future than the existing date. If not the request to extend is denied. Conversely, if the request is for an extension sufficiently far ahead in the future, then a new extended retention date/time is computed (step 1212).
  • the computation can occur in a variety of ways.
  • the extended data can be based upon either the creation time or the last modify time where the new extended period is added to these values.
  • the extended retention date can be computed by adding the last access time value (the current retention date/time) and the new extended period are added to compute the new extended retention date/time. In any of the above examples, if the extended period is infinite, then an appropriate representation for the indefinite retention period is computed.
  • step 1214 the WORM utility over- rides the normal prohibition against any modification of the subject WORM file and allows the limited overwrite of the last access time property to contain the new computed extended retention date value (or indefinite retention indicator).
  • certain older open protocols such as the commonly used NFSv2 and v3 use a 32-bit time format that is interpreted as seconds since January 1, 1970 (e.g. "time 0"). If interpreted as an unsigned value, this expression provides a last access time up to February 1, 2016.
  • the WORM utility is provided with a new, more contemporary baseline time or epoch (new time 0), of, for example, January 1, 2003.
  • new time 0 a new, more contemporary baseline time or epoch
  • the WORM utility interprets (see timeline 1300 Fig. 13) last access times before January 1, 2003 (new time zero) differently than those after January 1, 2003. In this manner all retention dates falling between new time zero and January 18, 2038 (old upper bound) are retained as standard values (31-bit Date Range 1).
  • any last access time value that is a time before new time zero would fall before the effective date for the WORM system, these dates are reinterpreted or wrapped around (arrow 1301)) as an upper range of dates (31-bit Date Range 2) between January 18, 2038 and January 1, 2071.
  • the two 31 -bit date ranges (before new time 0 and after new time 0) provide an overall 32-bit retention date range 1302 to a new exemplary upper bound of January 1, 2071.
  • a variety of solutions to a limited bit range for time values can be employed.
  • a time-remapping technique is not needed.
  • a secure compliance clock 279 (Fig. 2) is provided to the storage operating system.
  • the compliance clock interacts with various aspects of the storage operating system as well as the WORM utility to generate a time value that is reliably targeted to provide the desired retention date over a typical retention period.
  • An exemplary compliance clock 279 in accordance with an illustrative embodiment is shown in Fig. 14.
  • the clock is typically implemented as a software, rather than hardware mechanism.
  • the clock includes a time value generator 1402 that receives a consistent pulse from a regularly-scheduled, continuous filer event 1404 such as a consistency point operation (CP).
  • CP consistency point operation
  • the generator 1402 has a scaling function that translates the CP or other event into a time-based value. For example, if a CP occurs every 11 seconds, the clock translates each CP into an 11 -second advance in the time- base.
  • a counter in the generator 1402 keeps a running total of events from which an ongoing date/time value 1410 is produced and output to the WORM utility and other interested components of the system.
  • the generator receives its base time value (for example, time 0) and can store its running total time in an appropriate memory element.
  • the time memory can be periodically committed to persistent storage using, for example, an on-disk record in, for example, an undeletable WORM file 1414 on the associated WORM volume.
  • this also means that the compliance clock travels with the WORM volume rather than the underlying filer.
  • This file is accessed in the event of a system crash, failure, or replacement/upgrade of the filer.
  • the clock file for each WORM volume is read and, as an added safety measure, the earliest clock time is selected as the value for the filer's overall compliance clock in its WORM operations.
  • the compliance clock generator 1402 is updated to account for this change in the timebase and the elapsed time count from the file 1414 is loaded to begin the count again with the new scale still outputting the desired accurate time count.
  • the compliance clock 279 can be provided with an input from the conventional system hardware/software system clock (or another generally trusted clock) 1416 from which it can compare its reported time to the allegedly actual time. This comparison can be both on an absolute basis (e.g. current reported date/time versus system reported date/time) and based upon the relative passage of time (e.g. number of seconds elapsed for the system clock versus the compliance clock).
  • the hardware system clock will, in fact, be synchronized to a valid true time source.
  • the compliance clock performs the described incremental counts of periodic events (CPs for example), but also “drifts" toward the hardware system clock time at a strictly bounded rate. This "bounded drifting" allows the compliance clock to track or lock onto the system hard- ware clock time to counteract the compounding of the clock skew over long periods of time.
  • the bounded drift rate 1418 ensures, even if the administrator adjusts the clock forward by, for example 10 years, in an effort to prematurely delete WORM records, that the compliance clock drifts so slowly toward this new time as to make the subver- sion attempt ineffective.
  • an allowable drift rate of only ⁇ 1000 seconds per year is permitted (i.e. the compliance clock can "drift" by no more than 1000 seconds backward or forward during a 1-year period)
  • the compliance clock could take hundreds of years to skew by 1 year.
  • an alert can be issued to the administrator or a supervisor/regulator.
  • all alerts can be logged to persistent/WORM storage in association with the volume and clock file. Given such an alert, appropriate action by authorities can be taken. Also, during an alert period, any deletion or modification of files could be disabled.
  • a secure hardware clock or trusted third party (for example, government-based) clock can also provide a high degree of tamper pro- tection.
  • an exemplary compliance clock has been described above, a variety of mechanisms and techniques involving external, internal or a combination of internal and external time-keeping procedures are expressly contemplated.
  • an external master clock such as a government-based atomic clock interconnected by a network can be employed.
  • a client attempts to manually delete a given file, or an appropriate application daemon process sweeps the volume to find and delete files, the system must determine whether the retention date for a given file has expired and deletion thereof is permitted.
  • Fig. 15 shows a generalized procedure for checking WORM retention dates and, when appropriate allowing limited unlocking of WORM status from an expired file.
  • a user or administrator either requests action on a subject worm file (such as deletion), or an application daemon scans the file for possible deletion.
  • the WORM utility queries the last access time attribute for the subject file. This is stored and the compliance clock is queried for the trusted date/time (step 1504).
  • decision step 1506 if the retention date is not greater than or equal to the clock date (or some minimum future date after the clock date for further skew protection), then the requestor is prevented from taking any action on the file (step 1508).
  • an indefinite retention date is set, it is never less than the clock date and action is never permitted by the utility.
  • step 1506 branches to step 1510, and the user or administrator is permitted to take limited action on the file, or action is automatically taken.
  • that action is typically limited only to deletion of the file from the volume, however other file-handling options may be permitted for an enterprise model WORM implementation. In this manner, other actions that may tamper with the integrity of the file while leaving it intact are still prevented.
  • the read only-attribute that committed the file to WORM is retained while, in combination with an expired date enables a return to the limited file permission of deletion. The utility thus places only a deletion permission on the expired WORM file.
  • a client can implement an automatic deletion of expired- retention-date files via operation of an application daemon or similar utility.
  • use of a compliance or trusted clock to provide a reliable reference to expiration of re- tention dates facilitates an automatic deletion process. That is, the deletion can occur in an "automatic" manner based upon periodic scans of the volume (see step 1502) to locate expired files — those with retention dates greater than or equal to the trusted clock time.
  • a recent trusted clock time can be stored in system memory and compared to the time in each file to locate the expired ones.
  • the retention date of each file can be read and then a current clock time can be retrieved and compared.
  • Deletion can occur on each file in turn after expiration is confirmed, or all ex- pired files can be identified by the scan and deleted thereafter in a batch process. These files are then deleted by the application using appropriate file management scripts. While the daemon describe herein typically runs on the client, it is expressly contemplated that an automatic deletion process, based upon a trusted clock can be imple- mented on either the client side, the file server side or both. Note that in an alternate embodiment the WORM filer or file server described herein can be implemented as a multi-protocol storage appliance and the resident storage operating system can be implemented as a virtualization system with virtualization modules embodied as a virtual disk (“vdisk”) module and a SCSI target module (not shown).
  • vdisk virtual disk
  • SCSI target module not shown
  • the vdisk module is layered on the file system 250 to enable access by administrative interfaces, such as a streamlined user interface (UI), in response to a system administrator issuing commands to the multi-protocol storage appliance.
  • UI streamlined user interface
  • the vdisk module manages SAN deployments by, among other things, implementing a comprehensive set of vdisk logical unit number (lun) commands issued through the UI by a system administrator.
  • These vdisk commands are converted to primitive file system operations (“primitives") that interact with the file system 250 and the SCSI target module to implement the vdisks.
  • This multi-protocol storage appliance arrangement is described in further detail in commonly owned U.S. Patent Application Serial No.
  • proprietary APIs can be used to implement retention dates. These can be combined with the trusted or compliance clock as described herein to ensure reliable retention and tamper-proof opera- tion.
  • the term "storage system” can include a content addressable storage system (CAS) as described generally above. Such a trusted clock could enhance reliability and tamper-proof operation of these types storage systems.
  • retention date/time values associated with each data container, set or file are provided within a last accessed property field in an illustrative embodiment, it is expressly contemplated that this value can be applied to any property, attribute or other data associated with the container, set or file that can be made immutable and that does not interfere with the management and handling of the container, set or file during its storage in WORM.
  • a file's retention date/time is set or extended according to an illustrative embodiment by querying the last modified date and adding the retention period thereto, a variety of base time values can be used to compute the retention date/time including, for example, the retrieval of a base time from the compliance clock or another trusted time source.

Abstract

L'invention concerne une date de fin de validité spécifiée dans un ensemble de dates verrouillé contre une suppression ou une modification dans la mise en oeuvre d'un stockage WORM. Ce mécanisme de date de fin de validité n'utilise pas d'interfaces de programme d'application (API) propriétaire ou de protocoles, mais utilise plutôt une fonctionnalité native dans des propriétés de fichier classique, (ou d'autres conteneurs de données, ensembles de données ou nombres d'unités logiques à base de bloc) disponibles dans des systèmes d'exploitation communément utilisés. Dans un mode de réalisation pris en exemple, la date/moment de fin de validité est calculé par demande du dernier moment modifié du fichier avant sauvegarde, par adjonction de la période de fin de validité à cette valeur et donc par dérivation d'une date de fin de validité après laquelle le fichier peut être libérer de WORM. Avant la sauvegarde, la date de fin de validité calculée est stockée dans le champ d'attributs/propriétés 'dernier moment d'accès' du fichier ou dans un autre champ de métadonnées qui reste associé en permanence au fichier et qui, étant utilisé pour une date de fin de validité, n'interfère pas avec la gestion de fichier à l'état WORM. Du fait que ce champ n'est pas utilisé dans un contexte WORM, il peut être adapté au stockage de cette date. Une fois stockée, la date de fin de validité de ce champ est verrouillée contre une modification. Lorsqu'une extension (jamais une réduction) d'une période de fin de validité est désirée, le dernier champ de moment d'accès est mis à jour, la nouvelle période de fin de validité étant ajoutée à la valeur existante de dernier moment d'accès afin de dériver une nouvelle date de fin de validité pour le fichier. A l'expiration de cette date de fin de validité, le système permet la suppression de l'ensemble de fichiers/données WORM arrivés à expiration.
PCT/US2004/012378 2003-11-03 2004-04-22 Systeme et procede d'enregistrement de date de fin de validite dans un systeme de stockage a disque inscriptible une seule fois WO2005045556A2 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN2004800395759A CN101443760B (zh) 2003-11-03 2004-04-22 在单写多读存储系统中用于记录保留日期的系统和方法
JP2006539450A JP2007524954A (ja) 2003-11-03 2004-04-22 追記型記憶装置に保存日を記録するシステム及び方法
EP20040818283 EP1690166A4 (fr) 2003-11-03 2004-04-22 Systeme et procede d'enregistrement de date de fin de validite dans un systeme de stockage a disque inscriptible une seule fois
CA2544846A CA2544846C (fr) 2003-11-03 2004-04-22 Systeme et procede d'enregistrement de date de fin de validite dans un systeme de stockage a disque inscriptible une seule fois
AU2004288444A AU2004288444B2 (en) 2003-11-03 2004-04-22 System and method for record retention date in a write once read many storage system
IL175445A IL175445A (en) 2003-11-03 2006-05-04 System and method for record retention date in a write once read many storage system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/701,373 2003-11-03
US10/701,373 US7590807B2 (en) 2003-11-03 2003-11-03 System and method for record retention date in a write once read many storage system

Publications (2)

Publication Number Publication Date
WO2005045556A2 true WO2005045556A2 (fr) 2005-05-19
WO2005045556A3 WO2005045556A3 (fr) 2009-04-02

Family

ID=34551412

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/012378 WO2005045556A2 (fr) 2003-11-03 2004-04-22 Systeme et procede d'enregistrement de date de fin de validite dans un systeme de stockage a disque inscriptible une seule fois

Country Status (9)

Country Link
US (3) US7590807B2 (fr)
EP (1) EP1690166A4 (fr)
JP (1) JP2007524954A (fr)
KR (1) KR100984438B1 (fr)
CN (1) CN101443760B (fr)
AU (1) AU2004288444B2 (fr)
CA (1) CA2544846C (fr)
IL (1) IL175445A (fr)
WO (1) WO2005045556A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016085541A1 (fr) * 2014-11-28 2016-06-02 Nasuni Corporation Système de fichiers versionnés doté d'un verrou global
US9575841B2 (en) 2009-01-23 2017-02-21 Nasuni Corporation Method and system for interfacing to cloud storage
US20210314403A1 (en) * 2015-07-07 2021-10-07 Nasuni Corporation Systems and methods for restoring an interface to a global file system

Families Citing this family (181)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9361243B2 (en) 1998-07-31 2016-06-07 Kom Networks Inc. Method and system for providing restricted access to a storage medium
US7392234B2 (en) * 1999-05-18 2008-06-24 Kom, Inc. Method and system for electronic file lifecycle management
US6993539B2 (en) 2002-03-19 2006-01-31 Network Appliance, Inc. System and method for determining changes in two snapshots and for transmitting changes to destination snapshot
US7873700B2 (en) * 2002-08-09 2011-01-18 Netapp, Inc. Multi-protocol storage appliance that provides integrated support for file and block access protocols
US7051053B2 (en) * 2002-09-30 2006-05-23 Dinesh Sinha Method of lazily replicating files and monitoring log in backup file system
US7340486B1 (en) * 2002-10-10 2008-03-04 Network Appliance, Inc. System and method for file system snapshot of a virtual logical disk
US7590807B2 (en) 2003-11-03 2009-09-15 Netapp, Inc. System and method for record retention date in a write once read many storage system
US7721062B1 (en) 2003-11-10 2010-05-18 Netapp, Inc. Method for detecting leaked buffer writes across file system consistency points
JP2005141683A (ja) * 2003-11-10 2005-06-02 Sony Corp コンテンツ利用管理システム，コンテンツ再生装置，コンテンツ利用管理方法，コンテンツ再生方法およびコンピュータプログラム
US7401093B1 (en) 2003-11-10 2008-07-15 Network Appliance, Inc. System and method for managing file data during consistency points
US7698289B2 (en) * 2003-12-02 2010-04-13 Netapp, Inc. Storage system architecture for striping data container content across volumes of a cluster
US9075851B2 (en) * 2003-12-09 2015-07-07 Emc Corporation Method and apparatus for data retention in a storage system
JP4822663B2 (ja) * 2003-12-12 2011-11-24 ソニー株式会社 情報処理装置および方法、並びに、プログラム
US7162662B1 (en) * 2003-12-23 2007-01-09 Network Appliance, Inc. System and method for fault-tolerant synchronization of replica updates for fixed persistent consistency point image consumption
US7340639B1 (en) 2004-01-08 2008-03-04 Network Appliance, Inc. System and method for proxying data access commands in a clustered storage system
US20050182910A1 (en) * 2004-02-04 2005-08-18 Alacritus, Inc. Method and system for adding redundancy to a continuous data protection system
US7783606B2 (en) 2004-02-04 2010-08-24 Netapp, Inc. Method and system for remote data recovery
US7720817B2 (en) 2004-02-04 2010-05-18 Netapp, Inc. Method and system for browsing objects on a protected volume in a continuous data protection system
US7904679B2 (en) * 2004-02-04 2011-03-08 Netapp, Inc. Method and apparatus for managing backup data
US7315965B2 (en) 2004-02-04 2008-01-01 Network Appliance, Inc. Method and system for storing data using a continuous data protection system
US7426617B2 (en) * 2004-02-04 2008-09-16 Network Appliance, Inc. Method and system for synchronizing volumes in a continuous data protection system
US7559088B2 (en) * 2004-02-04 2009-07-07 Netapp, Inc. Method and apparatus for deleting data upon expiration
JP2005222368A (ja) * 2004-02-06 2005-08-18 Hitachi Ltd ストレージシステム
US7440966B2 (en) * 2004-02-12 2008-10-21 International Business Machines Corporation Method and apparatus for file system snapshot persistence
US7039662B2 (en) * 2004-02-24 2006-05-02 Hitachi, Ltd. Method and apparatus of media management on disk-subsystem
US9229646B2 (en) * 2004-02-26 2016-01-05 Emc Corporation Methods and apparatus for increasing data storage capacity
US7949792B2 (en) * 2004-02-27 2011-05-24 Cisco Technology, Inc. Encoding a TCP offload engine within FCP
US7680864B2 (en) * 2004-03-02 2010-03-16 Intel Corporation Method and apparatus for managing access to stored objects based on retention policy
US7272654B1 (en) * 2004-03-04 2007-09-18 Sandbox Networks, Inc. Virtualizing network-attached-storage (NAS) with a compact table that stores lossy hashes of file names and parent handles rather than full names
US20050210028A1 (en) * 2004-03-18 2005-09-22 Shoji Kodama Data write protection in a storage area network and network attached storage mixed environment
JP4394493B2 (ja) * 2004-03-24 2010-01-06 株式会社日立製作所 ファイル管理方法、ファイル管理装置、及び、ファイル管理プログラム
US7171511B2 (en) * 2004-03-24 2007-01-30 Hitachi, Ltd. WORM proving storage system
JP2005284816A (ja) * 2004-03-30 2005-10-13 Hitachi Ltd ディスクアレイシステム
JP2005301684A (ja) * 2004-04-12 2005-10-27 Hitachi Ltd ストレージシステム
JP4491269B2 (ja) * 2004-04-22 2010-06-30 株式会社日立製作所 ストレージシステム及びファイル管理装置
US7266714B2 (en) * 2004-06-15 2007-09-04 Dolby Laboratories Licensing Corporation Method an apparatus for adjusting the time of a clock if it is determined that the degree of adjustment is within a limit based on the clocks initial time
US20060010301A1 (en) * 2004-07-06 2006-01-12 Hitachi, Ltd. Method and apparatus for file guard and file shredding
US20060036579A1 (en) * 2004-08-10 2006-02-16 Byrd Stephen A Apparatus, system, and method for associating resources using a time based algorithm
US8028135B1 (en) * 2004-09-01 2011-09-27 Netapp, Inc. Method and apparatus for maintaining compliant storage
JP2006072789A (ja) * 2004-09-03 2006-03-16 Hitachi Ltd ストレージシステム及びストレージシステムのデータ管理装置
US8914330B2 (en) * 2004-09-17 2014-12-16 International Business Machines Corporation Bulk deletion through segmented files
US7958093B2 (en) * 2004-09-17 2011-06-07 International Business Machines Corporation Optimizing a storage system to support short data lifetimes
JP2006127106A (ja) * 2004-10-28 2006-05-18 Hitachi Ltd ストレージシステム及びその制御方法
US7581118B2 (en) * 2004-12-14 2009-08-25 Netapp, Inc. Disk sanitization using encryption
US7774610B2 (en) * 2004-12-14 2010-08-10 Netapp, Inc. Method and apparatus for verifiably migrating WORM data
JP2006215954A (ja) * 2005-02-07 2006-08-17 Hitachi Ltd ストレージシステム及びストレージ装置のアーカイブ管理方法
JP4585330B2 (ja) * 2005-02-18 2010-11-24 株式会社日立製作所 ファイルシステム制御装置、ファイルシステム制御方法及びファイルシステム制御プログラムを含む記憶媒体
US7801863B2 (en) 2005-03-04 2010-09-21 Microsoft Corporation Method and computer-readable medium for formula-based document retention
US20060206484A1 (en) * 2005-03-14 2006-09-14 Hitachi, Ltd. Method for preserving consistency between worm file attributes and information in management servers
US20060218201A1 (en) * 2005-03-24 2006-09-28 International Business Machines Corporation System and method for effecting thorough disposition of records
US7685165B2 (en) * 2005-04-01 2010-03-23 International Business Machines Corporation Policy based resource management for legacy data
JP4566808B2 (ja) * 2005-04-21 2010-10-20 株式会社日立製作所 情報処理システム、ストレージシステム及び情報処理方法
US7962689B1 (en) 2005-04-29 2011-06-14 Netapp, Inc. System and method for performing transactional processing in a striped volume set
US8073899B2 (en) * 2005-04-29 2011-12-06 Netapp, Inc. System and method for proxying data access commands in a storage system cluster
US7904649B2 (en) 2005-04-29 2011-03-08 Netapp, Inc. System and method for restriping data across a plurality of volumes
US7698334B2 (en) * 2005-04-29 2010-04-13 Netapp, Inc. System and method for multi-tiered meta-data caching and distribution in a clustered computer environment
US7698501B1 (en) 2005-04-29 2010-04-13 Netapp, Inc. System and method for utilizing sparse data containers in a striped volume set
US7680830B1 (en) * 2005-05-31 2010-03-16 Symantec Operating Corporation System and method for policy-based data lifecycle management
GB2427048A (en) 2005-06-09 2006-12-13 Avecho Group Ltd Detection of unwanted code or data in electronic mail
US7653682B2 (en) * 2005-07-22 2010-01-26 Netapp, Inc. Client failure fencing mechanism for fencing network file system data in a host-cluster environment
US7558930B2 (en) * 2005-07-25 2009-07-07 Hitachi, Ltd. Write protection in a storage system allowing both file-level access and volume-level access
JP4766954B2 (ja) * 2005-08-22 2011-09-07 株式会社日立製作所 ストレージ装置、データ復旧方法及びデータアクセス方法
JP4699842B2 (ja) * 2005-09-06 2011-06-15 株式会社日立製作所 ストレージ装置及びデータ移動方法
US7487178B2 (en) * 2005-10-05 2009-02-03 International Business Machines Corporation System and method for providing an object to support data structures in worm storage
US8015222B2 (en) 2005-10-24 2011-09-06 Emc Corporation Virtual repository management
US8819048B1 (en) * 2005-10-24 2014-08-26 Emc Corporation Virtual repository management to provide retention management services
WO2007053356A2 (fr) 2005-10-28 2007-05-10 Network Appliance, Inc. Systeme et procede permettant d'optimiser le support multitrajets dans un environnement de systeme de stockage distribue
US7640279B2 (en) * 2005-11-30 2009-12-29 International Business Machines Corporation Apparatus and method for file-level replication between two or more non-symmetric storage sites
WO2007086844A2 (fr) * 2006-01-25 2007-08-02 Network Appliance, Inc. Procede et appareil pour appliquer automatiquement le statut worm a des fichiers
US7752401B2 (en) * 2006-01-25 2010-07-06 Netapp, Inc. Method and apparatus to automatically commit files to WORM status
US7734951B1 (en) 2006-03-20 2010-06-08 Netapp, Inc. System and method for data protection management in a logical namespace of a storage system environment
US9984080B2 (en) * 2006-08-01 2018-05-29 International Business Machines Corporation Efficient non-database file-expiration management for document retention
US7747584B1 (en) 2006-08-22 2010-06-29 Netapp, Inc. System and method for enabling de-duplication in a storage system architecture
US8489811B1 (en) 2006-12-29 2013-07-16 Netapp, Inc. System and method for addressing data containers using data set identifiers
US8301673B2 (en) * 2006-12-29 2012-10-30 Netapp, Inc. System and method for performing distributed consistency verification of a clustered file system
US8312046B1 (en) 2007-02-28 2012-11-13 Netapp, Inc. System and method for enabling a data container to appear in a plurality of locations in a super-namespace
US7552131B2 (en) 2007-03-05 2009-06-23 International Business Machines Corporation Autonomic retention classes
US7634630B1 (en) * 2007-03-26 2009-12-15 Emc Corporation Storing authentication information in a content unit on an object addressable storage system
US8219821B2 (en) 2007-03-27 2012-07-10 Netapp, Inc. System and method for signature based data container recognition
US8150800B2 (en) * 2007-03-28 2012-04-03 Netapp, Inc. Advanced clock synchronization technique
US8290899B2 (en) * 2007-03-28 2012-10-16 Netapp, Inc. Group stamping style asynchronous replication utilizing a loosely-accurate global clock
US8219749B2 (en) * 2007-04-27 2012-07-10 Netapp, Inc. System and method for efficient updates of sequential block storage
US7827350B1 (en) 2007-04-27 2010-11-02 Netapp, Inc. Method and system for promoting a snapshot in a distributed file system
US7882304B2 (en) * 2007-04-27 2011-02-01 Netapp, Inc. System and method for efficient updates of sequential block storage
US7702662B2 (en) * 2007-05-16 2010-04-20 International Business Machines Corporation Method and system for handling reallocated blocks in a file system
US7797489B1 (en) 2007-06-01 2010-09-14 Netapp, Inc. System and method for providing space availability notification in a distributed striped volume set
US8190834B2 (en) * 2007-06-15 2012-05-29 Emc Corporation Process for contiguously streaming data from a content addressed storage system
US8626741B2 (en) * 2007-06-15 2014-01-07 Emc Corporation Process for cataloging data objects backed up from a content addressed storage system
US8631235B2 (en) * 2007-08-08 2014-01-14 Oracle America, Inc. System and method for storing data using a virtual worm file system
US7958166B2 (en) * 2007-08-15 2011-06-07 Emc Corporation System and method for providing write-once-read-many (WORM) storage
US8146155B1 (en) * 2007-09-29 2012-03-27 Emc Corporation Controlling access to content on an object addressable storage system
US20090103723A1 (en) * 2007-10-19 2009-04-23 Sun Microsystems, Inc. System And Method For Secure Storage Of Data
US7996636B1 (en) 2007-11-06 2011-08-09 Netapp, Inc. Uniquely identifying block context signatures in a storage volume hierarchy
US9270540B2 (en) * 2007-12-17 2016-02-23 Verizon Patent And Licensing Inc. Method and apparatus of providing an interface for managing network switches
US7996607B1 (en) 2008-01-28 2011-08-09 Netapp, Inc. Distributing lookup operations in a striped storage system
US8055629B2 (en) * 2008-03-05 2011-11-08 International Business Machines Corporation Transitioning an archived file to write-once-read-many
JP5309206B2 (ja) * 2008-04-07 2013-10-09 トムソン ライセンシング コンテンツ頒布システムにおいてマルチメディア・コンテンツのロンダリングおよび再パッケージングを防止する方法
US8725986B1 (en) 2008-04-18 2014-05-13 Netapp, Inc. System and method for volume block number to disk block number mapping
US8099571B1 (en) 2008-08-06 2012-01-17 Netapp, Inc. Logical block replication with deduplication
US8707438B1 (en) * 2008-10-09 2014-04-22 Emc Corporation System and method for providing storage for electronic records
US8533478B2 (en) * 2008-10-24 2013-09-10 Hewlett-Packard Development Company, L. P. System for and method of writing and reading redundant data
US8788519B2 (en) * 2008-10-24 2014-07-22 John C. Canessa System and methods for metadata management in content addressable storage
US9043288B2 (en) * 2008-10-27 2015-05-26 Netapp, Inc. Dual-phase file system checker
US7974953B1 (en) * 2008-10-28 2011-07-05 Netapp, Inc. System and method for deletion of writeable PPIS
US8108557B2 (en) * 2009-01-22 2012-01-31 Hewlett-Packard Development Company, L.P. System and method for measuring clock skew on a network
WO2010122606A1 (fr) * 2009-04-24 2010-10-28 Hitachi, Ltd. Système de stockage et procédé de gestion de données de celui-ci
US9087066B2 (en) * 2009-04-24 2015-07-21 Swish Data Corporation Virtual disk from network shares and file servers
US9239840B1 (en) 2009-04-24 2016-01-19 Swish Data Corporation Backup media conversion via intelligent virtual appliance adapter
US8117388B2 (en) * 2009-04-30 2012-02-14 Netapp, Inc. Data distribution through capacity leveling in a striped file system
US8655848B1 (en) 2009-04-30 2014-02-18 Netapp, Inc. Unordered idempotent logical replication operations
US8321380B1 (en) 2009-04-30 2012-11-27 Netapp, Inc. Unordered idempotent replication operations
US20100318720A1 (en) * 2009-06-16 2010-12-16 Saranyan Rajagopalan Multi-Bank Non-Volatile Memory System with Satellite File System
JP2011022875A (ja) * 2009-07-17 2011-02-03 Sanyo Electric Co Ltd データアクセス装置
US9069884B2 (en) * 2009-09-08 2015-06-30 International Business Machines Corporation Processing special attributes within a file
US8743408B2 (en) * 2009-09-11 2014-06-03 Global Graphics Software Limited Selecting a binder file displayed on a GUI for storage of documents
US8990725B2 (en) * 2009-09-11 2015-03-24 Global Graphics Software Limited System and method for processes enabled by metadata associated with documents within a binder file
US20110066932A1 (en) * 2009-09-11 2011-03-17 Global Graphics Software Limited System and method for providing a representation of hierarchical structures of documents
US8671072B1 (en) 2009-09-14 2014-03-11 Netapp, Inc. System and method for hijacking inodes based on replication operations received in an arbitrary order
US8880826B2 (en) * 2009-10-20 2014-11-04 Dell Products, Lp System and method for write once read many (WORM) storage in an information handling system
US9369524B2 (en) * 2009-10-26 2016-06-14 Netapp, Inc. Simplified and unified management for network-attached storage
US8473690B1 (en) 2009-10-30 2013-06-25 Netapp, Inc. Using logical block addresses with generation numbers as data fingerprints to provide cache coherency
US8799367B1 (en) 2009-10-30 2014-08-05 Netapp, Inc. Using logical block addresses with generation numbers as data fingerprints for network deduplication
KR100979750B1 (ko) * 2009-11-06 2010-09-03 (주)피스페이스 분산 저장 시스템에서 파일을 관리하는 장치 및 방법
US9015333B2 (en) 2009-12-18 2015-04-21 Cisco Technology, Inc. Apparatus and methods for handling network file operations over a fibre channel network
TWI425375B (zh) * 2010-01-20 2014-02-01 Inventec Corp 伺服器檔案管理之方法
DE102010005172B4 (de) * 2010-01-20 2016-01-14 Siemens Aktiengesellschaft Verfahren zum Betreib eines Archivierungssystems für medizinische Bilddatensätze und Archivierungssystem
US8473773B2 (en) * 2010-02-05 2013-06-25 Netapp, Inc. Method and system to provide a compliance clock service suitable for cloud deployment
CN102193841B (zh) * 2010-03-04 2013-07-31 阿里巴巴集团控股有限公司 一种Subversion配置库的备份方法及装置
US8683152B2 (en) * 2010-03-10 2014-03-25 Netapp, Inc. Fast migration of virtual storage partition data across storage systems
US8631215B1 (en) * 2010-03-29 2014-01-14 Netapp, Inc. Provisioning different types of write once, read many states
US8281096B1 (en) * 2010-06-02 2012-10-02 Symantec Corporation Systems and methods for creating snapshots
US20120150925A1 (en) * 2010-12-10 2012-06-14 International Business Machines Corporation Proactive Method for Improved Reliability for Sustained Persistence of Immutable Files in Storage Clouds
US9971656B2 (en) 2010-12-13 2018-05-15 International Business Machines Corporation Instant data restoration
US9639540B2 (en) 2011-02-25 2017-05-02 Hewlett Packard Enterprise Development Lp Retention management in a worm storage system
US8849880B2 (en) * 2011-05-18 2014-09-30 Hewlett-Packard Development Company, L.P. Providing a shadow directory and virtual files to store metadata
US9584877B2 (en) * 2011-06-16 2017-02-28 Microsoft Technology Licensing, Llc Light-weight validation of native images
US20130091421A1 (en) 2011-10-11 2013-04-11 International Business Machines Corporation Time relevance within a soft copy document or media object
US9514154B2 (en) 2011-10-27 2016-12-06 International Business Machines Corporation Virtual file system interface for communicating changes of metadata in a data storage system
US8516022B1 (en) * 2012-01-11 2013-08-20 Emc Corporation Automatically committing files to be write-once-read-many in a file system
US10223506B2 (en) * 2012-04-04 2019-03-05 Rackspace Us, Inc. Self-destructing files in an object storage system
CN103684712B (zh) * 2012-09-14 2017-04-05 百度在线网络技术（北京）有限公司 文件快速恢复重传的方法、装置及网盘
US9424432B2 (en) * 2012-09-20 2016-08-23 Nasdaq, Inc. Systems and methods for secure and persistent retention of sensitive information
US20140082753A1 (en) * 2012-09-20 2014-03-20 Siar SARFERAZ Systems and methods for data privacy and destruction in multi-system landscapes
US20140222223A1 (en) * 2012-12-14 2014-08-07 Jaycen Horton Web-based irrigation controller
US9514150B2 (en) * 2013-04-19 2016-12-06 Hewlett Packard Enterprise Development Lp Automatic WORM-retention state transitions
US10078656B1 (en) * 2013-07-26 2018-09-18 Amazon Technologies, Inc. Unmodifiable data in a storage service
GB2520056A (en) 2013-11-08 2015-05-13 Ibm Digital data retention management
US20160292168A1 (en) * 2013-12-06 2016-10-06 Hewlett-Packard Development Company, L.P. File retention
US9015439B1 (en) * 2014-05-30 2015-04-21 SanDisk Technologies, Inc. Event lock storage device
US9400894B1 (en) * 2014-08-05 2016-07-26 Google Inc. Management of log files subject to edit restrictions that can undergo modifications
CN104332170B (zh) * 2014-08-26 2017-10-10 华为技术有限公司 一种存储设备和数据存储方法
US10223363B2 (en) * 2014-10-30 2019-03-05 Microsoft Technology Licensing, Llc Access control based on operation expiry data
WO2016195676A1 (fr) * 2015-06-03 2016-12-08 Hewlett Packard Enterprise Development Lp Conservation de données
US10257273B2 (en) 2015-07-31 2019-04-09 Netapp, Inc. Systems, methods and devices for RDMA read/write operations
US9952797B2 (en) 2015-07-31 2018-04-24 Netapp, Inc. Systems, methods and devices for addressing data blocks in mass storage filing systems
CN105205109A (zh) * 2015-08-27 2015-12-30 浪潮(北京)电子信息产业有限公司 一种文件管理方法、装置及系统
US10521401B2 (en) * 2015-08-28 2019-12-31 Netapp Inc. Data object lockdown
US10762041B2 (en) * 2015-08-31 2020-09-01 Netapp, Inc. Event based retention of read only files
US9715348B2 (en) 2015-09-09 2017-07-25 Netapp, Inc. Systems, methods and devices for block sharing across volumes in data storage systems
US20170091256A1 (en) * 2015-09-29 2017-03-30 Bank Of America Corporation Record Retention and Deletion
US10114844B2 (en) * 2015-11-30 2018-10-30 International Business Machines Corporation Readiness checker for content object movement
CN106024046B (zh) * 2016-05-24 2019-09-20 深圳市硅格半导体有限公司 数据存储方法及装置
US10082969B2 (en) * 2017-01-26 2018-09-25 Reduxio Systems Ltd. System and method for managing a storage system
US10275465B2 (en) * 2017-03-14 2019-04-30 Dell Products L.P. Method and system for scan-free detection of auto-committed files in a write-once-read-many storage devices
US10838828B2 (en) * 2017-07-25 2020-11-17 Hubstor Inc. Methods and systems relating to network based storage
US20180349269A1 (en) * 2017-06-06 2018-12-06 Microsoft Technology Licensing, Llc Event triggered data retention
CN107301018A (zh) * 2017-06-15 2017-10-27 郑州云海信息技术有限公司 一种在集群存储上的worm技术应用方法
US10860544B2 (en) * 2017-07-31 2020-12-08 Veritas Technologies Llc Systems and methods for write-once-read-many storage
US20190272538A1 (en) * 2018-03-01 2019-09-05 Matrics2, Inc. Using a nested random number-based security ecosystem for block chains for electronic cash tokens and other embodiments
WO2019177244A1 (fr) * 2018-03-14 2019-09-19 ㈜나무소프트 Système de fourniture de disque worm hybride
CN109492425B (zh) * 2018-09-30 2021-12-28 南京中铁信息工程有限公司 一种在分布式文件系统上的worm一写多读技术应用方法
US11356283B2 (en) * 2019-05-08 2022-06-07 Seagate Technology Llc Data storage using an encryption key with a time expiration associated therewith
CN111078276B (zh) * 2019-12-20 2022-12-30 抖音视界有限公司 应用程序的冗余资源处理方法、装置、设备及存储介质
US11593215B2 (en) * 2020-02-05 2023-02-28 EMC IP Holding Company LLC Method and system for generating immutable backups with configurable retention spans
KR102397047B1 (ko) * 2020-06-16 2022-05-17 서강대학교산학협력단 웜 스토리지의 신뢰성 강화 방법 및 신뢰성이 강화된 웜 스토리지
US11762806B2 (en) * 2020-10-15 2023-09-19 EMC IP Holding Company LLC Hardening system clock for retention lock compliance enabled systems
CN112667580A (zh) * 2021-01-04 2021-04-16 北京同有飞骥科技股份有限公司 一种在GPFS上的worm技术应用方法及系统
US11599296B2 (en) * 2021-07-30 2023-03-07 Netapp, Inc. Immutable snapshot copies stored in write once read many (WORM) storage
US11748299B2 (en) 2021-09-16 2023-09-05 Cohesity, Inc. Managing objects stored at a remote storage
US20230244633A1 (en) * 2022-01-31 2023-08-03 Cohesity, Inc. Extending an expiration time of an object associated with an archive
US20230273897A1 (en) * 2022-02-25 2023-08-31 Cohesity, Inc. Managing expiration times of archived objects

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832263A (en) 1996-03-15 1998-11-03 Digidox, Inc. System and method for in-place modification of information recorded in read-only storage using modifiable non-volatile storage associated with an agent
WO2002025445A2 (fr) 2000-09-19 2002-03-28 Kom, Inc. Procede et systeme de gestion du cycle de vie de fichiers electroniques

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4584643A (en) * 1983-08-31 1986-04-22 International Business Machines Corporation Decentralized synchronization of clocks
US4974156A (en) * 1988-05-05 1990-11-27 International Business Machines Multi-level peripheral data storage hierarchy with independent access to all levels of the hierarchy
EP0389399A3 (fr) 1989-03-20 1993-01-20 International Business Machines Corporation Structure de répertoire pour un support optique WORM
US5025396A (en) * 1989-03-21 1991-06-18 International Business Machines Corporation Method and apparatus for merging a digitized image with an alphanumeric character string
JP2945757B2 (ja) 1989-09-08 1999-09-06 オースペックス システムズ インコーポレイテッド 多重装置オペレーティングシステムのアーキテクチャ
US5163131A (en) 1989-09-08 1992-11-10 Auspex Systems, Inc. Parallel i/o network file server architecture
US5963962A (en) 1995-05-31 1999-10-05 Network Appliance, Inc. Write anywhere file-system layout
DE69431186T2 (de) 1993-06-03 2003-05-08 Network Appliance Inc Verfahren und Dateisystem zur Zuordnung von Datei-Blöcken zu Speicherplatz in einem RAID-Plattensystem
DK0702815T3 (da) 1993-06-03 2000-12-18 Network Appliance Inc Opsætning af et filsystem til skrivning på et hvilket som helst sted
US6604118B2 (en) 1998-07-31 2003-08-05 Network Appliance, Inc. File system image transfer
US5831859A (en) * 1993-08-20 1998-11-03 Base Ten Systems, Inc. Pharmaceutical recordkeeping system with labelling for manufacturing raw materials
US5835953A (en) 1994-10-13 1998-11-10 Vinca Corporation Backup system that takes a snapshot of the locations in a mass storage device that has been identified for updating prior to updating
US5548572A (en) * 1995-03-31 1996-08-20 International Business Machines Corporation Spare and calibration sector management for optical WORM media
US5813009A (en) * 1995-07-28 1998-09-22 Univirtual Corp. Computer based records management system method
US6298386B1 (en) 1996-08-14 2001-10-02 Emc Corporation Network file server having a message collector queue for connection and connectionless oriented protocols
US5941972A (en) 1997-12-31 1999-08-24 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US6185661B1 (en) * 1998-01-02 2001-02-06 Emc Corporation Worm magnetic storage device
US6457130B2 (en) 1998-03-03 2002-09-24 Network Appliance, Inc. File access control in a multi-protocol file server
US6574591B1 (en) 1998-07-31 2003-06-03 Network Appliance, Inc. File systems image transfer between dissimilar file systems
US6330571B1 (en) 1999-01-15 2001-12-11 International Business Machines Corporation Method and computer program product for implementing datalink path protection
US6496907B1 (en) * 1999-10-22 2002-12-17 Apple Computer, Inc. System and method for updating from a read-only to a read-write entry and concurrently invalidating stale cache copies from head-to-tail and tail-to-head directions
US6779080B2 (en) 2000-01-11 2004-08-17 International Business Machines Corporation Serial data storage system with automatically adjusted data protection to implement worm media with limited overwrite allowing write appending
US7072916B1 (en) 2000-08-18 2006-07-04 Network Appliance, Inc. Instant snapshot
US6823336B1 (en) 2000-09-26 2004-11-23 Emc Corporation Data storage system and method for uninterrupted read-only access to a consistent dataset by one host processor concurrent with read-write access by another host processor
US6606693B1 (en) 2001-09-25 2003-08-12 Alan Morris Method and system for long-term digital data storage
US6615330B2 (en) * 2001-12-27 2003-09-02 Storage Technology Corporation Virtual worm method and system
US6993539B2 (en) 2002-03-19 2006-01-31 Network Appliance, Inc. System and method for determining changes in two snapshots and for transmitting changes to destination snapshot
US7107385B2 (en) 2002-08-09 2006-09-12 Network Appliance, Inc. Storage virtualization by layering virtual disk objects on a file system
US7051053B2 (en) * 2002-09-30 2006-05-23 Dinesh Sinha Method of lazily replicating files and monitoring log in backup file system
US7155460B2 (en) * 2003-03-18 2006-12-26 Network Appliance, Inc. Write-once-read-many storage system and method for implementing the same
US7146388B2 (en) * 2003-10-07 2006-12-05 International Business Machines Corporation Method, system, and program for archiving files
US7590807B2 (en) 2003-11-03 2009-09-15 Netapp, Inc. System and method for record retention date in a write once read many storage system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832263A (en) 1996-03-15 1998-11-03 Digidox, Inc. System and method for in-place modification of information recorded in read-only storage using modifiable non-volatile storage associated with an agent
WO2002025445A2 (fr) 2000-09-19 2002-03-28 Kom, Inc. Procede et systeme de gestion du cycle de vie de fichiers electroniques

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1690166A4

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9575841B2 (en) 2009-01-23 2017-02-21 Nasuni Corporation Method and system for interfacing to cloud storage
WO2016085541A1 (fr) * 2014-11-28 2016-06-02 Nasuni Corporation Système de fichiers versionnés doté d'un verrou global
US10311153B2 (en) 2014-11-28 2019-06-04 Nasuni Corporation Versioned file system with global lock
US20210314403A1 (en) * 2015-07-07 2021-10-07 Nasuni Corporation Systems and methods for restoring an interface to a global file system
US11726967B2 (en) * 2015-07-07 2023-08-15 Nasuni Corporation Systems and methods for restoring an interface to a global file system

Also Published As

Publication number Publication date
WO2005045556A3 (fr) 2009-04-02
CN101443760A (zh) 2009-05-27
CA2544846C (fr) 2013-03-12
KR100984438B1 (ko) 2010-09-29
IL175445A0 (en) 2006-09-05
JP2007524954A (ja) 2007-08-30
US20070118687A1 (en) 2007-05-24
AU2004288444A1 (en) 2005-05-19
US7930493B1 (en) 2011-04-19
CN101443760B (zh) 2011-11-09
US20050097260A1 (en) 2005-05-05
CA2544846A1 (fr) 2005-05-19
AU2004288444B2 (en) 2010-04-22
IL175445A (en) 2010-12-30
US7366834B2 (en) 2008-04-29
EP1690166A2 (fr) 2006-08-16
KR20070051769A (ko) 2007-05-18
EP1690166A4 (fr) 2009-11-04
US7590807B2 (en) 2009-09-15

Similar Documents

Publication Publication Date Title
US7366834B2 (en) System and method for record retention date in a write once read many storage system
US8332362B2 (en) Write-once-read-many storage system and method for implementing the same
US10649954B2 (en) Selective extraction of information from a mirrored image file
US11880335B2 (en) Event based retention of read only files
Quinlan et al. Venti: A new approach to archival data storage
US7165079B1 (en) System and method for restoring a single data stream file from a snapshot
US7987197B2 (en) History preservation in a computer storage system
WO2006065361A1 (fr) Procede et dispositif pour la migration verifiable de donnees non reinscriptibles (worm)

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480039575.9

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2544846

Country of ref document: CA

Ref document number: 175445

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 2004288444

Country of ref document: AU

Ref document number: 2477/DELNP/2006

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2004818283

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2004818283

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006539450

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 2004288444

Country of ref document: AU

Date of ref document: 20040422

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1020067010879

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2004818283

Country of ref document: EP