US10049016B2 - Distributed garbage collection for the dedupe storage network - Google Patents
Distributed garbage collection for the dedupe storage network Download PDFInfo
- Publication number
- US10049016B2 US10049016B2 US14/818,260 US201514818260A US10049016B2 US 10049016 B2 US10049016 B2 US 10049016B2 US 201514818260 A US201514818260 A US 201514818260A US 10049016 B2 US10049016 B2 US 10049016B2
- Authority
- US
- United States
- Prior art keywords
- garbage collection
- garbage
- collection operation
- data
- backup
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active - Reinstated, expires
Links
- 239000010813 municipal solid waste Substances 0.000 title claims abstract description 109
- 238000003860 storage Methods 0.000 title abstract description 39
- 230000010076 replication Effects 0.000 claims abstract description 52
- 238000000034 method Methods 0.000 claims description 75
- 238000012217 deletion Methods 0.000 claims description 10
- 230000037430 deletion Effects 0.000 claims description 10
- 230000000977 initiatory effect Effects 0.000 claims description 7
- 230000003362 replicative effect Effects 0.000 claims description 7
- 238000004140 cleaning Methods 0.000 claims description 5
- 230000000694 effects Effects 0.000 abstract description 8
- 230000014759 maintenance of location Effects 0.000 abstract description 5
- 238000004891 communication Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000000746 purification Methods 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
- G06F12/0261—Garbage collection, i.e. reclamation of unreferenced memory using reference counting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
- G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
-
- 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/17—Details of further file system functions
- G06F16/174—Redundancy elimination performed by the file system
- G06F16/1748—De-duplication implemented within the file system, e.g. based on file segments
- G06F16/1752—De-duplication implemented within the file system, e.g. based on file segments based on file chunks
-
- 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/182—Distributed file systems
- G06F16/184—Distributed file systems implemented as replicated file system
-
- G06F17/30159—
-
- G06F17/30212—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
- G06F11/1453—Management of the data involved in backup or backup restore using de-duplication of the data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking
Definitions
- This application relates generally to data storage, and more specifically to a system, article of manufacture and method of methods and systems of a distributed garbage collection for the dedupe storage network.
- conflicts can arise when a garbage collection (GC) operation is running on a site while other sites in the dedupe storage network concurrently begins uploading data to said site.
- a conflict can also arise when the onsite starts downloading data from another site.
- the GC is in ‘data gathering’ state and a replication site is already uploading data.
- the replication site may not be able complete the data upload before GC changes its state to ‘data deletion’.
- GC can be in a ‘data gathering’ state and the onsite is already downloading data. Accordingly, it may not be able to complete the download before GC changes its state to ‘data deletion’.
- GC can list all the unique chunks from dedupe file system in Eraser DB, considering all of them as potential garbage chunks. Then the GC can iterate over all the valid backup images and filter out their data chunks from Eraser DB. This is how GC finds out list of garbage and orphan chunks from dedupe file system. In this case the ongoing uploads and downloads have created new data chunks but not the metadata for that dedupe image. Accordingly, the GC is in a ‘data gathering’ state and considers these partial uploaded or downloaded chunks as orphan chunks and deletes them from the system. To overcome this problem we changed the upload and download process.
- a replication site uploaded dedupe file system specific metadata after GC prepared its garbage chunk list in Eraser database (DB).
- DB Eraser database
- the replication site wants to upload a chunk which is also included in Eraser DB, then whether the upload happens first or chunk deletion by GC happens first can result into backup image corruption.
- the data download process relies on the locally available copy of data chunk for dedupe image creation. If the download process relying on a data chunk which is also part of Eraser DB, then garbage chunk deletion by GC will eventually make the downloaded image corrupt. Both these problems occur because GC state machine is transparent to upload and download processes. When GC in ‘data deletion’ state, backup process gives new life to data chunks by adding hardlink to the chunks. But since replication process is not aware of GC state machine it cannot give new life to garbage chunks.
- a computer-implemented method of handling garbage data chunks in a replication operation of a dedupe file system comprising the step of determining when the garbage collection operation is initiated.
- the method includes the step of recording the initiation time of the garbage collection.
- the method implements the following steps: acquiring, with the garbage collection operation, a write lock for the data chunk; determining that a hardlink count of data chunk; if the hardlink count is one (1), marking the data chunk as garbage data chunk; and moving, with the garbage collection operation, the garbage data chunk to a temporary trash directory.
- the method includes the step of deleting, with the garbage collection operation, the dedupe file system specific metadata of backup images, which are expired.
- the method includes the step of listing, with the garbage collection operation, one or more new backup images created as a result of a replication operation after the initiation time of garbage collection operation. For each such new backup image, the method reclaims the garbage collection operation, one or more data chunks included in a backup image that is a part of the temporary trash directory, and wherein the garbage collection operation recovers the one or more backup data chunks to the dedupe file system.
- the method includes the step of deleting, with the garbage collection operation, all the remaining data chunks present in the temporary trash directory.
- a computer-implemented method of a dedupe file system includes the step of replicating a dedupe file system specific metadata of a backup image.
- the method includes the step of replicating one or more data chunks of the backup image.
- the method includes the step of replicating the backup application specific metadata.
- the method includes the step of advertising to the backup application that the backup image is read ready.
- FIG. 1 illustrates an example process of determining which of the replicated chunks is to be designated as a garbage chunk after marking the backup image expired, according to some embodiments.
- FIGS. 2 A-B illustrates an example distributed GC process that implements a dedupe storage network, according to some embodiments.
- FIG. 3 illustrates an example process of dealing with an orphan chunk issue in upload and downloads.
- FIG. 4 illustrates an example process of implementing a solution to the garbage chunk issue in upload and download operations, according to some embodiments.
- FIG. 5 depicts an exemplary computing system that can be configured to perform any one of the processes provided herein.
- the following description is presented to enable a person of ordinary skill in the art to make and use the various embodiments. Descriptions of specific devices, techniques, and applications are provided only as examples. Various modifications to the examples described herein can be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the various embodiments.
- the schematic flow chart diagrams included herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, and they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
- Application server can be, inter alia, a software framework that provides a generalized approach to creating an application-server implementation, regard to what the application functions are and/or the server portion of a specific implementation instance.
- the server's function can be dedicated to the execution of procedures (e.g. programs, routines, scripts) for supporting its applied applications.
- An application server can be an example of a physical server.
- Associated owner site can be a site at which this backup image was originally created
- a backup or the process of backing up, can refer to the copying and/or archiving of computer data so it may be used to restore the original after a data loss event.
- Backup image can include copies of programs, system settings, files, etc. It can be a complete system backup that can be used for restore operations.
- Chunk (also a ‘data chunk’) can be the segments of data that are generated from a data stream by splitting the data stream at fixed or variable lengths.
- a chunk can be a specified fixed size or variable size.
- Cloud computing can be computing that can involve a large number of computers connected through a communication network such as the Internet. Cloud computing can be a form of distributed computing over a network, and can include the ability to run a program or application on many connected computers at the same time.
- Cloud storage can be a model of networked enterprise storage where data is stored in virtualized pools of storage which are generally hosted by third parties.
- Hosting companies can operate large data centers, and users can have data hosted by leasing storage capacity from said hosting companies. Physically, the resource can span across multiple servers and multiple locations.
- Onsite can mean that a dedupe storage node which initiates the replication upload/download.
- Replication site can be the dedupe storage node where data is pushed or fetched from. Replication can mean the uploading of the dedupe image to the replication partner.
- Dedupe storage network is represented in the form of a graph topology, where node represents dedupe storage node, and the directed edge represent the data replication path.
- dedupe storage network data is replicated in dedupe preserving manner. A data chunk which is present at a dedupe storage node is never replicated to that same storage node by any other storage node in the dedupe storage network.
- Local fs represents the dedupe data present locally on any dedupe storage node. It comprises of all the unique data chunks, the metadata representing dedupe images and the database which lists the unique data chunks present locally.
- Remote fs represents the dedupe data which has been replicated to a replication site by a dedupe storage node in the dedupe storage network. It comprises of the metadata representing the replicated dedupe images and the database which lists the unique data chunks replicated to replication site.
- Garbage collection (GC) design for a standalone site can operate on a state machine. Accordingly, GC can be optimized to make minimum possible impact on a backup window.
- a dedupe storage network for dedupe file system on any site apart from local backups, there can be many writers, in the form of many sites. These writers can be replicating their backup images.
- GC activity may be of relatively of less priority than other operations such as: dedupe data read, write, upload and download.
- GC's state machine may not impose any locking for data upload and download from and to, to any other sites in the dedupe storage network.
- the state of GC of any site can be completely transparent to all its peers performing data upload and download.
- GC can honor the data inflow in the form of uploads or downloads happening in the dedupe storage network and get rid of only garbage chunks from the dedupe file system. Accordingly, systems and methods are provided herein that can provide a distributed garbage collection for the dedupe storage network.
- FIG. 1 illustrates an example process 100 of determining which of the replicated chunks is to be designated as a garbage chunk after marking the backup image expired, according to some embodiments.
- each backup image can have an associated owner site.
- the owner site can controls the retention policy for the corresponding backup image.
- the owner site can expire the backup image from its local file system (fs) after the local retention period is over by marking it as expired.
- the garbage collector (GC) running on the owner site can clean up the garbage chunks related to this expired image.
- the owner site can also maintain a list of all other sites in the dedupe storage network.
- a backup image can be replicated during its respective retention period.
- the owner site marks the replicated image as expired in its own remote fs for the respective replication site.
- the owner site can mark a backup image as expired in the local fs of its replication peer sites.
- the owner site can maintain list of chunks which it has replicated to replication sites in its remote fs database. However, this database can be a subset of chunks present at the replications site. At the replication sites, there can be many more chunks present as a result of backups happening at that site and replications happening from other sites. Accordingly, in some examples, the owner site may not be able decide which chunks are garbage chunks at the replication site. In this case, the owner site may not be able to cleanup any chunks at replication site. However, the owner site can correct its own database of replicated chunks.
- the owner site can determine which of the replicated chunks is to be designated as a garbage chunk after marking the backup image expired and removes those chunks from its own remote fs database. Accordingly, the GC running on the replication sites has full knowledge of chunks present at that site and can clean up the garbage chunks.
- FIGS. 2 A-B illustrate an example distributed GC process 200 that implements a dedupe storage network, according to some embodiments.
- the distributed GC periodically wakes up and performs the garbage collection.
- process 200 performs steps 206 - 222 .
- process 200 lists all the expired replicated images.
- process 200 prepares the list of chunks included in these expired replicated images as Eraser database (DB). It is noted that all the chunks included in all expired replicated images are considered as garbage chunks initially.
- DB Eraser database
- process 200 filters out all the chunks included from the Eraser DB.
- step 214 at the end of step 212 , all the chunks present in the Eraser DB are determined to be garbage replicated chunks.
- process 200 can remove all the chunks included in the Eraser DB from the remote fs database for that replication site. This way the purification of local view of replication site's chunks list is done.
- process 200 can send the list of expired replicated images to replication site. The replication site in turn can mark these images as expired in its local fs.
- Process 200 can leave the actual chunk garbage collection task to the local GC running on that replication site.
- process 200 can clean up the metadata of expired replicated images from remote fs for that replication site.
- process 200 can then go to sleep as the cycle complete.
- FIG. 3 illustrates an example process 300 of dealing with an orphan chunk issue in upload and downloads.
- the metadata of backup image is split into two categories: dedupe file system specific and backup application specific.
- An example upload and download process is now provided.
- process 300 uploads/downloads dedupe file system specific metadata.
- uploads/downloads dedupe file system specific metadata can be a form of a replication operation.
- dedupe file system considers this as valid image.
- the user of this file system is backup application and since backup application specific metadata is not yet present, the application will never request the read for this image in transient phase.
- process 300 determines the upload/download data chunks of the required image.
- process 300 determines the upload/download backup application specific metadata. After this point it is advertised to the backup application that this image is read ready.
- FIG. 4 illustrates an example process 400 of implementing a solution to the garbage chunk issue in upload and download operations, according to some embodiments.
- step 402 when a GC wakes up from ‘dormant’ state, the GC notes down the current time (e.g. as ‘T 1 ’), as the initiation time of the garbage collection.
- step 404 when GC is in ‘data deletion’ state, for each of the garbage chunk, the GC acquires a ‘write lock’, and checks its hardlink count. If it is one (1) then an earlier GC was used to directly delete that chunk. Now rather than deleting the chunk, the GC moves such chunks to temporary ‘trash’ directory.
- step 406 rather than deleting GC can move the garbage chunks to trash folder.
- step 408 the GC cleans up metadata of the expired backup images.
- step 410 GC cleans up the chunks in the ‘trash’ directory. If chunk is present in the ‘trash’ directory, that means GC has cleaned up that chunk because it was garbage. GC recovers such required backup chunks to the dedupe file system.
- step 412 for each such image, the GC reclaims all of the chunks included in the image which are part of ‘trash’ directory.
- step 414 the GC cleans up the chunks in the ‘trash’ directory.
- Distributed GC can only inform the replication sites the list of expired replicated images and cleanup of replicated garbage chunks from its remote fs database for corresponding replication sites. But it cannot cleanup garbage chunks from replication sites. Garbage chunks can only be cleaned by the GC running on that site.
- GC can clean up the data chunks of images whose replication is in progress considering them as orphan chunks. This is solved by changing the data replication process as: replicate dedupe file system specific metadata first, then data, followed by backup application specific metadata.
- FIG. 5 depicts an exemplary computing system 500 that can be configured to perform any one of the processes provided herein.
- computing system 500 may include, for example, a processor, memory, storage, and I/O devices (e.g., monitor, keyboard, disk drive, Internet connection, etc.).
- computing system 500 may include circuitry or other specialized hardware for carrying out some or all aspects of the processes.
- computing system 500 may be configured as a system that includes one or more units, each of which is configured to carry out some aspects of the processes either in software, hardware, or some combination thereof.
- FIG. 5 depicts computing system 500 with a number of components that may be used to perform any of the processes described herein.
- the main system 502 includes a motherboard 504 having an I/O section 506 , one or more central processing units (CPU) 508 , and a memory section 510 , which may have a flash memory card 512 related to it.
- the I/O section 506 can be connected to a display 514 , a keyboard and/or other user input (not shown), a disk storage unit 516 , and a media drive unit 518 .
- the media drive unit 518 can read/write a computer-readable medium 520 , which can contain programs 522 and/or data.
- Computing system 500 can include a web browser.
- computing system 500 can be configured to include additional systems in order to fulfill various functionalities.
- Computing system 500 can communicate with other computing devices based on various computer communication protocols such a Wi-Fi, Bluetooth® (and/or other standards for exchanging data over short distances includes those using short-wavelength radio transmissions), USB, Ethernet, cellular, an ultrasonic dedupe area communication protocol, etc.
- the cloud-appliance can be configured to regularly backup the recovered system running on the cloud. Accordingly, multiple images corresponding to the system running on the cloud can be captured and stored by the cloud appliance. The cloud-appliance can detect the unique data chunks of these backup images and uploads these data chunks to the cloud storage. The cloud-appliance can integrate with the cloud infrastructure APIs to discover any other systems running in the cloud. The cloud-appliance can be configured to regularly backup these systems (e.g. are manually created in the cloud).
- the cloud-appliance can back up the system regularly.
- the system can upload unique data chunks to cloud storage.
- the user can power-on another on-site appliance and configure it to regularly download new unique data chunks from the cloud storage.
- the on-site appliance can restore this image.
- a difference between distributed GC and local GC can be as follows.
- a distributed GC on onsite can clean up the local view of replicated file system by cleaning up remote fs database and inform the remote site about the expired image. Then the remote site cleans up the replicated image from its local file system when the local GC runs.
- the various operations, processes, and methods disclosed herein can be embodied in a machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., a computer system), and can be performed in any order (e.g., including using means for achieving the various operations). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
- the machine-readable medium can be a non-transitory form of machine-readable medium.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims (3)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/818,260 US10049016B2 (en) | 2015-02-06 | 2015-08-04 | Distributed garbage collection for the dedupe storage network |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/615,434 US10621143B2 (en) | 2015-02-06 | 2015-02-06 | Methods and systems of a dedupe file-system garbage collection |
US14/701,530 US10324802B2 (en) | 2015-05-01 | 2015-05-01 | Methods and systems of a dedupe storage network for image management |
US14/818,260 US10049016B2 (en) | 2015-02-06 | 2015-08-04 | Distributed garbage collection for the dedupe storage network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/701,530 Continuation-In-Part US10324802B2 (en) | 2015-02-06 | 2015-05-01 | Methods and systems of a dedupe storage network for image management |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160232059A1 US20160232059A1 (en) | 2016-08-11 |
US10049016B2 true US10049016B2 (en) | 2018-08-14 |
Family
ID=56565422
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/818,260 Active - Reinstated 2035-11-22 US10049016B2 (en) | 2015-02-06 | 2015-08-04 | Distributed garbage collection for the dedupe storage network |
Country Status (1)
Country | Link |
---|---|
US (1) | US10049016B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110907070A (en) * | 2019-01-11 | 2020-03-24 | 黄永芹 | Environment-friendly big data monitoring terminal |
US11221785B2 (en) * | 2019-12-03 | 2022-01-11 | Western Digital Technologies, Inc. | Managing replication state for deleted objects |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105808674A (en) * | 2016-03-01 | 2016-07-27 | 北京金山安全软件有限公司 | Picture display method and device and electronic equipment |
US10706022B2 (en) | 2017-01-18 | 2020-07-07 | International Business Machines Corporation | Space-efficient secondary indexing on distributed data stores |
US11561714B1 (en) | 2017-07-05 | 2023-01-24 | Pure Storage, Inc. | Storage efficiency driven migration |
US11249901B2 (en) * | 2018-12-07 | 2022-02-15 | EMC IP Holding Company LLC | Ownership-based garbage collection of data |
US11048430B2 (en) | 2019-04-12 | 2021-06-29 | Netapp, Inc. | Object store mirroring where during resync of two storage bucket, objects are transmitted to each of the two storage bucket |
US11321007B2 (en) | 2020-07-29 | 2022-05-03 | International Business Machines Corporation | Deletion of volumes in data storage systems |
CN112835517B (en) * | 2021-01-22 | 2022-11-25 | 珠海妙存科技有限公司 | Method, device and medium for improving MLC NAND performance |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5202982A (en) * | 1990-03-27 | 1993-04-13 | Sun Microsystems, Inc. | Method and apparatus for the naming of database component files to avoid duplication of files |
US20120117029A1 (en) * | 2010-11-08 | 2012-05-10 | Stephen Gold | Backup policies for using different storage tiers |
US20130091102A1 (en) * | 2011-10-11 | 2013-04-11 | Netapp, Inc. | Deduplication aware scheduling of requests to access data blocks |
US20140149794A1 (en) * | 2011-12-07 | 2014-05-29 | Sachin Shetty | System and method of implementing an object storage infrastructure for cloud-based services |
US20160077926A1 (en) * | 2014-09-16 | 2016-03-17 | Actifio, Inc. | System and method for multi-hop data backup |
US20160188668A1 (en) * | 2014-12-27 | 2016-06-30 | Ascava, Inc. | Performing multidimensional search and content-associative retrieval on data that has been losslessly reduced using a prime data sieve |
-
2015
- 2015-08-04 US US14/818,260 patent/US10049016B2/en active Active - Reinstated
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5202982A (en) * | 1990-03-27 | 1993-04-13 | Sun Microsystems, Inc. | Method and apparatus for the naming of database component files to avoid duplication of files |
US20120117029A1 (en) * | 2010-11-08 | 2012-05-10 | Stephen Gold | Backup policies for using different storage tiers |
US20130091102A1 (en) * | 2011-10-11 | 2013-04-11 | Netapp, Inc. | Deduplication aware scheduling of requests to access data blocks |
US20140149794A1 (en) * | 2011-12-07 | 2014-05-29 | Sachin Shetty | System and method of implementing an object storage infrastructure for cloud-based services |
US20160077926A1 (en) * | 2014-09-16 | 2016-03-17 | Actifio, Inc. | System and method for multi-hop data backup |
US20160188668A1 (en) * | 2014-12-27 | 2016-06-30 | Ascava, Inc. | Performing multidimensional search and content-associative retrieval on data that has been losslessly reduced using a prime data sieve |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110907070A (en) * | 2019-01-11 | 2020-03-24 | 黄永芹 | Environment-friendly big data monitoring terminal |
US11221785B2 (en) * | 2019-12-03 | 2022-01-11 | Western Digital Technologies, Inc. | Managing replication state for deleted objects |
Also Published As
Publication number | Publication date |
---|---|
US20160232059A1 (en) | 2016-08-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10049016B2 (en) | Distributed garbage collection for the dedupe storage network | |
US10747719B2 (en) | File system point-in-time restore using recycle bin and version history | |
JP4996619B2 (en) | Method and program for operating a system comprising a backup server and a backup storage system | |
US10621143B2 (en) | Methods and systems of a dedupe file-system garbage collection | |
US8468387B2 (en) | Bare metal machine recovery | |
JP5924209B2 (en) | Backup control program, backup control method, and information processing apparatus | |
US9377964B2 (en) | Systems and methods for improving snapshot performance | |
US10289687B2 (en) | Space optimized snapshot for network backup | |
CN102360410B (en) | User operation discovery method of file system and synchronous system utilizing the same | |
US10324802B2 (en) | Methods and systems of a dedupe storage network for image management | |
EP3014512B1 (en) | Reverse replication to rollback corrupted files | |
AU2015362561B2 (en) | Techniques for data backup and restoration | |
JP5868986B2 (en) | Recovery by item | |
EP3535955B1 (en) | Systems, devices and methods for managing file system replication | |
US20090307276A1 (en) | Migration using file system links | |
US20100293143A1 (en) | Initialization of database for synchronization | |
US10514988B2 (en) | Method and system of migrating applications to a cloud-computing environment | |
US8266110B1 (en) | Integrated archival and backup | |
US20240160534A1 (en) | Snappable recovery chain over generic managed volume | |
Brunner | Enabling Efficient Storage of Git Repositories in PAClab | |
JP2009251764A (en) | Job management system, job control method, and job control program | |
Thomas | Instant PostgreSQL Backup and Restore How-to |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: SURELINE SYSTEMS, INC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DURGE, SACHIN BABAN;NAGARKAR, KULDEEP SURESHRAO;GOYAL, RAVENDER;AND OTHERS;REEL/FRAME:057855/0231 Effective date: 20210513 Owner name: PERSISTENT SYSTEMS INC.,, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SURELINE SYSTEMS, INC.;REEL/FRAME:057850/0139 Effective date: 20210519 |
|
AS | Assignment |
Owner name: HSBC BANK USA, NATIONAL ASSOCIATION, NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:PERSISTENT SYSTEMS INC.;SOFTWARE COMPANY INTERNATIONAL, LLC;REEL/FRAME:058095/0958 Effective date: 20211022 |
|
AS | Assignment |
Owner name: HSBC BANK USA, NATIONAL ASSOCIATION, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:PERSISTENT SYSTEMS INC.;REEL/FRAME:059132/0355 Effective date: 20220228 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
AS | Assignment |
Owner name: HSBC BANK USA, NATIONAL ASSOCIATION, NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:PERSISTENT SYSTEMS INC.;SOFTWARE COMPANY INTERNATIONAL, LLC, AS SUCCESSOR-BY-CONVERSION TO SOFTWARE CORPORATION INTERNATIONAL;REEL/FRAME:060218/0077 Effective date: 20220503 Owner name: HSBC BANK USA, NATIONAL ASSOCIATION, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:PERSISTENT SYSTEMS INC.;REEL/FRAME:060218/0123 Effective date: 20220503 |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20220814 |
|
PRDP | Patent reinstated due to the acceptance of a late maintenance fee |
Effective date: 20231030 |
|
FEPP | Fee payment procedure |
Free format text: PETITION RELATED TO MAINTENANCE FEES FILED (ORIGINAL EVENT CODE: PMFP); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: PETITION RELATED TO MAINTENANCE FEES GRANTED (ORIGINAL EVENT CODE: PMFG); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: SURCHARGE, PETITION TO ACCEPT PYMT AFTER EXP, UNINTENTIONAL (ORIGINAL EVENT CODE: M1558); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |