Abstract: A distributed file system for devices is described. In an embodiment, each data element stored on one of the devices has an associated location and availability attribute. The location attribute is stored co-located with the data element. The availability attribute and a copy of the location attribute are stored by a metadata service. When a client on a device needs to access a data element, it sends a request to the metadata service to find the location of the data element. If the data element is available, this information is provided to the client and this may involve waking a dormant device which holds the data element. Where the data element is not available, read only access may be granted to a cached copy of the data element. Where replication is used and one of the devices holding a replica is unavailable, the system may use write off-loading.

Abstract: A distributed file system for devices is described. In an embodiment, each data element stored on one of the devices has an associated location and availability attribute. The location attribute is stored co-located with the data element. The availability attribute and a copy of the location attribute are stored by a metadata service. When a client on a device needs to access a data element, it sends a request to the metadata service to find the location of the data element. If the data element is available, this information is provided to the client and this may involve waking a dormant device which holds the data element. Where the data element is not available, read only access may be granted to a cached copy of the data element. Where replication is used and one of the devices holding a replica is unavailable, the system may use write off-loading.

Abstract: A distributed file system for devices is described. In an embodiment, each data element stored on one of the devices has an associated location and availability attribute. The location attribute is stored co-located with the data element. The availability attribute and a copy of the location attribute are stored by a metadata service. When a client on a device needs to access a data element, it sends a request to the metadata service to find the location of the data element. If the data element is available, this information is provided to the client and this may involve waking a dormant device which holds the data element. Where the data element is not available, read only access may be granted to a cached copy of the data element. Where replication is used and one of the devices holding a replica is unavailable, the system may use write off-loading.

Abstract: A distributed file system for devices is described. In an embodiment, each data element stored on one of the devices has an associated location and availability attribute. The location attribute is stored co-located with the data element. The availability attribute and a copy of the location attribute are stored by a metadata service. When a client on a device needs to access a data element, it sends a request to the metadata service to find the location of the data element. If the data element is available, this information is provided to the client and this may involve waking a dormant device which holds the data element. Where the data element is not available, read only access may be granted to a cached copy of the data element. Where replication is used and one of the devices holding a replica is unavailable, the system may use write off-loading.

Abstract: A distributed file system for devices is described. In an embodiment, each data element stored on one of the devices has an associated location and availability attribute. The location attribute is stored co-located with the data element. The availability attribute and a copy of the location attribute are stored by a metadata service. When a client on a device needs to access a data element, it sends a request to the metadata service to find the location of the data element. If the data element is available, this information is provided to the client and this may involve waking a dormant device which holds the data element. Where the data element is not available, read only access may be granted to a cached copy of the data element. Where replication is used and one of the devices holding a replica is unavailable, the system may use write off-loading.

Abstract: Resource control for virtual datacenters is described, for example, where a plurality of virtual datacenters are implemented in a physical datacenter to meet guarantees. In examples, each virtual datacenter specifies a plurality of different types of resources having throughput guarantees which are met by computing, for individual flows of the virtual data centers implemented in the physical datacenter, a flow allocation. For example, a flow allocation has, for each of a plurality of different types of physical resources of the datacenter used by the flow, an amount of the physical resource that the flow can use. A flow is a path between endpoints of the datacenter along which messages are sent to implement a service. In examples, the flow allocations are sent to enforcers in the datacenter, which use the flow allocations to control the rate of traffic in the flows.

Abstract: Controlling data storage input/output requests is described, for example, to apply a policy to an end-to-end flow of data input/output requests between at least one computing entity and at least one store. In various examples a plurality of queues are configured at one or more stages of the end-to-end flow and controlled to adhere to a policy. In examples, each stage has a control interface enabling it to receive and execute control instructions from a controller which may be centralized or distributed. For example, the control instructions comprise queuing rules and/or queue configurations. In various examples queues and queuing rules are dynamically created and revised according to feedback about any of: flow behavior, changes in policy, changes in infrastructure or other factors. In examples, high level identifiers of the flow endpoints are resolved, on a per stage basis, to low level identifiers suitable for use by the stage.

Abstract: Controlling data storage input/output requests is described, for example, to apply a policy to an end-to-end flow of data input/output requests between at least one computing entity and at least one store. In various examples a plurality of queues are configured at one or more stages of the end-to-end flow and controlled to adhere to a policy. In examples, each stage has a control interface enabling it to receive and execute control instructions from a controller which may be centralized or distributed. For example, the control instructions comprise queuing rules and/or queue configurations. In various examples queues and queuing rules are dynamically created and revised according to feedback about any of: flow behavior, changes in policy, changes in infrastructure or other factors. In examples, high level identifiers of the flow endpoints are resolved, on a per stage basis, to low level identifiers suitable for use by the stage.

Abstract: Mobile device localization using audio signals is described. In an example, a mobile device is localized by receiving a first audio signal captured by a microphone located at the mobile device and a second audio signal captured from a further microphone. A correlation value between the first audio signal and second audio signal is computed, and this is used to determine whether the mobile device is in proximity to the further microphone. In one example, the mobile device can receive the audio signals from the further microphone and calculate the correlation value. In another example, a server can receive the audio signals from the mobile device and the further microphone and calculate the correlation value. In examples, the further microphone can be a fixed microphone at a predetermined location, or the further microphone can be a microphone located in another mobile device.

Abstract: Methods of classifying a storage traffic stream in a shared storage network are described. In an embodiment, an identifier for the entity generating the stream is generated, where this entity may, for example, indicate a virtual machine, program, session, physical machine, user or process. The identifier is then shared with at least one processing layer along a path of the storage traffic stream between the generating entity and the storage device which stores the file to which the traffic stream relates. In various embodiments, the identifier may then be used by any processing layers which receive it, to selectively handle traffic streams based on the generating entity. The identifier may be shared when the traffic stream is created or subsequently and in various embodiments, the identifier is shared in a second exchange of messages, following the creation of the traffic stream and prior to any other traffic.

Abstract: Mobile device localization using audio signals is described. In an example, a mobile device is localized by receiving a first audio signal captured by a microphone located at the mobile device and a second audio signal captured from a further microphone. A correlation value between the first audio signal and second audio signal is computed, and this is used to determine whether the mobile device is in proximity to the further microphone. In one example, the mobile device can receive the audio signals from the further microphone and calculate the correlation value. In another example, a server can receive the audio signals from the mobile device and the further microphone and calculate the correlation value. In examples, the further microphone can be a fixed microphone at a predetermined location, or the further microphone can be a microphone located in another mobile device.

Abstract: A data store including a file location attribute is described. In an embodiment, the location attribute for a data element, such as a file or database record, is stored with the bytes of data and records the geographic location of the data element. Writing to this attribute is limited to a single trusted entity, such as an operating system, to ensure that the location data can be trusted and when a data element is moved or replicated, the attribute is updated to reflect the new location of the data element. This location data is made available to users and applications by a metadata service which tracks the locations of data elements and responds to requests from users. Access control policies can been defined in terms of location and stored at the metadata service and the metadata service can then enforce these policies when responding to requests.

Abstract: Methods for reducing the power consumption of distributed storage systems are described. An embodiment describes a storage system which is adapted to reduce its power consumption at times of low load by reducing the number of active versions of the stored data. The data to be stored in the storage system is divided into chunks and in an example, each chunk is replicated on a number of different servers. At times of low load, the system enters a mode of operation in which the number of active replicas is reduced and servers that do not store any active replicas are put into a low power state. When in this mode, writes are written to a versioned store and the data is subsequently copied to servers storing replicas once all the servers have returned to normal power state.

Abstract: Mobile device localization using audio signals is described. In an example, a mobile device is localized by receiving a first audio signal captured by a microphone located at the mobile device and a second audio signal captured from a further microphone. A correlation value between the first audio signal and second audio signal is computed, and this is used to determine whether the mobile device is in proximity to the further microphone. In one example, the mobile device can receive the audio signals from the further microphone and calculate the correlation value. In another example, a server can receive the audio signals from the mobile device and the further microphone and calculate the correlation value. In examples, the further microphone can be a fixed microphone at a predetermined location, or the further microphone can be a microphone located in another mobile device.

Abstract: A distributed file system for devices is described. In an embodiment, each data element stored on one of the devices has an associated location and availability attribute. The location attribute is stored co-located with the data element. The availability attribute and a copy of the location attribute are stored by a metadata service. When a client on a device needs to access a data element, it sends a request to the metadata service to find the location of the data element. If the data element is available, this information is provided to the client and this may involve waking a dormant device which holds the data element. Where the data element is not available, read only access may be granted to a cached copy of the data element. Where replication is used and one of the devices holding a replica is unavailable, the system may use write off-loading.

Abstract: A data store including a file location attribute is described. In an embodiment, the location attribute for a data element, such as a file or database record, is stored with the bytes of data and records the geographic location of the data element. Writing to this attribute is limited to a single trusted entity, such as an operating system, to ensure that the location data can be trusted and when a data element is moved or replicated, the attribute is updated to reflect the new location of the data element. This location data is made available to users and applications by a metadata service which tracks the locations of data elements and responds to requests from users. Access control policies can been defined in terms of location and stored at the metadata service and the metadata service can then enforce these policies when responding to requests.

Abstract: Improved storage systems which use write off-loading are described. When a request to store some data in a particular storage location is received, if the particular storage location is unavailable, the data is stored in an alternative location. In an embodiment, the particular storage location may be unavailable because it is powered down or because it is overloaded. The data stored in the alternative location may be subsequently recovered and written to the particular storage location once it becomes available.

Abstract: A prediction system may perform capacity planning for one or more resources of a database systems, such as by understanding how different workloads are using the system resources and/or predicting how the performance of the workloads will change when the hardware configuration of the resource is changed and/or when the workload changes. The prediction system may use a detailed, low-level tracing of a live database system running an application workload to monitor the performance of the current database system. In this manner, the current monitoring traces and analysis may be combined with a simulation to predict the workload's performance on a different hardware configuration. More specifically, performance may be indicated as throughput and/or latency, which may be for all transactions, for a particular transaction type, and/or for an individual transaction.

Abstract: Methods for reducing the power consumption of distributed storage systems are described. An embodiment describes a storage system which is adapted to reduce its power consumption at times of low load by reducing the number of active versions of the stored data. The data to be stored in the storage system is divided into chunks and in an example, each chunk is replicated on a number of different servers. At times of low load, the system enters a mode of operation in which the number of active replicas is reduced and servers that do not store any active replicas are put into a low power state. When in this mode, writes are written to a versioned store and the data is subsequently copied to servers storing replicas once all the servers have returned to normal power state.

Abstract: A prediction system may perform capacity planning for one or more resources of a database systems, such as by understanding how different workloads are using the system resources and/or predicting how the performance of the workloads will change when the hardware configuration of the resource is changed and/or when the workload changes. The prediction system may use a detailed, low-level tracing of a live database system running an application workload to monitor the performance of the current database system. In this manner, the current monitoring traces and analysis may be combined with a simulation to predict the workload's performance on a different hardware configuration. More specifically, performance may be indicated as throughput and/or latency, which may be for all transactions, for a particular transaction type, and/or for an individual transaction.