Source: https://patents.google.com/patent/US9411812B2/en
Timestamp: 2019-04-19 07:16:52+00:00

Document:
Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for file system management. In one aspect, a method includes receiving a request at a kernel to perform a file operation on a particular file; identifying a flag bit associated with the file; invoking user space file handler to perform particular action when the flag bit is set; determining whether notification that action has been performed by file handler is received; and allowing the file operation on the file when notification is received.
This application is a continuation and claims the benefit under 35 U.S.C. §120 of the filing date of U.S. application Ser. No. 13/350,047, for File System Management, which was filed on Jan. 13, 2012, which claims the benefit under 35 U.S.C. §119(e) of the filing date of U.S. patent application Ser. No. 61/433,180, for File System Management, which was filed on Jan. 14, 2011, and which are incorporated here by reference.
This specification relates to file systems.
Requests for particular file operations, for example to read a file, are sent to the operating system kernel (e.g., using a system call). The kernel manages resources (e.g., system hardware as well as particular information such as a database record) available to perform the operations. The kernel allocates resources for performing the requested operation. Conventionally, resources can only be used by a single process at a time. When two processes are running, they can each be waiting for an event of the other to occur in order to proceed. For example, the event that each process is waiting for can be the release of a respective recourse currently possessed by the other process. However, since both processes are waiting for the other, neither will cause the event. This results in a deadlock.
This specification describes technologies relating to file system management.
In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include the actions of receiving a request at a kernel to perform a file operation on a particular file; identifying a flag bit associated with the file; invoking user space file handler to perform particular action when the flag bit is set; determining whether notification that action has been performed by file handler is received; and allowing the file operation on the file when notification is received. Other embodiments of this aspect include corresponding systems, apparatus, and computer programs recorded on computer storage devices, each configured to perform the operations of the methods.
These and other embodiments can each optionally include one or more of the following features. Invoking the user space file handler includes holding the operation and setting a time for the file handler to perform the action without setting any resource locks. Expiration of the set time without a request for further time results in the kernel performing the file operation. The file operation is a read file operation and the file handler requests the file data from a network location. The file operation is a modify file operation and the file handler copies the file prior to performing the modify file operation being performed. The method further includes identifying i -node information for the file, where the i-node information includes one or more flag bits. The method further includes when the flag bit is set, accessing extended attribute information associated with the file to identify special file handling operation to be performed by file handler.
Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. Techniques are provided for invoking user space handlers for kernel space events. As a result, file operations are also intercepted before they are performed. A hold on a request can be initiated while a user space handler is invoked without setting any locks. Thus, deadlocks can be avoided. Invoking user space handlers provides greater flexibility in performing operations than in the kernel space, for example, initiating network connections to retrieve data. Special file handling can be identified for files by examining i-node flags. Using an i-node flag to identify special file handling provides a quick check and reduces input/output (I/O) operations.
FIG. 1 is a block diagram of an example system.
FIG. 2 is an example diagram of kernel space interactions.
FIG. 3 is a flow diagram of an example process for performing file operations.
FIG. 4 is an example system architecture.
When a file operation request is received at the kernel, for example, as a system call to read a file or to modify a file (write), a determination is made as to whether additional operations are to be performed before allowing the requested file operation. If additional operations are to be performed, the kernel institutes a hold on the file operation, without reserving any resources to the request (e.g., no locks), and sets a timeout timer. An extended attribute of the file identifies special file handling to be performed on the file. A corresponding user space file handler is requested to perform one or more actions within the time provided by the timer. When the timer expires, the hold is released and the requested resources are allocated for performing the requested file operation.
FIG. 1 is a block diagram of an example system 100. The system 100 includes a user device 102 that can communicate with one or more network locations 106 through a network 104.
The user device 102 can represent various forms of digital computing devices, for example, laptops, desktops, workstations, personal digital assistants, tablet computers, and other mobile devices (e.g., smartphones, mobile phones). The network 104 can be, for example, a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof. Communication through the network 104 can be performed using one or more wired, wireless, or a combination of connections. The network locations 106 can be other computing devices, remote storage locations, servers, or other data repositories accessible by the user device 102.
The user device 102 includes both a kernel space 110 and user space 108. In particular, an operating system typically segregates virtual memory into the kernel space 110 and the user space 108. The kernel space 110 is reserved for running the kernel, kernel extensions, and device drivers. The user space 108 includes the memory area where user mode applications work. The kernel represents a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources. Particular operations can be performed in the user space that cannot be performed in the kernel space and vice versa. For example, network connections can be made in user space but not in kernel space.
In response to a request, for example, to perform a file modification or a file open, the kernel can invoke one or more file handlers in the user space 108 to perform particular actions prior to assigning resources in response to the request. The user space handler can perform operations including opening network connections in order to request data from one or more network locations 106 through the network 104.
FIG. 2 is an example diagram of kernel space interactions 200. A file operation request is received by the kernel 204 (e.g., from a user space application). Based on an analysis of the request, the kernel holds the request and invokes a user space handler 206 to perform one or more actions (e.g., according to a token sent to the user space file handler 206). In particular, the kernel can read an extended attribute 208 associated with the file to identify the particular file operations to be performed, e.g., prior to allowing the requested file operation to proceed. The kernel does not place a lock on any resources. The kernel further can set a timer in which the user space handler 206 has to perform the one or more actions or request additional time to perform the one or more actions.
The user space handler 206 performs the one or more actions and sends the token back to the kernel 204 indicating that the actions have been completed. Alternatively, the user space handler 206 can send a request for more time. The kernel 204 can increase or reset the timer in response to the request for more time. Once notified of the completed action, the kernel 204 releases the hold and assigns resources for performing the requests file operation.
No locks are placed by the kernel 204. Therefore, if the timer runs out without receiving notification or a request for time from the user space handler 206, the hold is released by the kernel 204 and resources are allocated for attempting to perform the requested file operation, after which control returns to the application (e.g., to perform further operations based on the requested file operation, for example, presenting file contents based on a requested read operation).
FIG. 3 is a flow diagram of an example process 300 for performing file operations. A request to perform a file operation is received (302). The request can be a system call to perform various types of file operations. For example, a read operation (e.g., to read a file) or a write operation (e.g., to edit file data). The received request can be sent to the kernel in response to user actions, for example, a user selecting a file to open or a user performing an edit on an open file.
File information associated with the request is identified (304). For example, in order to perform a read or write of a file, the file data is identified according to the file's i-node or other catalog record. This is a unique identifier for the file that is indexed (e.g., a table of i-nodes) to file information including the location of blocks of data in which the file is stored, time stamps, last accessed, owner of file, permissions, size, and/or creation time. The kernel can load the i-node file information into memory. The i-node can also be associated with one or more flag bits.
A determination is made as to whether a particular flag bit is set (306). This particular flag bit indicates that special file handling should be performed. However, as a single bit this does not indicate what processing is to be performed on the file. Instead, when the flag bit is set, the kernel reads the extended attribute associated with the file. The extended attribute is an additional data structure associated with the file that describes the special file handling to be performed. Since the i-node (or corresponding catalog record) is loaded into memory by the kernel, little processing cost is required to check the flag bits (e.g., no additional I/O operations are required). If the flag bit is not set, the kernel can proceed to respond to the request.
For example, the extended attribute can provide metadata about the type of file and what special handling is needed to be performed. For example, the extended attribute can indicate that the particular file is a data-less file (e.g., the file is only virtually present) and that the corresponding file data needs to be retrieved before the requested operation can be performed (e.g., the file data has to be retrieved before the file can be read). In another example, the extended attribute can indicate that the particular file is to be backed up before the requested operation is performed (e.g., to back-up a copy of the file prior to modifying the file). In some implementations, the extended attribute identifies a particular user space handler to be invoked (e.g., designed to perform particular operations).
A user space file handler is invoked to perform the one or more actions indicated by the extended attribute (308). For example, in some implementations, the file handler has already called into the kernel requesting work and is waiting to be assigned a token. Alternatively, the specific user space file handler is invoked by the kernel. The kernel sends the token to the file handler indicating the actions to be performed with respect to the file. The file handler then initiates a thread to perform the requested action. For example, the file handler can open one or more network connections to a destination in which the file data is stored. The file data can then be retrieved and associated with the existing zero data file.
In addition to invoking the user space file handler, the kernel holds the requested operation and sets a timer (310). The timer provides a time limit for the user space file handler to perform the indicated operation. While the timer holds the requested operation, no resources are locked out by the kernel. Thus, no deadlocks can occur from the request (e.g., from a resource request made by the user space file handler). As a result, other requests for resources can be made (e.g., as part of other processes) while the user space file handler is performing the one or more actions.
A determination is made as to whether the timer has expired before receiving a response from the user space file handler (312). If a response is not received, the hold is released (314) and the requested operation proceeds (322). For example, the kernel can allocate the necessary resources for performing the requested operation. The operation may or may not be able to be performed. For example, if the requested file operation is to read a file that is not present, then an error will result from the attempted read operation. However, if the requested file operation is a file modification to an open file, the modification can be performed.
If a response is received from the user space file handler (316) before the timer has expired, a determination is made as to whether or not the action or actions have been completed (318). If the action or actions have not been completed, a request for more time can be sent by the user space file handler. The timer is extended or reset (320). The process then returns to the determination of whether a response is received before the timer expires (312). The hold on the file operation is maintained until the timer again expires.
If the action has been completed, the hold is released and the requested file operation proceeds (322). The user space file handler can indicate that the action has been complete, for example, by returning the received token to the kernel or other notification. The file operation can proceed, for example, by the kernel assigning resources to perform the requested operation. For example, when the request is a read file request, the resources are allocated for reading the file into memory. The file data can then, for example, be presented to the user (e.g., as a document).
Specific examples are provided below to further illustrate the process 300.
In some implementations, data-less data items are created that present the appearance of data items that are not located on the particular user device. For example, items being synchronized or downloaded from other locations (e.g., other user devices or network locations) may not have the data to be synchronized or downloaded stored locally. Different criteria can be used to determine whether or not to download the data. For example, the size of the file, the current transfer rate, the type of data, etc. As such, the data can be stored elsewhere and retrieved when requested by the user. In order to present the appearance of the data, virtual data items can be generated. For example, files can appear to be present on the user device (e.g., as a displayed icon in a particular directory), but the file data is not physically present.
Similarly, in another implementation, data items can be removed from the user device and stored in a network location while retaining the virtual item representation. Again, different criteria can be used to determine whether or not to remove a data item from physically being located on the user device. For example, data items that are accessed infrequently can be removed to save space. Additionally, data items can be removed based on a percentage or amount of free space remaining on the device to store data (e.g., when a threshold storage level is reached).
These virtual data items can appear as any other file, directory, or other data on the file system or can be identified as virtual files (e.g., with a particular badging of an associated icon).
When a user requests one of these virtual data items, for example a file, the data must be retrieved before the file read is attempted otherwise an error will result. Consequently, the read request the flag bit indicates that the file is an empty file and that the file data must be retrieved. The read request is held by the kernel while a particular user space file handler is requested in order to retrieve the associated file data.
The user space file handler performs the network connections to the storage location of the file data (e.g., at a location indicated in the extended attribute data). The retrieved file data is then associated with the data-less data file such that the file now has the file contents (e.g., the data-less file can be modified or replaced). If the user space file handler fails to perform the actions, for example, because the network connections are unavailable, a time out will result in the hold being released by the kernel. However, since there is no data to be read, an error will result. This read error can be presented to the user indicating that the action is unable to be performed at the present time.
Once the file data is retrieved, the user space file handler indicates to the kernel that the actions have been performed and the kernel releases the hold on the read operation. The file is then read, for example, for presentation to the user by an application associated with the file.
In some other implementations, changes to data items are tracked and periodically stored prior to any changes being made. For example, a modification to a data item can trigger a copy of the data item (e.g., a version of the data item) being stored prior to performing the modification. The user device can maintain a collection of versions of the data item for later retrieval by the user.
Thus, in order to store copies of the file prior to modification, the file modification request has to be intercepted and the copy performed prior to allowing the modification operation to proceed.
When a request to perform a file modification operation is received by the kernel, the kernel identifies the flag bit as set. The extended attribute indicates that the file is one to be tracked and that a copy should be made before a file modification operation. In some implementations, this is variable depending on specific criteria. For example, only one copy can be made for a given time period (e.g., 1 hour). Thus, a copy is made of the file prior to the first modification of the file.
However, any subsequent modifications to the same file within that time period are allowed to proceed without copying the file. Thus, a file that changes 10 times within an hour will only be copied the first time after the start of the specified time period. Later requests to modify the file within the specified time period will not trigger the special file handling prior to performing the requested operation.
In some other implementations, when a request to perform a file modification operation is received, a determination is made as to whether a prior operation has been performed on the file within a specified time period. For example, the time of the requested modification can be compared to operations performed on the file within a current fixed window of time. For example, the specified time period can be one of a sequence of fixed time windows (e.g., every hour block of time can form a specified time period regardless of when a prior file modification operation occurred). If there has not been a prior operation on the file within a current time window (or less than a specified number of modifications), the file is copied prior to the modification operation being performed. In some implementations, in addition to the determination with respect to time, the type of requested modification is considered. For example, an edit operation can trigger the copy being made while a name change may not.
If there has been a prior operation on the file within the current time window, the requested modification can be allowed within performing any intervening action (e.g., copying the unmodified version of the file). For example, when only one action (e.g., copy file) per time window is performed prior to a requested modification operation on a file.
If the file is to be copied prior to the modification operation, the user space file handler is called to perform the file copy operation. When the kernel is notified that the operation is complete, the hold on the operation is removed and the file is allowed to be modified.
If a timeout occurs without a response from the user space file handler, the hold is released and the modification is allowed to occur. Thus, no pre-modified version will be stored.
In some other implementations, files can have a flag bit set when the file is to be tracked. For example, when versions of a file are stored as described above, the versions can be tracked to make sure all the versions are linked together. In another example, if a request for a name change is received for a tracked file the name change is held while performing a link between the new file and the earlier versions.
FIG. 4 illustrates an example architecture of a system 400. The system architecture 400 is capable of performing operations for performing file system management. The architecture 400 includes one or more processors 402 (e.g., IBM PowerPC, Intel Pentium 4, etc.), one or more display devices 404 (e.g., CRT, LCD), graphics processing units 406 (e.g., NVIDIA GeForce, etc.), a network interface 408 (e.g., Ethernet, FireWire, USB, etc.), input devices 410 (e.g., keyboard, mouse, etc.), and one or more computer-readable mediums 412. These components exchange communications and data using one or more buses 414 (e.g., EISA, PCI, PCI Express, etc.).
The term “computer-readable medium” refers to any medium that participates in providing instructions to a processor 402 for execution. The computer-readable medium 412 further includes an operating system 416 (e.g., Mac OS®, Windows®, Linux, etc.), a network communication module 418, user space file handlers 422, and other applications 424.
The operating system 416 can be multi-user, multiprocessing, multitasking, multithreading, real-time and the like. The operating system 416 performs basic tasks, including but not limited to: recognizing input from input devices 410; sending output to display devices 404; keeping track of files and directories on computer-readable mediums 412 (e.g., memory or a storage device); controlling peripheral devices (e.g., disk drives, printers, etc.); and managing traffic on the one or more buses 414. The operating system 416 also includes kernel functions. The network communications module 418 includes various components for establishing and maintaining network connections (e.g., software for implementing communication protocols, such as TCP/IP, HTTP, Ethernet, etc.).
The operating system 416, particularly the kernel, and the user space file handlers 422 provide various software components for performing the various functions for holding file operation requests at the kernel and invoking a user space handler to perform one or more actions before releasing or timing out the hold on the requested operation as described with respect to FIGS. 1-3.
allowing the operation to be performed on the modified file.
2. The method of claim 1, wherein expiration of the set time without a request for further time results in the kernel performing the operation.
3. The method of claim 2, wherein the kernel executes in a kernel space of a memory of a computer system.
4. The method of claim 3, wherein the kernel space is reserved for execution of the kernel, kernel extensions, and device drivers.
5. The method of claim 3, wherein particular operations can be performed in a user space that cannot be performed in the kernel space and vice versa.
6. The method of claim 1, wherein the operation is a read file operation.
7. The method of claim 1, wherein the operation is a modify file operation and the file handler copies the file prior to the modify file operation being performed.
8. The method of claim 1, further comprising: identifying i-node information for the file, wherein the i-node information includes one or more flag bits.
when the flag bit is set: accessing the file attribute from the memory to identify the particular action to be performed by the file handler.
10. The method of claim 9, wherein the file attribute identifies a particular user space handler to be invoked, the particular user space handler being designated to perform particular operations.
11. The method of claim 1, wherein the file attribute indicates that the file is to be backed up before the operation is performed.
12. The method of claim 2, wherein a user space comprises a memory area in which user mode applications execute and the kernel does not execute.
allowing, at the kernel, the operation to be performed on the modified file.
14. The system of claim 13, wherein expiration of the set time without a request for further time results in the kernel performing the operation.
15. The system of claim 13, wherein the operation is a read file operation.
16. The system of claim 13, wherein the operation is a modify file operation and the file handler copies the file prior to the modify file operation being performed.
identifying i-node information for the file, wherein the i-node information includes one or more flag bits.
accessing the file attribute from the memory to identify the particular action to be performed by the file handler.
19. The system of claim 13, wherein the file attribute indicates that the file is to be backed up before the operation is performed.
20. The system of claim 13, wherein the file attribute identifies a particular user space handler to be invoked, the particular user space handler being designated to perform particular operations.
22. The non-transitory computer storage medium of claim 21 , wherein expiration of the set time without a request for further time results in the kernel performing the operation.
23. The non-transitory computer storage medium of claim 21, wherein the operation is a read file operation.
24. The non-transitory computer storage medium of claim 21 wherein the operation is a modify file operation and the file handler copies the file prior to the modify file operation being performed.
25. The non-transitory computer storage medium of claim 21, further operable to cause the data processing apparatus to perform operations comprising: identifying i-node information for the file, wherein the i-node information includes one or more flag bits.
27. The non-transitory computer storage medium of claim 21, wherein the file attribute indicates that the file is to be backed up before the operation is performed.
28. The non-transitory computer storage medium of claim 21, wherein the file attribute identifies a particular user space handler to be invoked, the particular user space handler being designated to perform particular operations.
allowing the operation to be performed on the file.
30. The method of claim 29, wherein the request is a file modification and the particular action is to perform a copy of the file.
31. The method of claim 29, wherein the time period is a first time window of a sequence of time windows, and wherein the action is performed on the file once during each time window of the sequence of time windows.
32. The method of claim 29, wherein the first time window is an hour block of time.
"Apple Previews Mac OS X Leopard," Aug. 7, 2006, [Online] [Retrieved on Nov. 26, 2007] Retrieved from the Internet: URL:http://www.apple.com/pr/library/2006/aug/07leopard.html, pp. 1-2.
"Aulaclic: Unit 6. The Recycle Bin," Nov. 2005, [Online] [Retrieved on Nov. 26, 2007] Retrieved from the Internet: URL:http://www.teacherclick.com/winxp/t-6-1.htm, pp. 1-2.
"MSDN Academic Alliance Developer Center, Curriculum Repository Glossary," [Online] [Retrieved on Apr. 22, 2009] Retrieved from the Internet URL: http://www.academicresourcecenter.net/curriculum/glossary.aspx, 4 pages.
"What's New in Word 2002," Wellesly College Information Services Computing Documentation, Jan. 2002, [Online] Retrieved on Aug. 14, 2008] Retrieved from the Internet URL: http://www.wellesley.edu/Computing/Office02/Word02/word02.html, 19 pages.
Anonymous, "ForeverSave Version 1.1.3", Published Jan. 1, 2009, 16 pgs [online]. Retrieved from the Internet: .
Anonymous, "ForeverSave Version 1.1.3", Published Jan. 1, 2009, 16 pgs [online]. Retrieved from the Internet: <URL: http://tool-forcesw.com/docs/ForeverSave-Manual.pdf>.
Bonwick et al., "The Zettabyte File System," [Online] [Retrieved on Jan. 22, 2008] Retrieved from the Internet: URL:http://partneradvantage.sun.com/protected/solaris10/adoptionkit/tech/zfs/zfs-overview.pdf, 13 pages.
Bonwick, "ZFS The Last Word in File Systems," [Online] [Retrieved on Jan. 22, 2008] Retrieved from the Internet: URL:http://opensolaris.org/os/community/zfs/docs/zfs.pdf, 34 pages.
Charles Rubin, Mary Millhollon and Katherine Murray, "Microsoft Office Word 2003, Official Manual", First Edition, Japan, Nikkei BP Softpress, Jul. 12, 2004, vol. 1, p. 300, 815-818.
Chen et al., "Data Redundancy and Compression Methods for a Disk-based Network Backup System", 2004, IEEE, pp. 1-8.
Communication pursuant to Article 94(3) EPC for Application No. EP 07 813 540.7, dated Jun. 23, 2009, 2 pages.
European Search Report dtd Oct. 16, 2012 in EP Application No. 12150673, 9 pgs.
Examination Report from European Application No. 07 813 540.7 dated Oct. 27, 2011, 5 pages.
Examination Report from European Application No. 07 813 593.6 dated Mar. 25, 2013, 4 pages.
Examination Report from European Application No. 07 813 605.8 dated Oct. 27, 2011, 5 pages.
Extended European Search Report and Written Opinion, European Application No. 11171738.5, Aug. 29, 2011, 5 pages.
Extended European Search Report, European Application No. 11184579.8, Nov. 17, 2011, 6 pages.
Godfrey, Michael et al., "Using Original Analysis to Detect Merging and Splitting of Source Code Entities," IEEE Transactions on Software Engineering, vol. 31, No. 2. Feb. 2005. pp. 166-181.
Griffiths, "Leopard first looks: Time Machine," Aug. 8, 2006 [Online] [Retrieved on Nov. 23, 2007] Retrieved from the Internet: URL:http://www.macworld.com/2006/08/firstlooks/leotimemac/index.php?pf=1, pp. 1-2.
In-link files, The Open Group Base, Specifications Issue 6 [online] IEEE Std 1003.1, 2004 Edition. [retrieved on Apr. 6, 2011]. Retrieved from the Internet:URL:http://pubs.opengroup.org/onlinepubs/009695399/utilities/In.html, 5 pages.
International Search Report and Written Opinion, PCT/US2008/065146, Oct. 31, 2008, 15 pages.
International Search Report and Written Opinion, PCT/US2008/066212, Mar. 9, 2009, 20 pages.
Microsoft Corporation, "Description of the AutoRecover Functions in Excel," [online] Microsoft Corporation, Aug. 10, 2007, Article ID 289273; URL: http://support.microsoft.com/kb/289273/en-us.
Microsoft Technet: "Restore a previous version of a file," Jan. 21, 2005, [Online] [Retrieved on Oct. 20, 2011] Retrieved from the Internet URL: http://technet.microsoft.com/en-us/library/cc778220(d=printer,v=WS.10).aspx , pp. 1-2. (From OA dated Oct. 27, 2011) (From OA May 26, 2014).
Microsoft-TechNet, "Using Encrypting File System," Nov. 3, 2005, Microsoft, 40 pages.
Moorthy, "Linux Crontab: 15 Awesome Cron Job Examples," TheGeekStuff.com, Jun. 11, 2009, retrieved on Dec. 23, 2013, http://www.thegeekstuff.com/2009/06/15-practical-crontab-examples/, 6 pages.
Office Action dated Apr. 1, 2015 from related Chinese Application No. 201310073409.1, 13 pages.
Office Action dated Feb. 29, 2012 from related Chinese Application No. 200880024710.0, 11 pages.
Posey, Brien M., "Working with the Windows Server 2003 Volume Shadow Copy Service". Published Jun. 24, 2004. http://www.windowsnetworking.com/articles-tutorials/Windows-Server-2003-Volume-Shadow-Copy-Service.html.; 11 pages.
Rubel, "Easy Automated Snapshot-Style Backups with Rsync," [Online] [Retrieved on Nov. 8, 2010] Retrieved from the Internet URL: http://www.mikerubel.org/computers/rsync-snapshots; 18 pages.
Shi et al., "USP: A Lightweight File System Management Framework," 2010 Fifth IEEE International Conference on Networking, Architecture, and Storage, 2010 IEEE, pp. 250-256.
Sun Microsystems, Inc., "ZFS On-Disk Specification," Draft: Dec. 9, 2005, [Online] [Retrieved on Jan. 22, 2008]; Retrieved from the Internet URL: http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf, 55 pages.
Tittel, "An EAZ Way to Restore Crippled and Inoperable Systems," ChannelWeb, Apr. 25, 2005, [Online] [Retrieved on Aug. 13, 2008] Retrieved from the Internet URL: http://www.crn.com/white-box/161502165, 10 pages.
Wang et al., "A Secure and Efficient Desktop Backup and Recovery System", 2007, IEEE, pp. 304-309.

References: §120
 §119
 Application No. 12150673
 Application No. 07
 Application No. 07
 Application No. 07
 Application No. 11171738
 Application No. 11184579
 Application No. 201310073409
 Application No. 200880024710