In a network environment, data may be maintained on a server and separate copies of the data may be maintained on different clients or other storages on the network. Synchronization of data tends to break down when more than one data store is introduced to maintain data because management of a large amount of pairwise validations becomes both unmaintainable and unreliable. It is with respect to this general technical environment that the present application is directed.
Examples of the present disclosure describe validation of data on a client having a plurality of data stores. A data consistency component of the client queries a plurality of data stores of the client to identify a portion of data from each of the data stores. The data consistency component compares portions of data obtained from the plurality of data stores using stored knowledge data, maintained by the data consistency component. Based on the comparison of the portions of data, the data consistency component identifies if inconsistency exists across the plurality of data stores. Inconsistency identified for any of the plurality of data stores is reported.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additional aspects, features, and/or advantages of examples will be set forth in part in the description which follows and, in part, will be apparent from the description, or may be learned by practice of the disclosure.
Non-limiting and non-exhaustive examples are described with reference to the following figures.
The present disclosure describes systems and methods for increasing integrity and consistency when performing validation of data that persists across multiple data stores. One way to maintain synchronization between data stores is to perform a full enumeration of data on data stores. A full enumeration of data updates values for all data stored in a data store using a remote source such as a network server. However, when a full enumeration of data is performed, a large amount of network and input/output (I/O) resources may be tied up causing increased network bandwidth and latency issues among other problems. Examples of the present disclosure describe efficient ways of maintaining a quality replica of data without requiring a new full replica of data to be retrieved from another network component/storage or requiring that a full enumeration of data be performed on an entire data store. Additionally, among other features, the present disclosure enables detection of data inconsistencies before a user may become aware of such inconsistencies such as errors in files maintained on a user-operated client.
As an example, the system 100 may be used to run software components such as applications or services enabling clients or users to access and manage data. The system 100 may implement protocols or frameworks to oversee applications, services, processes, etc., running on a local component of the system 100 such as local component A, 104, local component B 106 or local component C 108. In one example, the system 100 may run a file hosting application or service, allowing clients or users to upload and sync files to a storage such as a distributed network (e.g., cloud storage). The file hosting application/service may allow clients to access files using an application (e.g. web browser) running on the local component such as a local device (e.g., mobile device, computer, laptop tablet or any device having a processor). File hosting applications/services may be associated with online services and allow users to keep files private, share them with contacts, or make files public. Examples of such filing hosting applications/services may be iterations of any distributed storage solution including Google Drive, iCloud, IBM SmartCloud, Dropbox, SugarSync, Syncplicity, OwnDrive, OneDrive, SkyDrive, Windows Live SkyDrive, and Windows Live Folders, among other examples. Other types of applications or services related to data synchronization may also be applicable.
System 100 may include a knowledge component 102 or data repository that may be used to store data for a network (e.g., a distributed computing environment such as a cloud-based environment). The knowledge component 102 may be comprised of one or more processing devices, storages, or combination thereof. An exemplary knowledge component 102 may be a server or any network storage device that stores information that is distributable to local components to enable local components to perform validation of data stores/data stored locally on a local component. As an example, information stored and distributed by the knowledge component 102 may include data identifying components of the system 100, definitions data for components of the system 100, policy rules for executing validations and any other information or data relevant to enable a local component of the system 100 to manage validation of its own components. As an example, the knowledge component 102 may store a master list of all files maintained by the system 100, for example in a normalized form. The knowledge component 102 may transfer information to a local component to assist a local component in management data. In one example, a local component may de-normalize data across multiple data stores. The knowledge component 102 may transmit information to aid a local component in managing its de-normalized data. Moreover, the knowledge component 102 interfaces with local components of the system 100, such as local component A 104, local component B 106, and local component C 108, to provide a local component with information usable in performing validation.
The local components illustrated in
A data store of a local component may be a subsystem of file data including files and folders of information. Examples of data stored by an individual data store of the local component may include but are not limited to the following types of data: validation data, metadata, a store for metadata about files on the file system, folder description information, and operating system data, among other examples. As identified above, a local component may comprise a plurality of data stores. Data stores may store or maintain different data (e.g., different types/forms). In one example, a data store of a local component may store files data for files maintained on a network server that may be a component of system 100 and another data store may store data for files persisted to disk. Knowledge data may be maintained by the local component to identify relationships between such data and enable validation to be performed across the different data stores. Other examples of data that knowledge data is maintained for may include but are not limited to synchronization information and binary file information maintained by data stores of a local component.
Each local component may include a data consistency expert 107. A data consistency expert 107 is a component to locally manage synchronization of data stores of the local component. A data consistency expert 107 manages validation of components associated with multiple data stores of a local component. As an example, a data consistency expert 107 may be software running on a local component such as a processing device or client device. As an example, the data consistency expert 107 may mirror information stored on the knowledge component 102. In some cases, a data store that is part of a local component may not be able to stay up to date with respect to transactions that occur on each of the data stores of the local component or other local components. As such, the data stores may have difficulty coordinating with each other and consistency of data replicated across data stores may be lost. The data consistency expert 107 is an example of a central authority on the local component that is used to maintain synchronization of data stored on a local component(s). As one example, the data consistency expert 107 enables the system 100 with many data stores to identify inconsistencies between data stores that may be unknown to individual data stores. The data consistency expert 107 may further identify files having inconsistencies that can result in errors that may negatively affect an end user experience, if the inconsistencies are not addressed. In yet another example, the data consistency expert 107 enables a reporting of inconsistency data (e.g., a validation error) to the telemetry component 110 of the system 100. Further, the data consistency expert 107 enables external validation of data stores to enhance maintenance of data integrity amongst data stores.
As an example, the data consistency expert 107 may perform validation of components of a local component or local components. As an example, the data consistency expert 107 may include a validator that manages validation/validations for a local component. In one example, the validator may define a schedule to ensure that validation of components occurs on a consistent basis. The validator may receive, compile, evaluate, and utilize knowledge data transmitted from the knowledge component 102 to identify all types of components that are able to be validated on a local component. In one example, the validator of the data consistency expert 107 may set and execute individual validation tasks, each of which evaluates validatable components to determine whether an inconsistency is present among data stores of a local component. In that example, validation of components may occur in one or more tasks. When the validator determines that a validation is to be performed, the validator may take as an input, an array of one or more validatable components and may perform validation each of each validatable component. Validation of components may occur at the same time. However, in other examples, validation of components may occur at different times. The validator of the data consistency expert 107 may use a smart heuristic to improve scheduling of evaluating of validatable components. A smart heuristic may be any component (hardware or software) of the data consistency expert 107 that is capable of analyzing data and making a decision to improve processing for the data consistency expert 107. In one example, the validator may utilize the smart heuristic to determine optimal times to perform validation on components of a local component. In one instance, the smart heuristic may determine a time where performance of the system 100 is less utilized and thus, efficiency in scheduling can be achieved. In one example, the smart heuristic may identify times where processing resources of a local component have greater availability so that the validator can control performance of validation (e.g., start and stop) to accommodate for changes in processing. When a validation is completed, the data consistency expert 107 may store results of validations locally for use by a repair function or for local diagnostic use at a later date. The results for a validation are also communicated to a telemetry component 110 for evaluation.
The telemetry component 110 may receive data related to performance of a validation(s) from any local component of the system 100 such as local component A 104, local component B 106 or local component C 108. Communication lines labeled 105 in
As an example, the data consistency component 202 may manage registry keys related to running of a task for validation of a component of the local component 200. Registry keys may be set for the following to control functionalities including but not limited to:
As in examples describing a data consistency expert 107 of
For example, validation of a component may include checking specific information managed by the validatable component with respect to a data store of the local component 200. Validation may include validating specific file identification information, pathways associated with data maintained by the data store (e.g., file/folder), modifications of data related to a data store, etc. As an example, validation of a single component may include performing a plurality of validation checks. A validation check uses one or more computational rules to determine if specific data related to the validatable component is valid. As data stores (or subsystems) may manage different data, validation may differ depending on a subsystem that is being validated. As an example, in a case where a validation component is related to synchronization of data, validation checks may differ compared with a validation relating to management of monitoring changes in a file directory. Validation rules, definitions, routines, etc., used to perform validation (including validation checks) may be managed and set by the data consistency component 202 and executed using the validator. The data consistency component 202 may manage knowledge data to enable performance of validation. As an example, knowledge data may include data identifying validatable components, definitions of validatable components, policy rules for executing validations and any other information or data relevant to enable a local component 200 to manage validation. Exemplary knowledge data may identify relationships between data stores (e.g., store A 206, store B 208, store C 210, store D 212, store E 214 and store F 216) of the local component 200. As an example, knowledge data may be used by the data consistency component 202 to match a portion or portions of data of a data store with a portion or portions of data of another data store. The data consistency component 202 may compare portions of data (e.g., tables, columns, lines, rows, etc.) obtained from the plurality of data stores using knowledge data to identify inconsistencies between data stores of a local component 200.
The validator of the data consistency component 202 may perform validation of components in order to identify existing or potential issues that may affect an experience of an end user of the local component 200. Performance of a validation may be pre-scheduled to execute (e.g., every 12 hours) or may be executed based on a request (e.g., received from an administrator or by a component of the local component 200). In one example, performance of validation may occur in one or more assigned tasks. A task run by the validator of the data consistency component 202 may perform validation of a validatable component related to a data store of the local component 200. In performing a validation, the validator may evaluate a data store as a whole, including file data maintained by a data store of the local component 200, to identify inconsistencies in the data store. In another example, the validator may compare portions of data across multiple data stores (e.g, store data stores (e.g., store A 206, store B 208, store C 210, store D 212, store E 214 and store F 216) of the local component 200, to determine inconsistencies among data stores. As data stores of the local component 200 may have different relationships, dimensions of relational aspects between data stores may be validated. For example, validations may be performed on data associations (e.g., one-one one-many, many-many) between data stores.
The data consistency component 202 may use results of validation performance to identify inconsistencies among data stores a local component 200. In some examples, a validatable component may initiate a request to execute a validation. In that example, the data consistency component 202 may receive a request from a component of a data store, and perform validation.
In one example, the data consistency component 202 may compare validatable components of one or more data stores of the local component 200 against data maintained by the data consistency component 202. In an example, validation may be iterated through some or all of the files of a data store and ensure that data such as metadata associated with a validatable component in each of the other stores matches data maintained by the data consistency component 202. In another example, the data consistency component 202 may obtain validatable components (e.g., files or data) from each of a plurality of data stores of the local component 200. The data consistency component 202 may perform validation on each validatable component including a comparison of a specific validatable component across each data store of the local component 200. For example, a portion of data may be received from store A 206. When the data consistency component 202 performs validation on the portion of data received from store A 206, the data consistency component 202 uses knowledge data to identify portions of data in other data stores of the local component 200 that relate to the portion of data received from store A 206. As an example, the portion of data for store A 206 may relate to rows of data 10-12 in a file maintained on store A 206 or a portion of metadata from file. The data consistency component 202 may use the knowledge data to determine that the data of store A 206 being validated corresponds to a portion of data (e.g., rows 13-15) of a file maintained in store D 212. Validation may be performed by comparing such portions of data for store A 206 and store D 212. Additionally, a comparison performed in the validation may be a comparison of many data stores. This enables the data consistency component 202 to identify when data stores of the local component 200 may be out of sync and what components of an overall system could be queuing changes that cause data stores to lose synchronization. As another example, a validation may comprise evaluating aspects of a file directory component, that manages a list of file changes occurring on a data store of the local component 200, by comparing state data for a file maintained by the data store with state data for data (e.g., file/folder) managed by the data consistency component 200 (e.g., the validator). State information may be any information that identifies a current state of data. The data consistency component 202 may further evaluate and compare state data of more than one data store associated with the local component 200.
When performing validation, the data consistency component 202 may request a data store of the local component 200 to provide any data that may be useful to validate a validatable component (e.g. metadata or file data) of all files in a subsystem (e.g., data store). As an example, data may be provided to the data consistency expert 202 by a data store of the local component 200 on a per library basis. Using a synchronization component as an example of a component that a validation is performed on, the data consistency component 202 may evaluate data received from a data store and compare the data store(s) to determine, among other things: 1) whether the data store(s) being compared have the same set of file data persisting thereon as a master file maintained by the data consistency component 202, and 2) do the files maintained on a data store correctly match the master files maintained by the data consistency component 202. Master file data maintained by the data consistency component 202 may be a set of data usable to maintain synchronization between data stores of the local component 200. As an example, the data consistency component 202 runs a task that some set of data stores in an overall system. An example task may be a task that compares files stores on a local operating system (OS) with other data stores of the local OS. In that exemplary task, relevant files are run through to ensure that the metadata in each of the data stores matches that of a file system. Continuing that exemplary task, the data stores may also be compared to ensure that the same files are represented in the data stores.
The data consistency component 202 may use a unique identifier (e.g., server file ID) or foreign key to identify files and folders of a data store for comparison. As an example of comparing whether file data matches that of the data consistency component 202, metadata about a file path may be evaluated. As end users may have modified files (e.g., changing a location of a file by moving it to another folder or renaming the file), it is likely that there may be a difference between file data stored in a particular data store and the master file data maintained by the data consistency component 202. Such differences can be determined, reported and corrected before a user experiences issues. Identifying specific validation components that cause issues affords a system or service an opportunity to specifically identify issues related to file data and implement efficient means to correct such file issues before the issues manifest to a user. For example, updates may be performed specifically for inconsistencies identified with respect to a validatable component including modification to specific data associated with the validatable component (such as metadata), without having to perform a full enumeration of data persisting on a data store. Additionally, a quality replica of data is able to be maintained locally without requiring a new replica of data to be retrieved from another network component/storage such a shared server when a validation inconsistency is detected. Thus, network resources can be efficiently managed so that a user doesn't have to experience issues when using a user interface, and the local component 200 is not required to tie up network resources to obtain updated file information if consistency is lost between data stores. Furthermore, data stores across the local component 200 may be efficiently updated using the system-wide data consistency component 202.
Moreover, the local component 200 may be configured to transmit validation results to a telemetry component such as the telemetry component 110 of
Flow begins at operation 302 where a client (e.g., local component) identifies data for validation. In one example, a data store of a local client may request validation of data and submit the data for validation to a data consistency component of client to perform validation. In another example, a data consistency component of a client may identify the data for validation. In various examples, performance of validation may be scheduled or un-scheduled. In one example, performance of validation may be initiated by a component of a data store, for instance, when a change occurs to data in a data store. As another example, the data consistency component may perform validation in association with a schedule to attempt to maintain consistency among data stores of the client.
Once data is identified for validation, validation may be performed on the identified data (operation 304). In some cases, a validation may be performed in the background of an OS of the client without requiring a user of the client to initiate or manage a validation. For example, a user of the client may be operating an application in the foreground of the OS while a validation occurs in the background of the OS. As an example, the data consistency component may provide a user of the client with notification that a validation is running. In performing validation, the data consistency component may send a query to a local data store (or data stores) requesting data to perform a validation. The query may include a request (or multiple requests) for data related to a validatable component. In response to receiving a query from the data consistency component, a data store (or data stores) of the client sends data from the data store to the data consistency expert for evaluation. In one example, performance of the validation may include execution of several sub-tests of validatable components. Performance of validation may comprise taking an array of validatable components and executing operations to validation each validatable component. In some examples, validation of each component of a validation does not need to occur at the same time. Operation 304 may include comparing, using knowledge data, maintained on the client, portions of data obtained from a plurality of data stores. The knowledge data used in performing a comparison may be data identifying relationships between portions of data obtained from the plurality of data stores.
Flow may then proceed to operation 306, where validation differences or inconsistencies are identified. The data consistency component may determine differentiations between data maintained by a data store and data maintained by the data consistency component or other data stores. Data is evaluated to determine various possible variations and causes of the variations. For each mismatch determined, a unique identifier is assigned. When a mismatch is identified with regard to data of a data store, an error may be generated for evaluation. The error generated identifies the unique identifier of the error for reporting purposes.
Once errors are detected, method 300 proceeds to operation 308 where the inconsistencies identified in any of the plurality of data stores are reported. As an example, inconsistencies may be reported to an administrative component such as a telemetry component 110, examples of which are described in
Flow begins at operation 402 where the telemetry component receives reporting of validation inconsistencies identified with respect to data stores of a client or local component. The data may be included in one or more reports. Inconsistencies may be identified by unique identifiers. Reporting of inconsistencies may be received by the telemetry component from a client or local component. As an example, reporting may be sent from a central authority of a client (e.g., data consistency expert/component), which identifies inconsistences existing with respect to data stores of the client. The telemetry component may implement an administrative tool or service that is used for presenting and evaluating inconsistency information. The administrative tool may be an application, service, or device running an application or service that is used to monitor functions related to validation and error detection. As an example, the administrative tool may be a dashboard application providing a real-time user interface showing presentations of current status and historical trends related to validation and error detection. The administrative tool may be connected to each and any component of a system and generate guiding metrics related to analysis performed on components of the system. Furthermore, the administrative tool may be modifiable and adaptable to collect and evaluate any type of information, for example related to tracking of validatable components and inconsistency detection. Among other things, the administrative tool may be usable to show summary data, key trends, comparisons, exceptions, etc.
Once an inconsistency reporting is received by the telemetry component, flow proceeds to operation 404 where the administrative reporting tool aggregates inconsistency information received from the client. In one example, data reported by the client (e.g., local component) may be aggregated with data received from other clients (e.g., local components) across a network. Statistical analysis may be performed on the combined data to form accumulated data. As an example, the administrative tool may form or group the different inconsistencies into groups or clusters. In other examples, the administrative tool may perform statistical analysis on inconsistency information, general information related to a client of a network or any other information related to performance of validation.
Once the inconsistency information is aggregated, the administrative tool may generate a report for the aggregated inconsistency information (operation 406). The report may be a validation report highlighting summary of empirical data for validatable components. In one example, the report generated may include graphical representations of data displayed through a user interface. As an example, the generated report may be a report based on the accumulated data including data on validation executed on local components of the network and data on inconsistencies identified across the local components of the network.
The administrative tool may further generate health metric information relating to analysis of validation and error information aggregated by the administrative tool. Health metric data may be data used by an administrator and/or end user to provide information that is used for both evaluation and repair of inconsistencies identified. Health metric data is not solely related to elements that are immediately visible to an end user, but may be used by administrators to identify and evaluate inconsistencies before such issues manifest to an end user. However, in some examples, an end user may be able to receive health metric data so that the user is informed and may take proactive steps to minimize inconsistencies.
Metric data displayed in the report 410 may be any telemetered condition information. Examples of metric data aggregated and displayed in the report 410 include information related to validations performed on client components. One or more groupings of metric data may be displayed in the report via a user interface. As shown in exemplary report 410, metric data may include information on unique users running validation (block 412), percent (%) of users reporting inconsistency (block 414), and inconsistency type breakdown (block 416), among other examples. Each of blocks 412, 414 and 416, respectively, may be illustrated in a graphical representation. Data may be compiled and displayed for one or more users (clients) of a system or network. Users of administrators of the monitoring application may selectively configure the monitoring application for report generation. The information on unique users running validation (block 412) is aggregated data on users (e.g., of client devices) that have or are currently performing validation. As an example, data may be aggregated for block 412 over a predetermined period of time as shown in report 410. The information on percent (%) of users reporting inconsistency (block 414) is aggregated data on local client components of users (e.g., of client devices) that an inconsistency was identified on. As an example, data may be aggregated for block 414 over a predetermined period of time as shown in report 410. The information on inconsistency type breakdown (block 416) is aggregated data on types of inconsistencies identified on local client components of users (e.g., of client devices). As an example, data of block 416 may be broken down by unique identifiers for inconsistencies identified across clients of a system or network.
As stated above, a number of program modules and data files may be stored in the system memory 506. While executing on the processing unit 504, the program modules 508 (e.g., virtual file system 108, Input/Output (I/O) manager 524, and other utility 526) may perform processes including, but not limited to, one or more of the stages of the operational flows illustrated in
Furthermore, examples of the invention may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. For example, examples of the invention may be practiced via a system-on-a-chip (SOC) where each or many of the components illustrated in
The computing device 502 may also have one or more input device(s) 512 such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc. The output device(s) 514 such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. The computing device 504 may include one or more communication connections 516 allowing communications with other computing devices 518. Examples of suitable communication connections 516 include, but are not limited to, RF transmitter, receiver, and/or transceiver circuitry; universal serial bus (USB), parallel, and/or serial ports.
The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, or program modules. The system memory 506, the removable storage device 509, and the non-removable storage device 510 are all computer storage media examples (i.e., memory storage.) Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article of manufacture which can be used to store information and which can be accessed by the computing device 502. Any such computer storage media may be part of the computing device 502. Computer storage media does not include a carrier wave or other propagated or modulated data signal.
Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
One or more application programs 666 may be loaded into the memory 662 and run on or in association with the operating system 664. Examples of the application programs include phone dialer programs, e-mail programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, messaging programs, and so forth. The system 602 also includes a non-volatile storage area 668 within the memory 662. The non-volatile storage area 668 may be used to store persistent information that should not be lost if the system 602 is powered down. The application programs 666 may use and store information in the non-volatile storage area 668, such as e-mail or other messages used by an e-mail application, and the like. A synchronization application (not shown) also resides on the system 602 and is programmed to interact with a corresponding synchronization application resident on a host computer to keep the information stored in the non-volatile storage area 668 synchronized with corresponding information stored at the host computer. As should be appreciated, other applications may be loaded into the memory 662 and run on the mobile computing device 600, including IO manager 524, other utility 526 and applications 528 described herein.
The system 602 has a power supply 670, which may be implemented as one or more batteries. The power supply 670 might further include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.
The system 602 may include peripheral device port 678 that performs the function of facilitating connectivity between system 602 and one or more peripheral devices. Transmissions to and from the peripheral device port 672 are conducted under control of the operating system 664. In other words, communications received by the peripheral device port 678 may be disseminated to the application programs 666 via the operating system 664, and vice versa.
The system 602 may also include a radio 672 that performs the function of transmitting and receiving radio frequency communications. The radio 672 facilitates wireless connectivity between the system 602 and the “outside world,” via a communications carrier or service provider. Transmissions to and from the radio 672 are conducted under control of the operating system 664. In other words, communications received by the radio 672 may be disseminated to the application programs 666 via the operating system 664, and vice versa.
The visual indicator 620 may be used to provide visual notifications, and/or an audio interface 674 may be used for producing audible notifications via the audio transducer 625. In the illustrated example, the visual indicator 620 is a light emitting diode (LED) and the audio transducer 625 is a speaker. These devices may be directly coupled to the power supply 670 so that when activated, they remain on for a duration dictated by the notification mechanism even though the processor 660 and other components might shut down for conserving battery power. The LED may be programmed to remain on indefinitely until the user takes action to indicate the powered-on status of the device. The audio interface 674 is used to provide audible signals to and receive audible signals from the user. For example, in addition to being coupled to the audio transducer 625, the audio interface 674 may also be coupled to a microphone to receive audible input, such as to facilitate a telephone conversation. In accordance with examples of the present invention, the microphone may also serve as an audio sensor to facilitate control of notifications, as will be described below. The system 602 may further include a video interface 676 that enables an operation of an on-board camera 630 to record still images, video stream, and the like.
A mobile computing device 600 implementing the system 602 may have additional features or functionality. For example, the mobile computing device 600 may also include additional data storage devices (removable and/or non-removable) such as, magnetic disks, optical disks, or tape. Such additional storage is illustrated in
Data/information generated or captured by the mobile computing device 600 and stored via the system 602 may be stored locally on the mobile computing device 600, as described above, or the data may be stored on any number of storage media that may be accessed by the device via the radio 672 or via a wired connection between the mobile computing device 600 and a separate computing device associated with the mobile computing device 600, for example, a server computer in a distributed computing network, such as the Internet. As should be appreciated such data/information may be accessed via the mobile computing device 600 via the radio 672 or via a distributed computing network. Similarly, such data/information may be readily transferred between computing devices for storage and use according to well-known data/information transfer and storage means, including electronic mail and collaborative data/information sharing systems.
In a non-limiting examples systems, computer-implemented methods and computer-readable storage devices are implemented to validate data across a plurality of data stores of a local device or client. In examples, a plurality of data stores of a client are queried by a data consistency component maintained on the client, to identify a portion of data from each of the plurality of data stores. Validation is performed on the portions of data by comparing the portions of data from the plurality of data stores using knowledge data maintained by the local device or client. Inconsistency is identified across the plurality of data stores based on the comparing of the portions of data. Inconsistency identified in any of the plurality of data stores is reported. In one example, the querying further comprises identifying, using the knowledge data, a portion of data in a first data store of the plurality of data stores that is associated with a portion of data in each of the other data stores of the plurality of data stores. The comparing compares the portion of data in the first data store with one or more portions of data in the other data stores that are associated to identify inconsistency between the portions of data of the plurality of data stores. In one example, the comparing further comprises comparing each of the portions of data from the plurality of data stores that are associated against data maintained by the data consistency component to identify inconsistency in data maintained in any of the plurality of data stores. For instance, the comparing of the portions of data further comprises comparing at least two data stores of the plurality of data stores having subsets of metadata for a file to determine if metadata from the at least two data stores matches, and identifying inconsistency when the subsets of metadata do not match. In yet another example, comparing further comprises comparing a whole file of a first data store and a whole file of a second data store to determine if a same whole file is represented in the at least two data stores to identify inconsistency when whole files of at least the first data store and at least the second data store do not match. When inconsistency is identified in one or more portions of data of the plurality of data stores, the inconsistency is remediated.
Reference has been made throughout this specification to “one example” or “an example,” meaning that a particular described feature, structure, or characteristic is included in at least one example. Thus, usage of such phrases may refer to more than just one example. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples.
One skilled in the relevant art may recognize, however, that the examples may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well known structures, resources, or operations have not been shown or described in detail merely to observe obscuring aspects of the examples.
While sample examples and applications have been illustrated and described, it is to be understood that the examples are not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems disclosed herein without departing from the scope of the claimed examples.
This application claims the benefit of U.S. Provisional Application No. 62/064,562, filed on Oct. 16, 2014, which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
62064562 | Oct 2014 | US |