PHYSICAL MEDIA AWARE SPACIALLY COUPLED JOURNALING AND REPLAY
1. A computer-implemented method, comprising:
- receiving a request to store data to a solid state drive (SSD);
updating a mapping table, the mapping table mapping physical data locations on the SSD to logical addresses;
generating an entry to a journal based at least in part on the request; and
storing, based at least in part on a number of entries stored by the journal, the journal to a predetermined location.
An indirection mapping data structure can maintain a mapping between logical block addresses used by a host computer and physical data storage locations on a solid state drive. Changes to the indirection mapping data structure can be stored in journals. When a journal is full, the journal can be stored to a predetermined location on the cluster block determined based on the number of entries stored by the journal, leading to a number of journals scattered throughout the cluster block at predetermined locations. Each physical chunk of media, whether written with data or marked as defective is journaled. Such a journaling scheme, where the journal locations are predetermined and each physical chunk of media is journaled is referred to as physical media-aware spatially coupled journaling. During replay the spatially coupled journals can be retrieved from the predefined locations within cluster blocks and used to rebuild the indirection mapping data structure.
- 1. A computer-implemented method, comprising:
receiving a request to store data to a solid state drive (SSD); updating a mapping table, the mapping table mapping physical data locations on the SSD to logical addresses; generating an entry to a journal based at least in part on the request; and storing, based at least in part on a number of entries stored by the journal, the journal to a predetermined location.
- View Dependent Claims (2, 3, 4, 5, 6, 7, 8, 9)
- 10. A system, comprising:
at least one processor; and memory including instructions that, when executed by the at least one processor, cause the system to; receive a request to store data to a solid state drive (SSD); update a mapping table, the mapping table mapping physical data locations on the SSD to logical addresses; generate an entry to a journal based at least in part on the request; and store, based at least in part on a number of entries stored by the journal, the journal to a predetermined location.
- View Dependent Claims (11, 12, 13, 14, 15, 16)
- 17. A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor of a computing device, cause the computing device to:
receive a request to store data to a solid state drive (SSD); generate an entry to a journal based at least in part on the request; and
- View Dependent Claims (18, 19, 20)
This application is a continuation of, and accordingly claims the benefit of, U.S. patent application Ser. No. 15/282,295 filed with the U.S. Patent and Trademark Office on Sep. 30, 2016, which is hereby incorporated herein by reference.
Virtualized computing environments are frequently supported by block-based storage. Such block-based storage is increasingly provided by solid state drives (SSDs). SSDs provide a block-style interface, making it easy to integrate these drives into systems that have traditionally relied on hard drives and other block storage devices. SSD drive manufacturers incorporate a controller which provides the block-style interface and which manages data storage and mapping. For example when a read or write request is received, it may include a logical block address associated with the request. The controller may determine a physical location on the SSD from where the data should be read, or to where the data should be written. The controller may also manage data storage on the SSD to improve the longevity of the device and manage other flash-specific functions. However, while the drive manufacturer may provide a controller that is suitable for the average customer, such controllers may not provide sufficient flexibility or customizability for all users and applications for which such drives may be deployed.
Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:
Systems and methods in accordance with various embodiments of the present disclosure overcome one or more of the aforementioned and other deficiencies experienced in conventional approaches to managing solid state drives (SSDs) in a block-based storage service in an electronic environment. In particular, SSD management features may be decoupled from a built in SSD controller and implemented in an external controller. The SSD management features may include indirection mapping and replay. An indirection mapping data structure can maintain a mapping between logical block addresses used by a host computer and physical data storage locations on an SSD. Updates to the indirection mapping data structure can be stored in journals. One or more journals may be associated with a cluster block, such that the journals store updates to the indirection mapping data structure for that cluster block. In various embodiments, a cluster block may include a grouping of physical erase blocks across an array of N contiguous die. The grouping of physical erase blocks may include the same block index from each die to simplify translation from logical to physical erase blocks. In embodiments using multi-plane programming on a die, P consecutive blocks from each of the N die can be grouped into a single cluster block, where P is the number of planes supported by the NAND die. When a journal has reached a predefined limit, the journal can be stored to a predetermined location on the cluster block determined based on the number of entries stored by the journal. In some embodiments, each journal'"'"'s predefined limit can be derived from a formula using one or more of the following as inputs: journal number, cluster block index number, cluster block sequence number. Such co-location at predetermined locations scattered throughout a cluster block is referred to as spatially coupled journaling. Further, each physical chunk of media in a cluster block, including defective/bad blocks that are not programmed, or other non-host data such as padding or other meta data, are captured in the journal. The journal is said to be physical media aware because of this direct mapping. When power is restored, following a power loss, the spatially coupled journals can be retrieved from the scattered predefined locations and used to rebuild the indirection mapping data structure.
As shown in
It will be appreciated that the example of
In various embodiments, the block-based storage service can expose the storage to the customers as a Web service. Customers can submit Web services requests, or other appropriate requests or calls, to allocate storage on those servers and/or access that storage from the instances provisioned for those customers. In certain embodiments, a user is able to access the data volumes of these storage devices as if those storage devices are conventional block devices. Since the data volumes will appear to the customer instances as if each volume is a disk drive or similar block device, the volumes can be addressed with offsets, lengths, and other such conventional block device aspects.
Traditional solid state drives (SSDs) include a controller that provides various drive and data management features. For example, SSDs store data persistently in flash cells; however data cannot be overwritten and instead must be first erased before new data can be stored. Additionally, each cell has a finite number of write/erase cycles before it can no longer reliably store data. As such, to effectively manage data storage, SSD-specific garbage collection, replay, and trim methods may be implemented by the SSD controller. As discussed above, these features are provided by drive manufacturers and may not be suitable for all users. Many of the features provided by the controller can be decoupled from the SSD in accordance with various embodiments.
Such indirection mapping tables can become quite large, increasing in size in proportion to the size of the SSD. The indirection mapping table may be maintained in volatile memory, such as RAM. This provides quick access to the mappings, but results in potential loss of the indirection mapping table in the event of a power failure or other unexpected power interruption. In various embodiments, and as discussed further below, a spatially coupled journaling scheme is implemented in which each time data is written to disk, a journal entry including logical address information. Based on the location of the journal entry, the corresponding physical location can be inferred. Each journal has a finite size, storing a maximum number of corresponding entries. In some embodiments all journals are of the same size. In some embodiments journals can be of variable size. Additionally, each physical chunk of media, whether defective or not, is journaled. By including a journal entry for every physical chunk of media, the journals can be stored at predetermined locations, regardless of the locations of defective blocks (e.g., bad blocks) on the disk. When the journal has reached a predefined limit, the journal is stored to the SSD within the same cluster block and immediately after the data it describes. As the journal includes a finite number of entries, corresponding to a known amount of disk space, the location of the journal on disk, relative to the start of a cluster block (or the last journal storage location) is known deterministically.
As discussed, a flash block must be in an erased state before data can be stored to it (e.g., data cannot be overwritten to the same physical location unless it is first erased). To accommodate these characteristics, data can be written sequentially to the next available page. When new data is written and associated with the same logical address as previously written data, the previously written data is invalidated. Garbage collector 210 can ensure erased cluster blocks are available to store data, and to reduce data fragmentation. Garbage collector 210 can include a journal selector 218 that can retrieve journals from the predetermined locations and determine whether the data is valid. Garbage collection engine 220 can then relocate data as needed or ignore the data, leading to it being erased when the cluster block is erased. Input/output manager 212 can manage read and write access to the SSD 206. In various embodiments, read manager 222 and write manager 224 may include read and write caches that store data requested to be read or written. In various embodiments, a trim manager 226 can enable a client device to indicate a range of logical addresses are stale and can be discarded. By enabling ranges of logical addresses to be marked stale by the client, garbage collection overhead can be reduced.
In some embodiments, each journal 404 can be the same size. Once the journal has filled all of its entries, it can be stored to cluster block 402. For example, the size of the journal can be made equal to the size of an indirection unit such that the journal can be written in a single write operation and the next journal can include entries starting with the next indirection unit. Since each journal is stored at a predetermined location, each journal includes entries that map a fixed amount of physical media to logical units. Where these logical units are of fixed size, each journal has a fixed number of journal entries. If the logical units are of variable sizes, e.g., where compression is used, journals are still stored at predetermined locations. To enable the journals to be stored at the predetermined locations, each journal may include a variable number of entries. When entries corresponding to the fixed amount of physical disk space have been journaled, the journal can be closed and stored at the predetermined location. In this example, each journal may include a different number of journal entries, but will be stored at predetermined locations and cover a fixed amount of physical disk space.
As shown in this example, each journal is stored at a physical location that is known deterministically from the beginning of the cluster block, based on the size of the journal. For example, each journal in
In some embodiments, the predetermined location where a journal is to be stored on the physical media may be defective (e.g., as of media production or due to use or other factor). In some embodiment, N contiguous locations on the physical media may be predetermined for each journal, where N can be defined to be any integer. For example, a predetermined location for a journal may correspond to 2 predetermined contiguous pages on an SSD. Although this increases the amount of space on the physical media dedicated to the journals, it provides layers of redundancy to ensure the fixed-location journaling scheme can still be used if one of the predetermined locations is defective. In some embodiments, defective locations can be remapped to non-defective locations logically. For example, a map of defective blocks mapped to journal locations can be maintained and remapped during device initialization to one or more non-defective locations. This remapping can be done by the SSD firmware or at the flash device level (if supported).
In some embodiments, where the number of dies in a cluster block is equal to or greater than the number of journals used in a cluster block, each journal can be stored to a different die. For example, as shown in
In some embodiments, if the number of dies in a cluster block is equal to or greater than double the number of journals used in a cluster block, then each journal can be duplicated and stored to a different die. If any die fails, no journals will be lost, as the corresponding copy can be recovered from its location on another die. Additionally, or alternatively, redundant array of independent disks (RAID) can be used to provide additional protection to the journals. For example, RAID 5 parity can be accumulated across all journals in the cluster block and saved for recovery in the event of a read failure on a journal.
Embodiments described above assume that each indirection entry corresponds to a fixed amount of disk space such that after a particular number of entries (e.g., the size of the journal) the journal is stored at a predetermined location. However, where compression algorithms are used, each entry may not correspond to the same amount of disk space. As such, if the journal is of fixed size and it is stored when it is filled, it may not be stored at a predetermined location. In some embodiments, a variable sized journal may be used that can be stored to disk upon detection that data has been written up to a predetermined location. For example, a write placement manager can keep track of write locations and cause the journal to be written to disk at a predetermined location. The journal can be closed and written to disk at the predetermined location regardless of the size of the journal, such that it can be later recovered from the predetermined location.
In some embodiments, because each journal is stored at a predetermined location, techniques may be used to reduce the likelihood of a defect at one of these locations. For example, some SSDs may be written in a single level cell (SLC) mode, where each cell stores a single bit of data, or a higher density storage mode such as multi-level cell (MLC) mode or triple level cell (TLC) mode where two bits or three bits, respectively may be stored per cell. SLC mode enables less data to be stored than MLC or TLC mode, but that data is stored more reliably. Accordingly, in some embodiments, user data may be stored to disk in MLC or TLC mode to maximize storage density. When a journal is stored in-line with the user data as discussed herein, it can be stored in SLC mode. This reduces the likelihood of a defect at the predetermined locations where the journals are stored, making the journals more robust. For example, journals 502, 504, 506, may be written in SLC mode, while all other indirection units shown in
In some embodiments, indirection manager 610 can enable client devices to read and update a given indirection entry. In various embodiments, indirection mapping table 606 can be implemented with different indirection granularity, depending on implementation needs. Indirection granularity may refer to the number of host data blocks (or sectors) that are referenced by one indirection unit in the indirection mapping table 606. For example, in some embodiments, an indirection granularity of 32 KiB may be used. If a drive is formatted as a 4 KiB block device, each indirection unit maps 8 sequential host sectors to 1 physical media location. In such embodiments, an indirection entry can be determined from a logical block address (LBA) of a sector by shifting off the lower three bits of the LBA. The indirection entry may indicate the die, block, and page corresponding to the LBA. To determine the sector within the indirection entry corresponding to the LBA, a mod operation can be performed. For example, in a 4 KiB block formatted drive, with a 16 KiB page size, and 32 KiB indirection unit, the first four sectors will be in the first block of the indirection unit and the second four sectors will be in the second block of the indirection unit.
In the event of an unexpected power loss, the size of the mapping table (e.g., approximately 4 GB for 32 TB) is large enough that maintaining sufficient power to store the map to non-volatile memory would be prohibitive. Instead, replay manager 614 can reconstruct indirection mapping table 606 using the spatially coupled journals. In various embodiments, replay manager 614 can initiate replay when a replay event is detected. Replay events may include a boot, upon recovery from power loss, upon receiving a replay request, etc. For example, during debugging, replay may be requested to be performed over an entire disk, or over a specific portion or portions of the media where errors were detected. In some embodiments, the first journal from each cluster block may be read from predetermined locations on each cluster block into memory 604. Using the cluster block sequence number from each journal, each cluster block may then be processed. For example, the journal from the first cluster block in the cluster block sequence can be read. As discussed, because the location of the journal is known, the size of the indirection units are known, and each physical chunk of media (including defective blocks) are journaled, the physical location of each indirection unit can be calculated without consulting any additional metadata. As such, when a logical block address is read in a journal entry, the corresponding physical location can be added to that LBA entry in the indirection mapping table. Each journal in the first cluster block may be retrieved from its predetermined location on disk and processed as discussed until the last journal on the cluster block has been processed and the indirection mapping table has been updated. Replay manager 614 can then move on to the next cluster block in the cluster block sequence. By processing each cluster block in order, physical locations of the stale data (e.g., mappings that are later changed) will be overwritten in the indirection mapping table such that once replay is complete, the indirection mapping table does not include stale mappings. By spatially coupling the journals at known locations on disk, replay can be performed without using checkpoints. Instead, journals can be read and processed in order to reconstruct the indirection mapping table.
In various embodiments, write placement manager 616 can receive write requests and push those writes to disk. In some embodiments, write placement manager 616 can include one or more write caches where write instructions are stored prior to being written to disk. When the write request is performed, journal manager 612 can update journal 608 accordingly. In some embodiments, multiple journal buffers can be allocated when a SSD is initialized. One journal can be marked active, with indirection entries added to the active journal. Once a journal storage event is detected, the journal can be written to disk and another journal, associated with another journal buffer, can be marked active. This enables write operations to be continuously pushed while the journal is being written without affecting response time.
In some embodiments, and as discussed further below, replay manager 614 may be configured to rebuild a defective block table, e.g., bad block map 618, during replay. As discussed, each portion of media is journaled, including defective blocks. This enables bad block map 618 to be reconstructed in case it is lost or corrupted. In some embodiments, bad block map 618, once recovered, can be stored from memory 604 to a non-volatile data store.
An indirection unit can be stored 704 to an indirection mapping table. The indirection unit maps the data to the physical data location in the cluster block on the SSD in the indirection mapping table. Data can be stored 706 to the SSD in response to a write request. Once the data has been stored, the indirection mapping table can be updated 708 to include a mapping to the physical data storage location where the data was stored. An entry can be added 710 to a journal using the indirection unit based on the write request. For example, an entry can be generated using a logical block address corresponding to the physical data location. In some embodiments, it can be determined 712 whether the next physical data location to be written to is defective. For example, an attempted read/write operation can be performed on the next physical data location. If an error is returned, the location can be determined to be defective. Additionally, or alternatively, the next physical data location can be looked up in a bad block map to determine whether it has already been identified as defective. If the next physical data location is determined to be defective, an entry can be appended 714 to the journal indicating the next physical data location is defective.
Journal entries can be appended to an active journal until a journal storage event is detected 716. If no journal storage event is detected, entries can continue being appended to the journal as write requests are received. Upon detecting the journal storage event, the journal can be stored 718 to a predetermined location. The predetermined location is co-located with the data in the cluster block. In some embodiments, the journal storage event may include determining that the journal includes a maximum number of journal entries. In some embodiments, the journal storage event can include determining that the journal includes a number of entries corresponding to a predetermined amount of disk space on the SSD. The journal can be stored in a journal buffer. In some embodiments, multiple journal buffers can be used, each storing a different journal.
In some embodiments, at the same time the active journal is written to disk, a new journal is opened in a different journal buffer. Subsequent updates to the indirection map can be stored 720 in the new journal. In some embodiments, a journal includes a header including a cluster block sequence number for the cluster block, and a content area including a plurality of entries mapping physical data locations of data on the cluster block to logical addresses.
A sequence number associated with a cluster block can be determined from the journal 806. For example, when a first journal is retrieved from each cluster block, the sequence numbers can be used to determine the order in which the cluster blocks are processed to rebuild the indirection mapping table. In some embodiments, the sequence number can be read from a header included in the journal. The indirection mapping table can be rebuilt 808 using the journals ordered by sequence numbers. Rebuilding the indirection mapping table can include creating 810 a new indirection mapping table. An entry can be read 812 from the current journal being parsed. As discussed, each portion of media is associated with a journal entry, including defective portions where no data is stored. The journal entry can be analyzed to determine 814 whether it includes a value indicating that the corresponding physical location is defective. If the journal entry does not indicate that it is defective, the new indirection mapping table can be updated 816 using the mapping data from the journal entry. If the journal entry does indicate that it is defective, then a bad block map can be updated 818 to include the corresponding physical location to the journal entry.
Once the journal entry has been processed, it can be determined 820 whether the end of the journal has been reached. If additional entries exist, processing may return to block 812 and the next entry can be processed. If the end of the journal has been reached, it can be determined 822 whether additional journals exist. In some embodiments, each journal may include journal header data. For example, the header may include a timestamp when the journal was written, when the first entry was written, when the last entry was written, or other data. Additionally, or alternatively, the journal header may include a total number of journals, updated each time a new journal is stored. In various embodiments, the data in the journal header may be used to determine an order in which to process the journals. If additional journals exist, the next journal can be retrieved 824 from its predetermined location and the entries of the next journal can be processed as discussed above with respect to blocks 812-820. If no additional journals exist, a notification can be sent 826 indicating replay is complete. Once complete, the indirection mapping table and bad block map have each been rebuilt. Although the embodiment of
As discussed, different approaches can be implemented in various environments in accordance with the described embodiments. As will be appreciated, although a Web-based environment may be used for many examples herein for purposes of explanation, different environments may be used, as appropriate, to implement various embodiments. Such a system can include one or more electronic client devices, which can include any appropriate device operable to send and receive requests, messages or information over an appropriate network and convey information back to a user of the device. Examples of such client devices include personal computers, cell phones, handheld messaging devices, laptop computers, set-top boxes, personal data assistants, electronic book readers and the like. The network can include any appropriate network, including an intranet, the Internet, a cellular network, a local area network or any other such network or combination thereof. Components used for such a system can depend at least in part upon the type of network and/or environment selected. Protocols and components for communicating via such a network are well known and will not be discussed herein in detail. Communication over the network can be enabled via wired or wireless connections and combinations thereof.
An illustrative environment can include at least one application server and data store. It should be understood that there can be several application servers, layers or other elements, processes or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. As used herein the term “data store” refers to any device or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed or clustered environment. The application server can include any appropriate hardware and software for integrating with the data store as needed to execute aspects of one or more applications for the client device and handling a majority of the data access and business logic for an application. The application server provides access control services in cooperation with the data store and is able to generate content such as text, graphics, audio and/or video to be transferred to the user, which may be served to the user by the Web server in the form of HTML, XML or another appropriate structured language in this example. The handling of all requests and responses, as well as the delivery of content between the client device and the application server, can be handled by the Web server. It should be understood that the Web and application servers are not required and are merely example components, as structured code discussed herein can be executed on any appropriate device or host machine as discussed elsewhere herein.
Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include computer-readable medium storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions. Suitable implementations for the operating system and general functionality of the servers are known or commercially available and are readily implemented by persons having ordinary skill in the art, particularly in light of the disclosure herein.
The environment in one embodiment is a distributed computing environment utilizing several computer systems and components that are interconnected via communication links, using one or more computer networks or direct connections. However, it will be appreciated by those of ordinary skill in the art that such a system could operate equally well in a system having fewer or a greater number of components than are illustrated. Thus, the depiction of any system herein should be taken as being illustrative in nature and not limiting to the scope of the disclosure.
As discussed above, the various embodiments can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices, or processing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of general purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless, and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system also can include a number of workstations running any of a variety of commercially-available operating systems and other known applications for purposes such as development and database management. These devices also can include other electronic devices, such as dummy terminals, thin-clients, gaming systems, and other devices capable of communicating via a network.
Various aspects also can be implemented as part of at least one service or Web service, such as may be part of a service-oriented architecture. Services such as Web services can communicate using any appropriate type of messaging, such as by using messages in extensible markup language (XML) format and exchanged using an appropriate protocol such as SOAP (derived from the “Simple Object Access Protocol”). Processes provided or executed by such services can be written in any appropriate language, such as the Web Services Description Language (WSDL). Using a language such as WSDL allows for functionality such as the automated generation of client-side code in various SOAP frameworks.
Most embodiments utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially-available protocols, such as TCP/IP, FTP, UPnP, NFS, and CIFS. The network can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.
In embodiments utilizing a Web server, the Web server can run any of a variety of server or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server(s) also may be capable of executing programs or scripts in response requests from user devices, such as by executing one or more Web applications that may be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++, or any scripting language, such as Perl, Python, or TCL, as well as combinations thereof. The server(s) may also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase®, and IBM®.
The environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers, or other network devices may be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad), and at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as random access memory (“RAM”) or read-only memory (“ROM”), as well as removable media devices, memory cards, flash cards, etc.
Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed, and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or Web browser. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.
Storage media and other non-transitory computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, such as but not limited to volatile and non-volatile, removable and non-removable non-transitory media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the a system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.