Fast native file system creation for backup files on deduplication systems

Native file system creation for backup files is described. A system creates a virtual disk template corresponding to a disk associated with a client device. The system sends a copy of the virtual disk template as template data. The system sends a copy of a file on the disk as file data. The system stores a backup file in a file system format that is native to the client device by combining the template data and the file data. The system restores a file in the backup file to the disk via mounting the backup file as a virtual disk on the client device.

BACKGROUND

A backup file can be a copy of part or all of a data set, and can be used to restore part or all of the data set to the condition of the data set at the point in time that the copy was created. A full backup file represents an entire data set at the point in time that the full backup file was created. As a data set increases in size, a full backup file requires more time to be created and requires more storage space. Therefore, a database administrator can supplement a full backup file of a large data set with a series of incremental backup files, or differential backup files, each of which can be a copy of the modifications to a data set since the most recent copy of the entire data set or since the most recent copy of modifications to the data set. If the backup/restore application identifies that the most recently created backup file for a data set is not a full backup file, the backup/restore application can combine the most recently created backup file for the data set with other backup files created for the data set into a synthetic full copy of the backed-up dataset. For example, after a backup/restore application creates a full backup file of a hard disk's entire data set, a user modifies data blocks in only one of the hard disk sectors, and the backup/restore application subsequently creates an incremental backup file of the hard disk's modified sector. Then the backup/restore application combines the current incremental backup file of the hard disk's modified sector with the previous full backup file of the hard disk to create a synthetic full backup file that includes the hard disk's recently modified sector as a replacement for the previous version of the modified sector and also includes the rest of the hard disk's previous data set.

De-duplicating can be a specialized data compression process used by a backup/restore application for eliminating most identical copies of repeating data. In deduplication process, unique blocks of data are identified and stored during analysis. As the analysis continues, other data blocks are compared to the already stored data blocks, and whenever a match occurs, the redundant data block is replaced in the backup file with a small reference that points to the matching data block that is already stored. Given that the deduplication process may identify the same unique data block dozens, hundreds, or even thousands of times, the amount of data that needs to be stored can be greatly reduced.

A data set can be a collection or a group of information that is backed up as a unit, such as the information for a computer or a network of computers. A data set may be stored on a storage array, which is a disk storage system that includes multiple disk drives. Unlike a disk enclosure, a storage array has cache memory and advanced functionality, such as virtualization and Redundant Array of Independent Disks (RAID). A data protection administrator may manage a backup/restore application to create backups files of data sets and store the backup files of data sets on one or more storage arrays.

A virtual machine can be a software implementation of a computer, and executes programs like a physical computer. A system virtual machine provides a complete system platform which supports the execution of a complete operating system, and usually emulates an existing architecture. Multiple instances of virtual machines lead to more efficient use of computing resources, both in terms of energy consumption and cost effectiveness, known as hardware virtualization, the key to a cloud computing environment. A virtual machine typically includes a virtual disk, which may be stored in file formats for virtual disks such as VHD, VHDx, and VMDK. A virtual disk can be a software component that emulates a physical storage device. A disk can be a data storage device. A volume can be a single accessible storage area with a file system, typically resident on a single partition of a disk. A cluster is the smallest logical unit of disk space, such as one or more disk sectors, that can be allocated for storing files and/or directories. To reduce the overhead of managing on-disk data structures, a file system allocates an extent of contiguous clusters, each of which is a group of one or more disk sectors, instead of allocating individual disk sectors by default. An extent can be any number of consecutive logical units of disk space. A file extent can be a number of consecutive logical units of disk space used to store a collection of information under a single identifying name. Similar to other data sets, backup/restore applications make copies of a virtual machine's data set and store these copies as backup files that enable the backup/restore application to restore the virtual machine's data set in the event of corruption or an erroneous update to the virtual machine's data set.

DETAILED DESCRIPTION

Even if a backup file for a disk is stored to a fast access disk in a storage array, a significant amount of time may be required to send the backup file, or a file within the backup file, to a client that requested the backup file to restore at least part of the disk. Since a backup/restore application typically stores backup files in a proprietary format, a fast access disk that stores a disk's backup file cannot be mounted to a client to achieve instant uptime of the files in the backup file because the client's native file system cannot read these files stored in the backup/restore application's proprietary format.

Methods and systems are provided for native file system creation for backup files. First, a brief summary of a method for native file system creation for backup files will be described. Next, a system for native file system creation for backup files will be described with reference to example embodiments. Then data structures for native file system creation for backup files will be described with reference to example embodiments. After that, a method for native file system creation for backup files will be described with reference to example embodiments

Native file system creation for backup files is described. A virtual disk template is created that corresponds to a disk associated with a client device. A copy of the virtual disk template is sent as template data. A copy of a file on the disk is sent as file data. A backup file is stored in a file system format that is native to the client device by combining the template data and the file data. A file in the backup file is restored to the virtual disk via mounting the backup file to the client device.

For example, when requested to create a backup for a client device, a NetWorker® backup and restore application creates a virtual disk template, and formats the template using the client's New Technology File System (NTFS) system format. Next, the NetWorker® backup and restore application streams a copy of the template as template data, and streams a copy of the blocks occupied by a source file on the disk as file data. Then the NetWorker® backup and restore application combines the template data and the file data to create and store a NTFS-formatted backup file of the disk. When the client requests the restoration of one of the disk's database files from the backup file, the NetWorker® backup and restore application mounts the backup file as a virtual disk, which contains the requested database file, on the client.

FIG. 1illustrates a block diagram of a system100that implements native file system creation for backup files, under an embodiment. As shown inFIG. 1, the system100may illustrate a cloud computing environment in which data, applications, services, and other resources are stored and delivered through shared data-centers and appear as a single point of access for the users. The system100may also represent any other type of distributed computer network environment in which servers control the storage and distribution of resources and services for different client users.

In an embodiment, the system100represents a cloud computing system that includes a first client102, a second client104, and a third client106; and a server108and a storage array110that may be provided by a hosting company. The storage array110includes a first array disk112and a second array disk114. AlthoughFIG. 1depicts the first client102as the laptop computer102, the second client104as the personal computer104, and the third client106as the server106, any of the clients102-106may be any type of computer, such as the hardware device400depicted inFIG. 4and described below. Any of the clients102-106may be a computer capable of hosting multiple virtual machines, such as the client106that includes a first local disk120and a second local disk122. AlthoughFIG. 1depicts the local disks120-122as internal to the client106, any of the local disks120-122can be external to the client106, and may be any combination of hard disks120-122and/or virtual disks120-122. The clients102-106, the server108, and the storage array110communicate via a network124. Since the server108includes a backup/restore application126, the server108may be referred to as the backup server108. Although following paragraphs describe EMC Corporation's Avamar® backup/restore application and EMC Corporation's NetWorker® backup/restore application as examples of the backup/restore application126, the backup/restore application126may be any other backup/restore application which provides the backup/restore functionalities described in the Background section.

AlthoughFIG. 1depicts the system100with three clients102-106, one server108, one storage array110, two array disks112-114, two local disks120-122, one network124, and one backup/restore application126, the system100may include any number of clients102-106, any number of servers108, any number of storage arrays110, any number of array disks112-114, any number of local disks120-122, any number of networks124, and any number of backup/restore applications126. WhileFIG. 1depicts the backup/restore application126residing completely on the server108, the backup/restore application126may reside completely on any of the clients102-106, completely on the server108, completely on another server that is not depicted inFIG. 1, or in any combination of partially on the clients102-106, partially on the server108, and partially on the other server that is not depicted. The clients102-106and the server108may each be substantially similar to the hardware device400depicted inFIG. 4and described below.

Although the following paragraph describes EMC Corporation's Avamar® backup/restore application as an example of the backup/restore application126, the backup/restore application126may be any other backup/restore application which provides the backup/restore functionalities described in the Background section. The backup/restore application126may be EMC Corporation's Avamar® backup/restore application, which provides fast, efficient backup and recovery through a complete software and hardware solution. Equipped with integrated variable-length deduplication technology, EMC Corporation's Avamar® backup/restore application facilitates fast, periodic full backups for virtual environments, remote offices, enterprise applications, network access servers, and desktops/laptops. Data deduplication significantly reduces backup time by only storing unique periodic changes, while always maintaining periodic full backups for immediate single-step restore. The transmission of deduplicated backup sends only changed blocks, reducing network traffic. EMC Corporation's Avamar® backup/restore application leverages existing local area network and wide area network bandwidth for enterprise-wide and remote/branch office backup and recovery. Every backup is a full backup, which makes it easy for users to browse, point, and click for a single-step recovery. EMC Corporation's Avamar® data store features redundant power and networking, redundant array of independent disks, and redundant array of inexpensive nodes technology to provide uninterrupted data accessibility. Periodic data systems checks ensure recoverability whenever needed. EMC Corporation's Avamar® systems can be deployed in an integrated solution with EMC Corporation's Data Domain® systems for high-speed backup and recovery of specific data types.

Although the following paragraph describes EMC Corporation's NetWorker® backup/restore application as an example of the backup/restore application126, the backup/restore application126may be any other backup/restore application which provides the backup/restore functionalities described in the Background section. The backup/restore application126may be EMC Corporation's NetWorker® backup application, which is a suite of enterprise level data protection software that unifies and automates backup to tape, disk-based, and flash-based storage media across physical and virtual environments for granular and disaster recovery. Cross-platform support is provided for many environments, including Microsoft Windows®. A central NetWorker® server manages a data zone that contains backup clients and NetWorker® storage nodes that access the backup media. The NetWorker® management console software provides a graphic user interface for functions such as client configuration, policy settings, schedules, monitoring, reports, and periodic operations for deduplicated and non-deduplicated backups. The core NetWorker® software backs up client file systems and operating system environment. Add-on database and application modules provide backup services for products such as Microsoft® Exchange Server. Client backup data can be sent to a remote NetWorker® storage node or stored on a locally attached device by the use of a dedicated storage node. EMC Corporation's NetWorker® modules for Microsoft® applications supports Microsoft® products such as Microsoft® Exchange, Microsoft® Sharepoint, Microsoft® SQL Server, and Microsoft® Hyper-V servers.

When requested to create a backup file for a client device, the system100creates a native file system-formatted virtual disk template based on one of the client's disks. For example, and without limitation, this can include a component of the NetWorker® backup and restore application126, which resides on the client106, creating the software container128that is local to the client106, creating the virtual disk template130in the software container128, based on the client's local disk122, and formatting the virtual disk template130using the NTFS file system that is native to the client106. A virtual disk template can be a preset format for a software component that emulates a physical storage device, which is used so that the software component format does not have to be recreated each time it is used. An example of the virtual disk template130is depicted inFIG. 2Aas a virtual disk template202, and described below in reference toFIGS. 2A-D. A client device can be a computer that is capable of obtaining information and/or applications from a server.

Creating the virtual disk template may include identifying a size associated with the disk, creating the virtual disk template based on the size, mounting the virtual disk template on the client device, creating a volume in the virtual disk template, formatting the volume with the file system format that is native to the client device, creating a directory corresponding to a directory structure of a file on the disk, creating a dummy file without data to represent the file; reserving file extents, corresponding to file extents of the file, on the volume and unmounting the virtual disk template from the client device. For example, the client's NetWorker® component identifies the size of the local disk122as 3 megabytes, creates the software container128in the VHD format and sufficiently large to hold a 3 megabytes virtual disk template, mounts the software container128on the client106, and creates the 3 megabytes virtual disk template130in the software container128. Continuing the example, the client's NetWorker® component creates the volume132in the virtual disk template130that is the same size as a volume in the local disk122, and formats the volume132using the client's NTFS system format. An example of the volume132is depicted inFIG. 2Bas a volume204, and described below in reference toFIGS. 2B-C. Further to the example, the client's NetWorker® component creates a dummy file134in the volume132that is large enough to store a copy of a source file in the volume in the local disk122, creates a directory on the volume132that matches the directory for the source file on the local disk122, reserves file extents that stores the file extent information for the source file in the volume in the local disk122, sets attributes and security information, synchronizes the file system, and unmounts the virtual disk template130from the client106. An example of the dummy file134in the volume132is depicted inFIG. 2Cas a dummy file206, and described below in reference toFIG. 2C.

Creating the virtual disk template may also include identifying an offset from a beginning of the disk to a beginning of a volume in the disk, identifying file extent information for the volume in the disk, and creating a file extent offset by combining the offset and the file extent information. For example, the client's NetWorker® component identifies an offset of 5 clusters from the beginning of the local disk122to the beginning of the volume in the local disk122, identifies a file extent that ranges from cluster number6to cluster number40in the volume in the local disk122, and creates a file extent offset of 11 to 45 by combining the offset and the file extent information. Consequently, the client's NetWorker® component creates the volume204at an offset of 5 virtual clusters from the beginning of the virtual disk template202, and stores the dummy file206from the virtual cluster number11of the virtual disk template202to the virtual cluster number11of the virtual disk template202. The system100also uses the file extent offset when creating a backup file for the local disk122, as described below.

After creating the virtual disk template, the system100sends a copy of the virtual disk's template as template data that is used to create a backup file for the disk. By way of example and without limitation, this can include the client's NetWorker® component streaming a copy of the virtual disk template130as template data to the backup server108. A copy can be a thing made to be similar or identical to another thing. Template data can be information associated with a preset format for a software component that emulates a physical storage device, which is used so that the software component format does not have to be recreated each time it is used.

After or while sending a copy of the virtual disk template, the system100sends a copy of a file on the disk as file data that is used to create a backup file for the disk. In embodiments, this can include the client's NetWorker® component streaming a copy of the data blocks in a source file in the local disk122as file data to the backup server108. A data block can be a piece of information that is processed as a unit. File data can be a collection of information stored in a computer's memory and/or on a storage device under a single identifying name.

Having sent copies of the source file in the local disk and the virtual disk's template as data, the system100combines template and file data to create and store a backup file in a client's native file system format so that the client can mount the backup file as a virtual disk. For example, and without limitation, this can include a component of the NetWorker® backup and restore application126, which resides on the backup server108, using a block based backup synthetic full consolidation workflow to combine the template data and the file data to create and store the NTFS-formatted backup file136for the local disk122, which can be mounted to the client106as the virtual disk136. A file system format can be the way that information is arranged by the structure and logic rules used to manage groups of information and their names. Native can be something designed for or built into a given system, such as a language associated with a given processor, computer, or compiler, and programs written in the language.

Combining the template data and the file data may include determining if a stream of data includes any specified file extent information, processing the stream of data as template data if the stream of data does not include any specified file extent information, and processing the stream of data as file data if the stream of data includes any specified file extent information. For example, a translator/mapper engine component of the NetWorker® backup and restore application126, which resides on the backup server108, receives a stream of data and determines if the stream of data includes the cluster numbers within the range of the file extents offset11to40, which was identified during the creation of the virtual disk template130by the client's NetWorker® component. Continuing this example, if the received stream of data for the local disk122includes the virtual cluster number6, then this stream of data is data for the virtual disk template130, such that the server's NetWorker® a component processes this stream of data as template data. Further to this example, if the received stream of data for the local disk122includes the cluster number30, then this stream of data is data for the source file in the volume in the local disk122, such that the server's NetWorker® component processes this stream of data as file data. Therefore, the server's NetWorker® component implements a block based backup synthetic full consolidation workflow by processing the template data for the virtual disk template130and not processing the corresponding data in the local disk122, processing the file data for the source file in the volume in the local disk122and not processing the corresponding data in the dummy file134, and then processing the remaining template data in the virtual disk template130and not processing the corresponding data in the local disk122.

Processing the stream of data as file data may include converting a logical address associated with file data to a relative address, rebasing the relative address, and storing the rebased address, in association with the file data, to the backup file. For example, the client's NetWorker® component streams a copy of the data blocks in the source file in the volume in the local disk122, including a data block identified by a target logical file block, as file data to the backup server108. A translator/mapper engine for the NetWorker® backup and restore application126, which resides on the backup server108, receives and identifies the file data, and converts the target logical file block identifier for the data block to a target file relative block identifier for the data block, thereby converting a block identifier that could be used directly by the targeted storage array110to a block identifier that is relative for the targeted storage array110. Next, the server's translator/mapper engine converts the target file relative block identifier for the data block to a source file relative block identifier for the data block, thereby converting a block identifier that is relative for the targeted storage array110into a block identifier that is relative for the source local disk122. Then the server's translator/mapper engine rebases the source file relative block identifier for the data block to a rebased source file relative block identifier for the data block, thereby converting into a block identifier that is relative for the source local disk122into a block identifier that is based on the source local disk122. The combined process of converting the target logical file block identifier for the data block to a rebased source file relative block identifier for the data block results in the backup file136using the same block identifier for each data block that the local disk122uses for the corresponding data block. The same block identifier for each data block in the backup file136enables the client106to mount and read each data block in the backup file136as if the client device106was reading each data block in the local disk122.

After using a virtual disk template to create a backup file in a client's native file system format, the system100can delete the virtual disk template that was temporarily used to create the backup file, thereby conserving system resources. By way of example and without limitation, this can include the client's NetWorker® component deleting the virtual disk template130.

Having created a native file system-formatted backup file for a client's local disk, the system100mounts the native file system-formatted backup file to the client as a virtual disk so that the client can instantly restore any or all of the backup file's individual files. In embodiments, this can include the NetWorker® backup and restore application126using the Microsoft Windows VHD mount Application Programming Interface (API) to mount the NTFS-formatted backup file136for the virtual disk122as the virtual disk136when the client106requests the restoration of the database file138in the backup file136to the local disk122. Mounting the backup file136as the virtual disk136enables the client106to achieve instant uptime of the database file138in the backup file136because the client's NTFS file system can read the database file138stored in the NTFS format. Mounting can be a process which an operating system makes files and directories on a storage device available for a user to access via the computer's file system. Since the backup file136for the local disk122is being mounted as the virtual disk136on the client device106, and the client device106already includes the local disk122, a possibility is created for a disk signature collision. Therefore, the NetWorker® backup and restore application126uses a globally unique identifier stream layout to stream the backup file136. An example of the backup file stream layout based on the Globally unique identifier Partition Table (GPT) format is depicted inFIG. 2Das a stream layout208, and described below in reference toFIG. 2D.

FIGS. 2A-Dare examples of data structures for native file system creation for backup files. The NetWorker® backup and restore application126creates the software container128that is local to the client106, creates the virtual disk template130in the software container128, based on the client's local disk122, and uses the client's NTFS file system to format the virtual disk template130as the virtual disk template202, which is depicted inFIG. 2A. The NetWorker® backup and restore application126creates the volume204in the virtual disk template202that is the same size as the volume in the local disk122, and uses the client's NTFS format to format the volume204, which is depicted inFIG. 2B. The NetWorker® backup and restore application126creates a dummy file206on the volume204that is large enough to store a copy of the source file in the volume in the local disk122, as depicted inFIG. 2C. If the volume on the local disk122does not store all data blocks contiguously, such as when a user deletes data from an intermediate portion of the volume, then the dummy file206is not contiguous, as depicted inFIG. 2C. The NetWorker® backup and restore application126uses a globally unique identifier stream layout208, which is depicted inFIG. 2D, to stream and store the backup file136. The stream layout208includes a master boot record210, a partition table header212, partition table primary entries214, virtual disk and container contents216, partition table entries218, and a partition table header220.

FIG. 3is a flowchart that illustrates a method for native file system creation for backup files, under an embodiment. Flowchart300illustrates method acts illustrated as flowchart blocks for certain steps involved in and/or between the clients102-106and/or the server108ofFIG. 1.

When a backup file for the client device is requested, a virtual disk template is created that corresponds to a disk associated with the client device, box302. The system100creates a native file system-formatted virtual disk template for a client's local disk. For example, and without limitation, this can include the client's NetWorker® component creating the software container128that is local to the client106, creating the virtual disk template130in the software container128, based on the client's local disk122, and formatting the virtual disk template130using the client's NTFS system format.

Having created a virtual disk template based on a client's local disk, a copy of the virtual disk template is sent as template data, box304. The system100sends a copy of the virtual disk's template to create a backup file for the client's local disk. By way of example and without limitation, this can include the client's NetWorker® component streaming a copy of the virtual disk template130as template data to the backup server108.

After or while sending a copy of a virtual disk template, a copy of a file in the disk is sent as file data, box306. The system100sends a copy of a local disk to create a backup file for the local disk. In embodiments, this can include the client's NetWorker® component streaming a copy of the second local disk122as file data to the backup server108.

Having sent copies of the file in the client's local disk and the virtual disk's template, a backup file is stored in a file system format that is native to a client device by combining template data and file data, box308. The system100combines the template and file data to create and store a backup file in a client's native file system format so that the client can mount the backup file as a virtual disk. For example, and without limitation, this can include the server's NetWorker® component combining the template data and the file data to create and store the NTFS-formatted backup file136for the local disk122.

After using a virtual disk template to create a backup file in a client's native file system format, the virtual disk template is optionally deleted, box310. The system100can delete the virtual disk template that was temporarily used to create the backup file, thereby conserving system resources. By way of example and without limitation, this can include the client's NetWorker® component deleting the virtual disk template130.

Having created a backup file for a client's local disk, a file in the backup file is restored to the disk via mounting the backup file on a client device as a virtual disk, box312. The system100mounts the native file system-formatted backup file to a client as a virtual disk so that the client can instantly restore any or all of the backup file's individual files. In embodiments, this can include the NetWorker® backup and restore application126mounting the NTFS-formatted backup file136for the local disk122as the virtual disk136when the client106requests the restoration of the database file138in the backup file136to the local disk122. Mounting the backup file136as the virtual disk136enables the client106to achieve instant uptime of the database file138in the backup file136because the client's NTFS file system can read the database file138stored in the NTFS format.

AlthoughFIG. 3depicts the blocks302-312occurring in a specific order, the blocks302-312may occur in another order. In other implementations, each of the blocks302-312may also be executed in combination with other blocks and/or some blocks may be divided into a different set of blocks.

Having describing the subject matter in detail, an exemplary hardware device in which the subject matter may be implemented shall be described. Those of ordinary skill in the art will appreciate that the elements illustrated inFIG. 4may vary depending on the system implementation. With reference toFIG. 4, an exemplary system for implementing the subject matter disclosed herein includes a hardware device400, including a processing unit402, memory404, storage406, a data entry module408, a display adapter410, a communication interface412, and a bus414that couples the elements404-412to the processing unit402.

The bus414may comprise any type of bus architecture. Examples include a memory bus, a peripheral bus, a local bus, etc. The processing unit402is an instruction execution machine, apparatus, or device and may comprise a microprocessor, a digital signal processor, a graphics processing unit, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. The processing unit402may be configured to execute program instructions stored in the memory404and/or the storage406and/or received via the data entry module408.

The memory404may include read only memory (ROM)416and random access memory (RAM)418. The memory404may be configured to store program instructions and data during operation of the hardware device400. In various embodiments, the memory404may include any of a variety of memory technologies such as static random access memory (SRAM) or dynamic RAM (DRAM), including variants such as dual data rate synchronous DRAM (DDR SDRAM), error correcting code synchronous DRAM (ECC SDRAM), or RAMBUS DRAM (RDRAM), for example. The memory404may also include nonvolatile memory technologies such as nonvolatile flash RAM (NVRAM) or ROM. In some embodiments, it is contemplated that the memory404may include a combination of technologies such as the foregoing, as well as other technologies not specifically mentioned. When the subject matter is implemented in a computer system, a basic input/output system (BIOS)420, containing the basic routines that help to transfer information between elements within the computer system, such as during start-up, is stored in the ROM416.

The storage406may include a flash memory data storage device for reading from and writing to flash memory, a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and/or an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM, DVD or other optical media. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the hardware device400.

It is noted that the methods described herein can be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, apparatus, or device, such as a computer-based or processor-containing machine, apparatus, or device. It will be appreciated by those skilled in the art that for some embodiments, other types of computer readable media may be used which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, RAM, ROM, and the like may also be used in the exemplary operating environment. As used here, a “computer-readable medium” can include one or more of any suitable media for storing the executable instructions of a computer program in one or more of an electronic, magnetic, optical, and electromagnetic format, such that the instruction execution machine, system, apparatus, or device can read (or fetch) the instructions from the computer readable medium and execute the instructions for carrying out the described methods. A non-exhaustive list of conventional exemplary computer readable medium includes: a portable computer diskette; a RAM; a ROM; an erasable programmable read only memory (EPROM or flash memory); optical storage devices, including a portable compact disc (CD), a portable digital video disc (DVD), a high definition DVD (HD-DVD™), a BLU-RAY disc; and the like.

A number of program modules may be stored on the storage406, the ROM416or the RAM418, including an operating system422, one or more applications programs424, program data426, and other program modules428. A user may enter commands and information into the hardware device400through the data entry module408. The data entry module408may include mechanisms such as a keyboard, a touch screen, a pointing device, etc. Other external input devices (not shown) are connected to the hardware device400via an external data entry interface430. By way of example and not limitation, external input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like. In some embodiments, external input devices may include video or audio input devices such as a video camera, a still camera, etc. The data entry module408may be configured to receive input from one or more users of the hardware device400and to deliver such input to the processing unit402and/or the memory404via the bus414.

A display432is also connected to the bus414via the display adapter410. The display432may be configured to display output of the hardware device400to one or more users. In some embodiments, a given device such as a touch screen, for example, may function as both the data entry module408and the display432. External display devices may also be connected to the bus414via an external display interface434. Other peripheral output devices, not shown, such as speakers and printers, may be connected to the hardware device400.

The hardware device400may operate in a networked environment using logical connections to one or more remote nodes (not shown) via the communication interface412. The remote node may be another computer, a server, a router, a peer device or other common network node, and typically includes many or all of the elements described above relative to the hardware device400. The communication interface412may interface with a wireless network and/or a wired network. Examples of wireless networks include, for example, a BLUETOOTH network, a wireless personal area network, a wireless 802.11 local area network (LAN), and/or wireless telephony network (e.g., a cellular, PCS, or GSM network). Examples of wired networks include, for example, a LAN, a fiber optic network, a wired personal area network, a telephony network, and/or a wide area network (WAN). Such networking environments are commonplace in intranets, the Internet, offices, enterprise-wide computer networks and the like. In some embodiments, the communication interface412may include logic configured to support direct memory access (DMA) transfers between the memory404and other devices.

In a networked environment, program modules depicted relative to the hardware device400, or portions thereof, may be stored in a remote storage device, such as, for example, on a server. It will be appreciated that other hardware and/or software to establish a communications link between the hardware device400and other devices may be used.

It should be understood that the arrangement of the hardware device400illustrated inFIG. 4is but one possible implementation and that other arrangements are possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent logical components that are configured to perform the functionality described herein. For example, one or more of these system components (and means) can be realized, in whole or in part, by at least some of the components illustrated in the arrangement of the hardware device400.

In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software, hardware, or a combination of software and hardware. More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), such as those illustrated inFIG. 4.

Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components can be added while still achieving the functionality described herein. Thus, the subject matter described herein can be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.