The present invention generally relates to adjusting the throttling of background processes at a high degree of precision.
Processes executing on a computer system will often require access to shared resources of the computer system, such as memory and the CPU, to meet quality of service (QoS) requirements and expectations. A process that executes in the background (a “background process”) may be required to execute on a regular basis. Typical examples of a background process include an anti-virus program and a backup program. However, the execution of background processes may have a negative impact to the quality of service of other processes due to conflicts with shared resources. For example, a background process that is taking a relatively large portion of the CPU's availability will result in other processes having less access to the CPU. Shared resources can become saturated by background process. When a process accesses a saturated resource, their access is delayed and the average response time increase, thereby causing the execution of the process, and the computer system as a whole, to slow down.
Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Approaches for dynamically adjusting a frequency at which the one or more background processes are executed at a high degree of precision are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Embodiments of the invention advantageously enable background processes to be dynamically throttled at a high degree of precision. As a result, the utilization of shared resources may be safely maintained at higher levels of utilization than by prior approaches. Before discussing how embodiments of the invention may be employed, it will be helpful to appreciate the differences between a background process and a foreground process. As used herein, a background process is a process designed to run in the background to perform a supportive function to a foreground process. A foreground process, as used herein, is a process that provides functionality central to the role of a device upon which the process executes. Foreground processes typically interact with a user and/or performs application level activity. Non-limiting, illustrative examples of functionality performed by a background process include making a backup copy of data and running an antivirus program. Non-limiting, illustrative examples of foreground processes include operating systems, database servers, text editors, and multimedia players.
It is observed that prior approaches for managing the execution of background processes exhibit many limitations and disadvantages. One approach for managing the executing rate of a background process according to known techniques is the “noop” approach. In the “noop” approach, both background processes and foreground processes are dispatched in the order in which they are received. A disadvantage with this technique is that it provides no protection against over saturation of a shared resource. For example, if a set of foreground processes are highly utilizing a shared resource, executing a high load of background processes may over saturate the shared resource and subsequently degrade performance of the foreground processes.
According to another prior art approach termed “static throttling,” the frequency at which background processes are dispatched to the CPU is either static or changes infrequently. For example, in the static throttling approach, a background process may be configured to have 1000 IO operations per second. Static throttling is problematic in that it virtually always under utilizes or over utilizes shared resources, as it is difficult to accurately predict how much foreground processes will utilize a shared resource.
Another approach for managing the execution rate of background processes is called “deadline.” In the “deadline” approach, an arbitrary deadline for when an IO is to occur is specified. For example, a process may be internally designated a one second deadline in which the IO operation requested by the process must occur. A scheduler may optimize the order in which IOs are issued as long as the performance of the IO operations still observers their assigned deadline. However, while the order in which IO operations are issued may change, the deadline approach is ineffective against addressing oversaturation of a shared resource, as the deadline approach does not consider how much or how little a shared resource is being used when reordering how IO operations are issued.
Another prior art approach for managing the execution rate of a background process is termed “CFQ,” which stands for Completely Fair Queue. In the CFQ approach, when either a background process or a foreground process desires access to the CPU, each process is assigned to one of a group of queues. Each queue is provided a certain amount of access to the CPU. When it is a particular's queue's turn to access the CPU, the process at the end of that queue is granted access to the CPU. In this way, all processes are provided access to the CPU, but certain higher-priority processes may be provided greater access to the CPU (by virtue of being assigned to a faster moving queue) than other lower-priority processes. However, the CFQ approach is also ineffective against addressing oversaturation of a shared resource, as the CFQ approach does not consider how much or how little a shared resource is being used when assigning processes to queues or determining how frequently IO operations should occur.
In step 210 of
Embodiments of the invention may be used to monitor a wide-variety of shared resources. Non-limiting, illustrative examples of shared resources which may be monitored in step 210 include one or more central processing units (CPUs), memory, persistent storage, and access to a network resource.
In an embodiment, step 210 may be performed by accessing a statistics information file implemented by an operating system. To illustrate a concrete example, the Linux operating system supports the file “/proc/diskstats,” which is a file that provides statistical information about resources of the computer system running the operating system. The “/proc/diskstats” file is updated with current statistical information about a wide variety of shared resources within a computer system each time the file is accessed. Internally, a function may be called to retrieve the statistical information when the file is read, and so this data is only retrieved as needed and is guaranteed to be current.
Step 210 may be performed frequently by embodiments to ensure that decisions regarding whether to increase or decrease the amount of IO operations issued by background processes are based on accurate data. For example, in one embodiment, step 210 may be performed at least five hundred times each second. In another embodiment, step 210 may be performed at least one thousand times each second. Other embodiments may perform step 210 in the range of one thousand to three thousand times per second. The particular frequency at which step 210 is performed will depend upon the characteristics of the computer system.
To provide a different perspective about how frequently step 210 may be performed by embodiments, in an embodiment, step 210 may be performed at least ten times as often as step 220 is performed. In another embodiment, step 210 may be performed at least one hundred times as often as step 220 is performed.
In step 220, the frequency at which one or more background processes are executed is adjusted without adjusting the frequency in which one or more foreground processes are executed. The purpose of step 220 is to ensure that the utilization of the shared resource is a great as possible without exceeding a threshold value. In certain embodiments, the threshold value may be less than 100% utilization, such as a value between 80-90% or 80-95% (e.g., 90% utilization), to provide some leeway room to ensure the load upon a shared resource is less than 100% of the capacity of the shared resource.
In an embodiment, step 220 is performed frequency to ensure that the utilization of the shared resources is optimized. In this way, the rate of which background resources access a shared resource may be quickly adjusted to ensure that any foreground process has priority to access the shared resource, but any excess capacity of the shared resource is used by background processes. As a result, step 220 may be performed many times each second. For example, to illustrate one example, step 220 may be performed at least eight times a second by one embodiment. Other embodiments may perform step 220 any number from eight to twenty times a second. Other embodiments may perform step 220 fifty or more times a second.
In an embodiment, the frequent adjustment to frequency at which one or more background processes are executed enables shared resources to be better utilized without causing the shared resources to be over utilized. To illustrate this point, consider
In an embodiment of the invention, an additional threshold (the “ceiling threshold”) may be established and used. When, in performing step 210, if the shared resource is being utilized greater than the ceiling threshold, then the threshold value used in step 210 may be automatically decreased, without human intervention, so that the shared resource does not exceed 100% utilization. The use of a ceiling threshold may be helpful in those embodiments where there is a lag time between when the threshold value is adjusted and when an impact upon the utilization of the shared resource is felt. If there is a delay in the impact upon the utilization of the shared resource when the threshold is updated, then using a ceiling threshold may be advantages to ensure the utilization of the shared resource stays below 100%.
For example, assume that the threshold value in step 210 is set at 88%. Further assume that the ceiling threshold is set at 95%. If the utilization of the shared resource is determined to exceed the ceiling threshold of 95%, then the threshold value of 88% may be dynamically lowered to ensure that the shared resource does not exceed 100% utilization, which would result in foreground processes having their quality of services diminished.
Computer system will employ many different shared resources and it is contemplated that embodiments may be used with many different numbers and types of shared resources. Further, each shared resource of an embodiment may have a different threshold. Consequently, the threshold associated with one shared resource may be completely independent from the threshold associated with a different resource. For example, persistent storage volume A may correspond to a hard-disk drive and have a threshold of 85% utilization, while persistent storage volume B may correspond to a different hard-disk drive or a solid state device and may have a threshold of 90%.
Note that certain embodiments may expose an interface wherein a user may update or configure the threshold value of a shared resource. In other embodiments, the threshold value of a shared resource may be programmatically determined or updated based upon heuristics and analysis. Such heuristics and analysis may be performed upon data about the shared resources retrieved in step 210.
To illustrate how an embodiment may be used with reference to a shared network resource, assume that two servers, denoted server A and server B, communicate with each over a one gigabyte network link. Further assume that server B becomes inoperable and, at a later point in time, comes back online. Sever A and server B each contained four databases, and the contents of the four databases on server B mirrored the contents of the four databases on server A. When server B comes back online, a recovery process will be initiated for each of the four databases on server B. Data will be copied from server A to server B to synchronize the contents of the four database on server B with the contents of the four databases on server A.
If only one instance of a database were undergoing recovery, then perhaps it could fully utilize the capacity of the communications link. However, traffic related to the recovery process is not the only type of communications carried over the communications link. Since server A and server B are in a cluster, membership communications or heartbeats are also exchanged over the communications link. If a member of the cluster fails to receive a heartbeat from a particular member of the cluster, the member may conclude that the particular member for whom a heartbeat message hasn't been received has gone down, which may be an erroneous conclusion. Thus, the recovery process for each instance needs to be aware that other processes wish to use the communications link. If each recovery process were to be allowed to fully utilize the communications link, the utilization of the communications link may effectively be over 100%, which would negatively impact foreground processes, such as heartbeat messages. Embodiments described herein present a solution by allowing background processes, such as a recovery process, to use only the excess utilization of a shared resource not used by foreground processes.
Embodiments of the invention may be implemented in a variety of different environments and programming entities. For example, embodiments may be implemented in an application or application operating environment.
Embodiments of the invention may be used to perform certain background processes, such as a backup process, more efficiently than prior approaches. In an embodiment of the invention wherein the background process is coping data, such as when a backup of a database or other data store is made, in addition to performing steps 210 and 220 of
Utilization of persistent storage will increase with block size. However, as shown in
Thus, in an embodiment, after performing step 210, alternatively or in addition to performing step 220, the block size of data copied by a background process is dynamically adjusted based upon the utilization for a shared resource, such as a communications link.
In an embodiment, embodiments of the invention may be implemented on or using a computer system.
Computer system 500 may be coupled to a display 512, such as a cathode ray tube (CRT), a LCD monitor, and a television set, for displaying information to a user. An input device 514, including alphanumeric and other keys, is coupled to computer system 500 for communicating information and command selections to processor 504. Other non-limiting, illustrative examples of input device 514 include a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512. While only one input device 514 is depicted in
Embodiments of the invention are related to the use of computer system 500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another machine-readable medium, such as storage device 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement embodiments of the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “machine-readable storage medium” as used herein refers to any medium that participates in storing instructions which may be provided to processor 504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 510. Volatile media includes dynamic memory, such as main memory 506.
Non-limiting, illustrative examples of machine-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
Various forms of machine readable media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a network link 520 to computer system 500.
Communication interface 518 provides a two-way data communication coupling to a network link 520 that is connected to a local network. For example, communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 520 typically provides data communication through one or more networks to other data devices. For example, network link 520 may provide a connection through a local network to a host computer or to data equipment operated by an Internet Service Provider (ISP).
Computer system 500 can send messages and receive data, including program code, through the network(s), network link 520 and communication interface 518. For example, a server might transmit a requested code for an application program through the Internet, a local ISP, a local network, subsequently to communication interface 518. The received code may be executed by processor 504 as it is received, and/or stored in storage device 510, or other non-volatile storage for later execution.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Number | Name | Date | Kind |
---|---|---|---|
4916605 | Beardsley et al. | Apr 1990 | A |
5046002 | Takashi et al. | Sep 1991 | A |
5057996 | Cutler et al. | Oct 1991 | A |
5117350 | Parrish et al. | May 1992 | A |
5212789 | Rago | May 1993 | A |
5287496 | Chen et al. | Feb 1994 | A |
5297258 | Hale et al. | Mar 1994 | A |
5394555 | Hunter et al. | Feb 1995 | A |
5403639 | Belsan et al. | Apr 1995 | A |
5423037 | Hvasshovd | Jun 1995 | A |
5509134 | Fandrich et al. | Apr 1996 | A |
5537534 | Voigt et al. | Jul 1996 | A |
5603001 | Sukegawa et al. | Feb 1997 | A |
5611057 | Pecone et al. | Mar 1997 | A |
5613071 | Rankin et al. | Mar 1997 | A |
5680579 | Young et al. | Oct 1997 | A |
5692149 | Lee | Nov 1997 | A |
5701480 | Raz | Dec 1997 | A |
5742787 | Talreja | Apr 1998 | A |
5887138 | Hagersten et al. | Mar 1999 | A |
5897661 | Baranovsky et al. | Apr 1999 | A |
5897664 | Nesheim et al. | Apr 1999 | A |
5960436 | Chang et al. | Sep 1999 | A |
5963983 | Sakakura et al. | Oct 1999 | A |
6000006 | Bruce et al. | Dec 1999 | A |
6023745 | Lu | Feb 2000 | A |
6052815 | Zook | Apr 2000 | A |
6130759 | Blair | Oct 2000 | A |
6141692 | Loewenstein et al. | Oct 2000 | A |
6151688 | Wipfel et al. | Nov 2000 | A |
6216126 | Ronstrom | Apr 2001 | B1 |
6298390 | Matena et al. | Oct 2001 | B1 |
6308169 | Ronstrom et al. | Oct 2001 | B1 |
6434144 | Romanov | Aug 2002 | B1 |
6467060 | Malakapalli et al. | Oct 2002 | B1 |
6615313 | Kato et al. | Sep 2003 | B2 |
6658526 | Nguyen et al. | Dec 2003 | B2 |
6704835 | Garner | Mar 2004 | B1 |
6728826 | Kaki et al. | Apr 2004 | B2 |
6745209 | Holenstein et al. | Jun 2004 | B2 |
6804766 | Noel et al. | Oct 2004 | B1 |
6874044 | Chou et al. | Mar 2005 | B1 |
6938084 | Gamache et al. | Aug 2005 | B2 |
6944699 | Bugnion et al. | Sep 2005 | B1 |
6981070 | Luk et al. | Dec 2005 | B1 |
7003586 | Bailey et al. | Feb 2006 | B1 |
7010521 | Hinshaw et al. | Mar 2006 | B2 |
7043621 | Merchant et al. | May 2006 | B2 |
7082481 | Lambrache et al. | Jul 2006 | B2 |
7162467 | Eshleman et al. | Jan 2007 | B2 |
7200718 | Duzett | Apr 2007 | B2 |
7203890 | Normoyle | Apr 2007 | B1 |
7249280 | Lamport et al. | Jul 2007 | B2 |
7251749 | Fong et al. | Jul 2007 | B1 |
7269708 | Ware | Sep 2007 | B2 |
7269755 | Moshayedi et al. | Sep 2007 | B2 |
7272605 | Hinshaw et al. | Sep 2007 | B1 |
7272654 | Brendel | Sep 2007 | B1 |
7281160 | Stewart | Oct 2007 | B2 |
7305386 | Hinshaw et al. | Dec 2007 | B2 |
7334154 | Lorch et al. | Feb 2008 | B2 |
7359927 | Cardente | Apr 2008 | B1 |
7383290 | Mehra et al. | Jun 2008 | B2 |
7406487 | Gupta et al. | Jul 2008 | B1 |
7415488 | Muth et al. | Aug 2008 | B1 |
7417992 | Krishnan | Aug 2008 | B2 |
7436771 | Roberts et al. | Oct 2008 | B2 |
7467265 | Tawri et al. | Dec 2008 | B1 |
7529882 | Wong | May 2009 | B2 |
7542968 | Yokomizo et al. | Jun 2009 | B2 |
7562162 | Kreiner et al. | Jul 2009 | B2 |
7584222 | Georgiev | Sep 2009 | B1 |
7610445 | Manus et al. | Oct 2009 | B1 |
7623494 | Zhu et al. | Nov 2009 | B2 |
7627618 | Honigfort | Dec 2009 | B2 |
7647449 | Roy et al. | Jan 2010 | B1 |
7657710 | Loewenstein | Feb 2010 | B2 |
7809691 | Karmarkar et al. | Oct 2010 | B1 |
7822711 | Ranade | Oct 2010 | B1 |
7885923 | Tawri et al. | Feb 2011 | B1 |
7917472 | Persson | Mar 2011 | B2 |
8015352 | Zhang et al. | Sep 2011 | B2 |
8018729 | Skinner | Sep 2011 | B2 |
8024515 | Auerbach et al. | Sep 2011 | B2 |
8037349 | Mandagere et al. | Oct 2011 | B2 |
8069328 | Pyeon | Nov 2011 | B2 |
8099391 | Monckton | Jan 2012 | B1 |
8103643 | Danilov et al. | Jan 2012 | B2 |
8161248 | Blumrich et al. | Apr 2012 | B2 |
8205206 | Ozer et al. | Jun 2012 | B2 |
8225053 | McCorkendale et al. | Jul 2012 | B1 |
8239617 | Linnell | Aug 2012 | B1 |
8261266 | Pike et al. | Sep 2012 | B2 |
8261289 | Kasravi et al. | Sep 2012 | B2 |
8321450 | Thatte et al. | Nov 2012 | B2 |
8335776 | Gokhale | Dec 2012 | B2 |
8356306 | Herington | Jan 2013 | B2 |
8370853 | Giampaolo et al. | Feb 2013 | B2 |
8401994 | Hoang et al. | Mar 2013 | B2 |
8504526 | Gokhale et al. | Aug 2013 | B2 |
8666939 | O'Krafka et al. | Mar 2014 | B2 |
8671074 | Wang et al. | Mar 2014 | B2 |
8683480 | Bachar et al. | Mar 2014 | B2 |
20010032253 | Duxbury | Oct 2001 | A1 |
20020089933 | Giroux et al. | Jul 2002 | A1 |
20020129192 | Spiegel et al. | Sep 2002 | A1 |
20020166031 | Chen et al. | Nov 2002 | A1 |
20020184239 | Mosher, Jr. et al. | Dec 2002 | A1 |
20030016596 | Chiquoine et al. | Jan 2003 | A1 |
20030097610 | Hofner | May 2003 | A1 |
20030177408 | Fields et al. | Sep 2003 | A1 |
20030220985 | Kawamoto et al. | Nov 2003 | A1 |
20040010502 | Bomfim et al. | Jan 2004 | A1 |
20040078379 | Hinshaw et al. | Apr 2004 | A1 |
20040143562 | Chen et al. | Jul 2004 | A1 |
20040148283 | Harris et al. | Jul 2004 | A1 |
20040172494 | Pettey et al. | Sep 2004 | A1 |
20040172577 | Tan et al. | Sep 2004 | A1 |
20040205151 | Sprigg et al. | Oct 2004 | A1 |
20040230862 | Merchant et al. | Nov 2004 | A1 |
20040267835 | Zwilling et al. | Dec 2004 | A1 |
20050005074 | Landin et al. | Jan 2005 | A1 |
20050021565 | Kapoor et al. | Jan 2005 | A1 |
20050027701 | Zane et al. | Feb 2005 | A1 |
20050028134 | Zane et al. | Feb 2005 | A1 |
20050034048 | Nemawarkar et al. | Feb 2005 | A1 |
20050081091 | Bartfai et al. | Apr 2005 | A1 |
20050086413 | Lee et al. | Apr 2005 | A1 |
20050120133 | Slack-Smith | Jun 2005 | A1 |
20050131964 | Saxena | Jun 2005 | A1 |
20050240635 | Kapoor et al. | Oct 2005 | A1 |
20050246487 | Ergan et al. | Nov 2005 | A1 |
20060059428 | Humphries et al. | Mar 2006 | A1 |
20060064549 | Wintergerst | Mar 2006 | A1 |
20060085594 | Roberson et al. | Apr 2006 | A1 |
20060123200 | Ito et al. | Jun 2006 | A1 |
20060130063 | Kilian et al. | Jun 2006 | A1 |
20060161530 | Biswal et al. | Jul 2006 | A1 |
20060174063 | Soules et al. | Aug 2006 | A1 |
20060174069 | Shaw et al. | Aug 2006 | A1 |
20060179083 | Kulkarni et al. | Aug 2006 | A1 |
20060195648 | Chandrasekaran et al. | Aug 2006 | A1 |
20060212795 | Cottrille et al. | Sep 2006 | A1 |
20060218210 | Sarma et al. | Sep 2006 | A1 |
20060242163 | Miller et al. | Oct 2006 | A1 |
20060253724 | Zhang | Nov 2006 | A1 |
20070038794 | Purcell et al. | Feb 2007 | A1 |
20070043790 | Kryger | Feb 2007 | A1 |
20070043860 | Pabari | Feb 2007 | A1 |
20070073896 | Rothman et al. | Mar 2007 | A1 |
20070143368 | Lundsgaard et al. | Jun 2007 | A1 |
20070156842 | Vermuelen et al. | Jul 2007 | A1 |
20070174541 | Chandrasekaran et al. | Jul 2007 | A1 |
20070234182 | Wickeraad et al. | Oct 2007 | A1 |
20070276784 | Piedmonte | Nov 2007 | A1 |
20070283079 | Iwamura et al. | Dec 2007 | A1 |
20070288692 | Bruce et al. | Dec 2007 | A1 |
20070288792 | Thorpe et al. | Dec 2007 | A1 |
20070294564 | Reddin et al. | Dec 2007 | A1 |
20070299816 | Arora et al. | Dec 2007 | A1 |
20080016300 | Yim et al. | Jan 2008 | A1 |
20080034076 | Ishikawa et al. | Feb 2008 | A1 |
20080034174 | Traister et al. | Feb 2008 | A1 |
20080034249 | Husain et al. | Feb 2008 | A1 |
20080046538 | Susarla et al. | Feb 2008 | A1 |
20080046638 | Maheshwari et al. | Feb 2008 | A1 |
20080126706 | Newport et al. | May 2008 | A1 |
20080172402 | Birdwell et al. | Jul 2008 | A1 |
20080256103 | Fachan et al. | Oct 2008 | A1 |
20080288713 | Lee et al. | Nov 2008 | A1 |
20080288819 | Heller, Jr. | Nov 2008 | A1 |
20080295105 | Ozer et al. | Nov 2008 | A1 |
20080301256 | McWilliams | Dec 2008 | A1 |
20090006500 | Shiozawa et al. | Jan 2009 | A1 |
20090006681 | Hubert et al. | Jan 2009 | A1 |
20090006888 | Bernhard et al. | Jan 2009 | A1 |
20090019456 | Saxena et al. | Jan 2009 | A1 |
20090024871 | Emaru et al. | Jan 2009 | A1 |
20090030943 | Kall | Jan 2009 | A1 |
20090059539 | Ryu et al. | Mar 2009 | A1 |
20090070530 | Satoyama et al. | Mar 2009 | A1 |
20090150599 | Bennett | Jun 2009 | A1 |
20090177666 | Kaneda | Jul 2009 | A1 |
20090198791 | Menghnani | Aug 2009 | A1 |
20090240664 | Dinker et al. | Sep 2009 | A1 |
20090240869 | O'Krafka et al. | Sep 2009 | A1 |
20090327751 | Koifman et al. | Dec 2009 | A1 |
20100058021 | Kawamura | Mar 2010 | A1 |
20100080057 | Reuter et al. | Apr 2010 | A1 |
20100107017 | Munjal et al. | Apr 2010 | A1 |
20100125695 | Wu et al. | May 2010 | A1 |
20100241895 | Li et al. | Sep 2010 | A1 |
20100262762 | Borchers et al. | Oct 2010 | A1 |
20100299490 | Attarde et al. | Nov 2010 | A1 |
20100306448 | Chen et al. | Dec 2010 | A1 |
20100318821 | Kwan et al. | Dec 2010 | A1 |
20100325498 | Nagadomi | Dec 2010 | A1 |
20110022566 | Beaverson et al. | Jan 2011 | A1 |
20110072206 | Ross et al. | Mar 2011 | A1 |
20110082965 | Koka et al. | Apr 2011 | A1 |
20110082985 | Haines et al. | Apr 2011 | A1 |
20110099420 | MacDonald McAlister | Apr 2011 | A1 |
20110167038 | Wang et al. | Jul 2011 | A1 |
20110179279 | Greevenbosch et al. | Jul 2011 | A1 |
20110185147 | Hatfield et al. | Jul 2011 | A1 |
20110191299 | Huynh Huu et al. | Aug 2011 | A1 |
20110225214 | Guo | Sep 2011 | A1 |
20120005154 | George et al. | Jan 2012 | A1 |
20120072449 | Patch et al. | Mar 2012 | A1 |
20130066948 | Colrain et al. | Mar 2013 | A1 |
20130198478 | Bitner | Aug 2013 | A1 |
Number | Date | Country |
---|---|---|
1548600 | Jan 2007 | EP |
1746510 | Jan 2007 | EP |
Entry |
---|
Unknown Author, Supermicro—Intel Itanium Processor 9300 Series Based Server Systems. www.supermicro.com/products/nfo/itanium.cfm, Jul. 8, 2010. |
Ajmani, Automatic Software Upgrades for Distributed Systems, MIT, Sep. 2004, 164 pgs. |
Amza, Data Replication Strategies for Fault Tolerance and Availability on Commodity Clusters, 2000, 9 pgs. |
Mukherjee et al., Verification of an Industrial CC-NUMA server, Proceedings of ASP-DAC 2002, 7th Asia and South Pacifric and the 15th International Conference on VLSI Design, Jan. 7-11, 2002, 6 pages. |
Shacham et al., Verificaiton of chip multiprocessor memory systems using a relaxed scoreboard, Microarchitecture, 2008, MICRO-41, 2008, 41st IEEE/ACM International Symposium, Nov. 8-12, 2008, 12 pages. |
Walker, Hash Table Tutorial, Oct. 13, 2007, 14 pgs. |
bsn-modulestore, Versioning Concept, Oct. 13, 2010, 2 pgs. |
Btrfs, http://en.wikipedia.org, Oct. 3, 2011, 9 pgs. |
Buchholz, The Structure of the Reiser File System, Jan. 26, 2006, 21 pgs. |
Chacon, Git, The Fast Version Control System, Oct. 3, 2011, 3 pgs. |
Email Communication from James Bodwin to Christopher Brokaw re prior art, Sep. 13, 2011, 4 pgs. |
Git (Software), http://en.wikipedia.org, Oct. 3, 2011, 10 pgs. |
Hitz, File System Design for an NFS File Server Appliance, Jan. 19, 1994, 23 pgs. |
McDonald, Architectural Semantics for Practical Transactional Memory, Jun. 2006, 12 pgs. |
McGonigle, A Short History of btrfs, Aug. 14, 2009, 11 pgs. |
Mellor, ZFS—the future of file systems? Aug. 14, 2006, 5 pgs. |
Mercurial, http://en.wikipedia.org; Oct. 2, 2011, 6 pages. |
Module: Mongoid: Versioning, http://rdoc.info, Documentation by YARD 0.7.2, 6 pages Oct. 3, 2011. |
Noach, Database Schema under Version Control, code.openarck.org, Apr. 22, 2010, 6 pages. |
Reiser FS, http://enwikipedia.org, Sep. 17, 2011, 5 pgs. |
Rice, Extension Versioning, Update and Compatibility, Aug. 9, 2011, 11 pgs. |
Rice, Toolkit Version Format, Aug. 19, 2011, 4 pgs. |
Russell, Track and Record Database Schema Versions, Jun. 28, 2005, 8 pgs. |
Schooner Information Technology, IPAF, PCT/US2008/065167, Oct. 23, 2008, 7 pgs. |
Schooner Information Technology, ISR/WO, PCT/US2008/065167, Jan. 28, 2009, 16 pgs. |
SQL Server Database Schema Versioning and Update, Dec. 2, 2009, 2 pgs. |
Sufficiently Advanced Bug, File Versioning, Caching and Hashing, Oct. 3, 2011, 3 pgs. |
The Z File System (ZFS), FreeBSD Handbook, Oct. 3, 2011, 8 pgs (Author not provided). |
Tux3 Linux Filesystem Project, 2008, 1 pg. |
Tux3 Versioning Filesystem, Jul. 2008, 67 pgs. |
Tux3, http://en.wikipedia.org, Jun. 2, 2010, 3 pgs. |
Vijaykumar, Speculative Versioning Cache, Dec. 1, 2001, 13 pgs. |
WAFL—Write Anywhere File Layout, 1999, 1 pg. |
Write Anywhere File Layout, Sep. 9, 2011, 2 pgs. |
ZFS, , http://en.wikipedia.org Sep. 30, 2011, 18 pgs. |
Chockler, Active Disk Paxos with infinitely many processes, Springer-Verlag, Apr. 2005, 12 pgs. |
Dwork, Concensus in the presence of partial synchrony, MIT, 1988, 6 pgs. |
Guerraoui, A Leader Election Protocol for Eventually Synchronous Shared Memory Systems, IEEE, 2006, 6 pgs. |
Lamport, Cheap Paxos, Microsoft, 2004, 9 pgs. |
Lamport, Fast Paxos, Microsoft, Jul. 2005, 43 pgs. |
Lamport, Generalized Consensus and Paxos, Microsoft, Mar. 2004, 25 pgs. |
Lamport, Paxos Made Simple, Nov. 2001, 14 pgs. |
Malkhi, Lecture notes in computer science [Section: Omega Meets Paxos, Leader election and stability without eventual timely links], 2005, pp. 199-213. |
Pease, Reaching Agreement in the Presence of Faults, ACM, 1980, pp. 228-234. |
Schneider, Implementing fault tolerant services using the state machine, Cornell Univ., 1990, 21 pgs. |
Number | Date | Country | |
---|---|---|---|
20130239114 A1 | Sep 2013 | US |