Abstract: The application relates to writing arbitrarily sized data extents using in-line descriptors, such as headers or footers, into physical blocks to describe the data extents in those physical blocks. Some data extents may be smaller than the size of a physical block, and some data extents may be larger than the size of a physical block. A given physical block therefore includes an in-line descriptor for a data extent in that block, indicating that the data extent starts within that block and also an offset from the beginning of the block to where the data extent starts. The in-line descriptor is included within the block so that when the block is read both the data and the descriptor are read, thereby eliminating performance penalty for reading the descriptor information.

Abstract: A method includes: storing a first data extent on a physical medium, wherein the physical medium is divided into a plurality of storage blocks, wherein each of the storage blocks has a size that is different than a size of the first data extent, further wherein the first data extent is stored to a first block of the plurality of storage blocks; generating a descriptor for the first data extent, wherein the descriptor indicates that the first data extent starts within the first block of the plurality of blocks and indicates an offset from the beginning of the first block at which the first data extent starts; and storing the descriptor within the first block.

Abstract: A method includes: storing a first data extent on a physical medium, wherein the physical medium is divided into a plurality of storage blocks, wherein each of the storage blocks has a size that is different than a size of the first data extent, further wherein the first data extent is stored to a first block of the plurality of storage blocks; generating a descriptor for the first data extent, wherein the descriptor indicates that the first data extent starts within the first block of the plurality of blocks and indicates an offset from the beginning of the first block at which the first data extent starts; and storing the descriptor within the first block.

Abstract: A system shares I/O load between controllers in a high availability system. For writes, a controller determines based on one or more factors which controller will flush batches of data from write-back cache to better distribute the I/O burden. The determination occurs after the local storage controller caches the data, mirrors it, and confirms write complete to the host. Once it is determined which storage controller will flush the cache, the flush occurs and the corresponding metadata at a second layer of indirection is updated by that determined storage controller (whether or not it is identified as the owner of the corresponding volume to the host, while the volume owner updates metadata at a first layer of indirection). For a host read, the controller that owns the volume accesses the metadata from whichever controller(s) flushed the data previously and reads the data, regardless of which controller had performed the flush.

Abstract: An unmanned aerial vehicle (UAV) has a first radio configured to operate on one of a plurality of radio frequency (RF) channels, a processing and management application program interface (API), and a controller. A system for active radio frequency (RF) channel switching includes the UAV and a head end control unit in wireless communication with the UAV. A method of RF spectrum identification and mapping includes collecting RF data by the UAV within an area of operation, determining location data within the area of operation using a global positioning system (GPS) located on the UAV, and mapping the RF data of the area of operation using the location data.

Abstract: A method by one or more computing devices for detecting application user anomalies in audit logs of database operations performed on one or more databases. The method includes obtaining a first audit log of database operations, wherein the first audit log indicates (1) which application users of an application caused which of the database operations to be performed and (2) which functions of the application caused which of the database operations to be performed, generating, for each of the application users indicated in the first audit log, a profile of that application user that indicates which of the functions that application user is expected to touch, and detecting an anomaly in response to a determination that a second audit log indicates that an application user touched a function that is not one of the functions indicated in the profile of the application user.

Abstract: A method, a computing device, and a non-transitory machine-readable medium for allocating data compression activities in a storage system are provided. A method includes tracking, by a storage controller, computing resources corresponding to a storage server. The storage controller processes one or more host read requests to access data requested by one or more hosts, the processing of the one or more host read requests including decompressing the data requested by the one or more hosts from the storage server and providing the decompressed data to the one or more hosts. The storage controller determines an amount of available computing resources after processing the one or more host read requests. Based on the amount of available computing resources, the storage controller performs inline compression of a first portion of host write requests and background compression of a second portion of the host write requests.

Abstract: A method, system and computer readable medium of: providing feature data of at least one organ at risk or target volume of said patient from a database of non-transitory data stored on a data storage device of prior patients data; generating, using a data processor, a distribution of dose points of the at least one organ at risk or target volume of said patient based on said feature data; calculating, using the data processor, at least one of (i) a probability of toxicity for the at least one organ at risk or (ii) a probability of treatment failure for the at least one target volume, based on said distribution of dose points; assessing, using the data processor, a dosimetric-outcome relationship based on the calculated probability; and automatically formulating, using the data processor, a treatment plan using the dosimetric-outcome relationship to minimize the at least one treatment-related risk.

Abstract: A system for tracking metadata changes and recovering from system interruptions. With host I/O, corresponding metadata incremental changes are aggregated and stored in a write-ahead log before being performed to their in-memory buffers. As those buffers are flushed, checkpoints are created and stored in the log. As the log wraps to the start, older entries are overwritten after they are freed from any remaining dependencies by newer checkpoints. If metadata entities have not created new checkpoints, they are instructed to in order to free up space for new aggregated batches and checkpoints. After an interruption, the wrap point is located in the log. From the wrap point, the log is scanned backwards to provide checkpoints to metadata entities. The log is then scanned forwards to perform changes specified by aggregated batches. The metadata entities' volatile memory states are recovered to what they were before the interruption.

Abstract: A system shares I/O load between controllers in a high availability system. For writes, a controller determines based on one or more factors which controller will flush batches of data from write-back cache to better distribute the I/O burden. The determination occurs after the local storage controller caches the data, mirrors it, and confirms write complete to the host. Once it is determined which storage controller will flush the cache, the flush occurs and the corresponding metadata at a second layer of indirection is updated by that determined storage controller (whether or not it is identified as the owner of the corresponding volume to the host, while the volume owner updates metadata at a first layer of indirection). For a host read, the controller that owns the volume accesses the metadata from whichever controller(s) flushed the data previously and reads the data, regardless of which controller had performed the flush.

Abstract: A smoking pipe is disclosed. Example embodiments are directed to a smoking pipe having a bowl where tobacco would be inserted to be smoked, the bowl being a separate piece or part that gets pressed, threaded, or magnetized into or onto a machined body, stem, or smoke chamber of the smoking pipe. The smoking pipe can have a body, stem, or smoke chamber that gets hollowed out by a machining process to allow maximum smoke expansion and superior performance. Example embodiments can include a bowl, a stem, body, or smoke chamber, a mouth piece or receiving portion, and a carburetor to allow fresh air to clear the smoke chamber. The smoking pipe may have or may not have a 5.725 degree taper machined into the inside diameter of the carburetor hole to allow other smoking attachments to be inserted into the carburetor hole.

Abstract: A system shares I/O load between controllers in a high availability system. For writes, a controller determines based on one or more factors which controller will flush batches of data from write-back cache to better distribute the I/O burden. The determination occurs after the local storage controller caches the data, mirrors it, and confirms write complete to the host. Once it is determined which storage controller will flush the cache, the flush occurs and the corresponding metadata at a second layer of indirection is updated by that determined storage controller (whether or not it is identified as the owner of the corresponding volume to the host, while the volume owner updates metadata at a first layer of indirection). For a host read, the controller that owns the volume accesses the metadata from whichever controller(s) flushed the data previously and reads the data, regardless of which controller had performed the flush.

Abstract: A method by one or more computing devices for detecting application user anomalies in audit logs of database operations performed on one or more databases. The method includes obtaining a first audit log of database operations, wherein the first audit log indicates (1) which application users of an application caused which of the database operations to be performed and (2) which functions of the application caused which of the database operations to be performed, generating, for each of the application users indicated in the first audit log, a profile of that application user that indicates which of the functions that application user is expected to touch, and detecting an anomaly in response to a determination that a second audit log indicates that an application user touched a function that is not one of the functions indicated in the profile of the application user.

Abstract: A method for detecting anomalies in audit logs of database operations performed on databases. The method includes obtaining a first audit log of database operations performed on one or more databases, generating, for each of a plurality of attribute values associated with a designated attribute appearing in the first audit log, a profile of that attribute value that indicates expected attribute characteristics of one or more attributes when that attribute value is associated with the designated attribute, obtaining a second audit log of further database operations performed on the one or more databases, and detecting an anomaly responsive to a determination that a log entry in the second audit log includes an attribute value associated with the designated attribute but attributes in the log entry deviate from the expected attribute characteristics of the one or more attributes indicated by the profile of the attribute value associated with the designated attribute.

Abstract: A computer-implemented method may be provided for analyzing and disseminating medical information. The method may include steps performed by one or more processors including, receiving a plurality of patient medical data; aggregating the plurality of patient medical data, wherein access to patient private health information is restricted; receiving a query for medical information; analyzing the aggregated medical data based on the query; producing a result of the query based on the analyzing of the aggregated medical data; and transmitting the result of the query.

Abstract: A method includes: storing a first data extent on a physical medium, wherein the physical medium is divided into a plurality of storage blocks, wherein each of the storage blocks has a size that is different than a size of the first data extent, further wherein the first data extent is stored to a first block of the plurality of storage blocks; generating a descriptor for the first data extent, wherein the descriptor indicates that the first data extent starts within the first block of the plurality of blocks and indicates an offset from the beginning of the first block at which the first data extent starts; and storing the descriptor within the first block.

Abstract: A system for tracking metadata changes and recovering from system interruptions. With host I/O, corresponding metadata incremental changes are aggregated and stored in a write-ahead log before being performed to their in-memory buffers. As those buffers are flushed, checkpoints are created and stored in the log. As the log wraps to the start, older entries are overwritten after they are freed from any remaining dependencies by newer checkpoints. If metadata entities have not created new checkpoints, they are instructed to in order to free up space for new aggregated batches and checkpoints. After an interruption, the wrap point is located in the log. From the wrap point, the log is scanned backwards to provide checkpoints to metadata entities. The log is then scanned forwards to perform changes specified by aggregated batches. The metadata entities' volatile memory states are recovered to what they were before the interruption.

Abstract: A system for tracking metadata changes and recovering from system interruptions. With host I/O, corresponding metadata incremental changes are aggregated and stored in a write-ahead log before being performed to their in-memory buffers. As those buffers are flushed, checkpoints are created and stored in the log. As the log wraps to the start, older entries are overwritten after they are freed from any remaining dependencies by newer checkpoints. If metadata entities have not created new checkpoints, they are instructed to in order to free up space for new aggregated batches and checkpoints. After an interruption, the wrap point is located in the log. From the wrap point, the log is scanned backwards to provide checkpoints to metadata entities. The log is then scanned forwards to perform changes specified by aggregated batches. The metadata entities' volatile memory states are recovered to what they were before the interruption.

Abstract: A method includes: storing a first data extent on a physical medium, wherein the physical medium is divided into a plurality of storage blocks, wherein each of the storage blocks has a size that is different than a size of the first data extent, further wherein the first data extent is stored to a first block of the plurality of storage blocks; generating a descriptor for the first data extent, wherein the descriptor indicates that the first data extent starts within the first block of the plurality of blocks and indicates an offset from the beginning of the first block at which the first data extent starts; and storing the descriptor within the first block.

Abstract: A method, a computing device, and a non-transitory machine-readable medium for allocating data compression activities in a storage system are provided. A method includes tracking, by a storage controller, computing resources corresponding to a storage server. The storage controller processes one or more host read requests to access data requested by one or more hosts, the processing of the one or more host read requests including decompressing the data requested by the one or more hosts from the storage server and providing the decompressed data to the one or more hosts. The storage controller determines an amount of available computing resources after processing the one or more host read requests. Based on the amount of available computing resources, the storage controller performs inline compression of a first portion of host write requests and background compression of a second portion of the host write requests.