In-place erasure code transcoding for distributed file systems

Description

TECHNICAL FIELD

The present invention relates generally to file systems, and more particularly, but not exclusively, to in-place erasure code transcoding for distributed file systems.

BACKGROUND

Modern computing often requires the collection, processing, or storage of very large data sets or file systems. Accordingly, to accommodate the capacity requirements as well as other requirements, such as, high availability, redundancy, latency/access considerations, or the like, modern file systems may be very large or distributed across multiple hosts, networks, or data centers, and so on. File systems may include many storage volumes that may be subject to failure. Having a large number of storage volumes storing critical/important information may increase the likelihood that a storage volume may fail or otherwise become unavailable. Accordingly, distributed file systems may employ various parity or protection schemes to mitigate inevitable storage volume unavailability/failure. However, the large capacity and dynamic flexibility of distributed file system introduces various difficulties associated with maintaining protection/parity of data stored in file systems. For example, expanding file system capacity may disrupt existing protection schemes. Thus, it is with respect to these considerations and others that the present invention has been made.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present innovations are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified. For a better understanding of the described innovations, reference will be made to the following Detailed Description of Various Embodiments, which is to be read in association with the accompanying drawings, wherein:

FIG. 1 illustrates a system environment in which various embodiments may be implemented;

FIG. 2 illustrates a schematic embodiment of a client computer;

FIG. 3 illustrates a schematic embodiment of a network computer;

FIG. 4 illustrates a logical architecture of a system for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 5 shows a logical schematic of a system that is a portion of a data storage system for in-place erasure code transcoding for distributed file systems in accordance with at least one of the various embodiments;

FIG. 6 illustrates a logical schematic of a file system for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 7A illustrates a logical schematic of a file system for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 7B illustrates a logical schematic of a file system for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 7C illustrates a logical schematic of a file system for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 7D illustrates a logical schematic of a file system for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 8 illustrates a logical schematic of protections groups for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiment;

FIG. 9 illustrates an overview flowchart for a process for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments;

FIG. 10 illustrates a flowchart for a process for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments; and

FIG. 11 illustrates a flowchart for a process for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

Various embodiments now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. The embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the embodiments to those skilled in the art. Among other things, the various embodiments may be methods, systems, media or devices. Accordingly, the various embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. Furthermore, the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment, although it may. Thus, as described below, various embodiments may be readily combined, without departing from the scope or spirit of the invention.

In addition, as used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and/or,” unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.”

For example embodiments, the following terms are also used herein according to the corresponding meaning, unless the context clearly dictates otherwise.

As used herein the term, “engine” refers to logic embodied in hardware or software instructions, which can be written in a programming language, such as C, C++, Objective-C, COBOL, Java™, PHP, Perl, JavaScript, Ruby, VB Script, Microsoft .NET™ languages such as C #, or the like. An engine may be compiled into executable programs or written in interpreted programming languages. Software engines may be callable from other engines or from themselves. Engines described herein refer to one or more logical modules that can be merged with other engines or applications, or can be divided into sub-engines. The engines can be stored in non-transitory computer-readable medium or computer storage device and be stored on and executed by one or more general purpose computers, thus creating a special purpose computer configured to provide the engine.

As used herein the terms “file system object” refers to entities stored in a file system. These may include files, directories, or the like. In this document for brevity and clarity all objects stored in a file system may be referred to as file system objects.

As used herein the term “file system block” refers to a smallest relocatable file system object. Usually, file system blocks have a fixed size based on the attributes of the underlying storage devices. Other larger file system objects are comprised of file system blocks. For example, small sized file system objects, such as, directory objects or small files may be comprised of a single block. Whereas larger file system objects, such as large document files may be comprised of many blocks. Blocks usually are arranged to have a fixed size. This may include fixing block size to a particular size, such as 4 KB, or the like, based on requirements associated with underlying storage hardware, such as, solid state drives (SSDs) or hard disk drives (HDDs), or the like. However, normal file system objects, such as, files may be of various sizes, comprised of the number of blocks necessary to represent or contain the entire file system object.

As used herein the term “storage device” as used herein refers to various apparatus for storing digital information, generally for use by computers. Storage devices may be fixed or removable non-volatile memory systems, such as, magnetic hard drives, magnetic tape, optical drives, solid state drives (SSD), flash memory storage, or the like. Typically, one or more storage devices may be arranged to store information for use in a computer system. Further, in some cases, storage devices may be virtualized such that they may be comprised of more than one storage device, storage device partition, cloud-computing object stores, cloud-computing data stores, or the like.

As used herein the term “protection level” refers to the number of simultaneous data failures a storage system may experience before data may be irrevocably lost.

As used herein the terms “erasure code,” or “erasure coding” refer to methods for error correction/error recovery based on computing repair information from storage information. The repair symbol information may be computed and stored separately from the storage information and may be employed to correct errors in the storage information that may be caused by data failure. Likewise, if the repair symbol information is lost because of a storage failure, it may be recomputed from the storage information. Unless data the amount of data failures exceed the protection level afforded by the erasure coding.

As used herein the term “data failure,” or “storage failure” refer to any system or device failure that causes data stored in a file system to be corrupted, lost, involuntarily deleted, or otherwise damaged such that the data is unreadable or involuntarily modified. For example, if a file system includes ten storage devices, the physical failure (breakdown) of one or more of the storage devices may be classified as a storage failure or data failure, since the information stored on the failed storage device may be inaccessible.

As used herein the term “data loss” refers to data failures that cannot be repaired. For example, if the number of data failures exceeds the file system protection level, the data failures will result in data loss. In contrast, if the number of data failures is less than or equal to the protection level, data failures may be repaired.

As used herein the terms “repair,” or re-protect refer to actions performed to recover from one or more data failures in a file system. If erasure coding is being employed, a repair may include reading repair symbol information or storage data from one or more storage devices and computing lost data using one or more erasure coding algorithms.

As used herein the term “block store” refers to a collection of file system blocks that may be stored on a storage device. Each block store may include many file system blocks.

As used herein the term “protection group” refers to a collection of associated block stores. Protection groups may be associated with a protection level based on erasure coding applied to the protection group. Generally speaking if a protection group has a protection level two data failure associated with one or more block stores in the protection group may be recoverable. If the number of failed block stores exceed a protection groups, protection level, data loss may occur. File systems may distribute the block stores for a given protection group across a cluster of file system nodes or storage devices.

As used herein the term “configuration information” refers to information that may include rule based policies, pattern matching, scripts (e.g., computer readable instructions), or the like, that may be provided from various sources, including, configuration files, databases, user input, built-in defaults, or the like, or combination thereof.

The following briefly describes embodiments of the invention in order to provide a basic understanding of some aspects of the invention. This brief description is not intended as an extensive overview. It is not intended to identify key or critical elements, or to delineate or otherwise narrow the scope. Its purpose is merely to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

Briefly stated, various embodiments are directed to in-place erasure code transcoding for distributed file systems. In one or more of the various embodiments, a file system that includes a plurality of protection groups that each are associated with a plurality of block stores may be provided such that each block store associated with the plurality of protection groups may be encoded based on a first erasure code.

In one or more of the various embodiments, the file system may be divided into a first partition and a second partition such that a portion of a storage space in the file system may be shifted from the first partition to the second partition such that the first partition may be associated with the first erasure code and the second partition is associated with a second erasure code.

In one or more of the various embodiments, in response to the second partition having sufficient storage space to store one or more protection groups further actions may be performed, including: determining one or more block stores in the first partition associated with the one or more protection groups; transcoding contents of the one or more block stores into one or more other block stores based on the second erasure code such that the one or more other block stores are sized based on the second erasure code; storing the one or more other block stores in the second partition; deleting the one or more block stores from the first partition; shifting another portion of the storage space from the first partition to the second partition such that the shifted other portion increases a size of the second partition to provide sufficient storage space for one or more other protection groups; or the like.

In one or more of the various embodiments, in response to the second partition reaching a maximum size, reporting that the file system is encoded based on the second erasure code.

In one or more of the various embodiments, one or more client requests to the file system may be provided. In some embodiments, the one or more client requests may be satisfied using contents from one or more of the first partition or the second partition.

In one or more of the various embodiments, a portion of plurality of the block stores in the first partition may be moved to provide storage space for the second.

In one or more of the various embodiments, in response to one or more storage devices being added to the file system, a portion of the plurality of block stores may be distributed to the one or more added storage devices to provide working space in the file system to transcode the plurality of block stores based on the second erasure code.

In one or more of the various embodiments, transcoding the contents of the one or more block stores into one or more other block stores may include: disassociating the one or more block stores from the one or more protection groups; associating the one or more other block stores with the one or more protection groups such that a storage capacity, protection level, or availability of each of the one or more protection groups remains unchanged; or the like.

In one or more of the various embodiments, in response to modifying the file system with one or more additional storage devices additional actions may be performed, including: determining a storage inefficiency value for the modified file system based on the first erasure code; determining a data loss risk value for the modified file system based on the first erasure code; in response to one or more of the storage inefficiency value or the data loss risk value exceeding a threshold value, converting the modified file system to protect its contents based on the second erasure code; or the like.

Illustrated Operating Environment

FIG. 1 shows components of one embodiment of an environment in which embodiments of the invention may be practiced. Not all of the components may be required to practice the invention, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, application server computer 116, file system management server computer 118, cloud computing environment 120, or the like.

At least one embodiment of client computers 102-105 is described in more detail below in conjunction with FIG. 2. In one embodiment, at least some of client computers 102-105 may operate over one or more wired or wireless networks, such as networks 108, or 110. Generally, client computers 102-105 may include virtually any computer capable of communicating over a network to send and receive information, perform various online activities, offline actions, or the like. In one embodiment, one or more of client computers 102-105 may be configured to operate within a business or other entity to perform a variety of services for the business or other entity. For example, client computers 102-105 may be configured to operate as a web server, firewall, client application, media player, mobile telephone, game console, desktop computer, or the like. However, client computers 102-105 are not constrained to these services and may also be employed, for example, as for end-user computing in other embodiments. It should be recognized that more or less client computers (as shown in FIG. 1) may be included within a system such as described herein, and embodiments are therefore not constrained by the number or type of client computers employed.

Computers that may operate as client computer 102 may include computers that typically connect using a wired or wireless communications medium such as personal computers, multiprocessor systems, microprocessor-based or programmable electronic devices, network PCs, or the like. In some embodiments, client computers 102-105 may include virtually any portable computer capable of connecting to another computer and receiving information such as, laptop computer 103, mobile computer 104, tablet computers 105, or the like. However, portable computers are not so limited and may also include other portable computers such as cellular telephones, display pagers, radio frequency (RF) devices, infrared (IR) devices, Personal Digital Assistants (PDAs), handheld computers, wearable computers, integrated devices combining one or more of the preceding computers, or the like. As such, client computers 102-105 typically range widely in terms of capabilities and features. Moreover, client computers 102-105 may access various computing applications, including a browser, or other web-based application.

A web-enabled client computer may include a browser application that is configured to send requests and receive responses over the web. The browser application may be configured to receive and display graphics, text, multimedia, and the like, employing virtually any web-based language. In one embodiment, the browser application is enabled to employ JavaScript, HyperText Markup Language (HTML), eXtensible Markup Language (XML), JavaScript Object Notation (JSON), Cascading Style Sheets (CSS), or the like, or combination thereof, to display and send a message. In one embodiment, a user of the client computer may employ the browser application to perform various activities over a network (online). However, another application may also be used to perform various online activities.

Client computers 102-105 also may include at least one other client application that is configured to receive or send content between another computer. The client application may include a capability to send or receive content, or the like. The client application may further provide information that identifies itself, including a type, capability, name, and the like. In one embodiment, client computers 102-105 may uniquely identify themselves through any of a variety of mechanisms, including an Internet Protocol (IP) address, a phone number, Mobile Identification Number (MIN), an electronic serial number (ESN), a client certificate, or other device identifier. Such information may be provided in one or more network packets, or the like, sent between other client computers, application server computer 116, file system management server computer 118, cloud computing environment 120, or other computers.

Client computers 102-105 may further be configured to include a client application that enables an end-user to log into an end-user account that may be managed by another computer, such as application server computer 116, file system management server computer 118, cloud computing environment 120, or the like. Such an end-user account, in one non-limiting example, may be configured to enable the end-user to manage one or more online activities, including in one non-limiting example, project management, software development, system administration, configuration management, search activities, social networking activities, browse various websites, communicate with other users, or the like. Also, client computers may be arranged to enable users to display reports, interactive user-interfaces, or results provided by application server computer 116, file system management server computer 118, cloud computing environment 120, or the like.

Wireless network 108 is configured to couple client computers 103-105 and its components with network 110. Wireless network 108 may include any of a variety of wireless sub-networks that may further overlay stand-alone ad-hoc networks, and the like, to provide an infrastructure-oriented connection for client computers 103-105. Such sub-networks may include mesh networks, Wireless LAN (WLAN) networks, cellular networks, and the like. In one embodiment, the system may include more than one wireless network.

Wireless network 108 may further include an autonomous system of terminals, gateways, routers, and the like connected by wireless radio links, and the like. These connectors may be configured to move freely and randomly and organize themselves arbitrarily, such that the topology of wireless network 108 may change rapidly.

Wireless network 108 may further employ a plurality of access technologies including 2nd (2G), 3rd (3G), 4th (4G) 5th (5G) generation radio access for cellular systems, WLAN, Wireless Router (WR) mesh, and the like. Access technologies such as 2G, 3G, 4G, 5G, and future access networks may enable wide area coverage for mobile computers, such as client computers 103-105 with various degrees of mobility. In one non-limiting example, wireless network 108 may enable a radio connection through a radio network access such as Global System for Mobil communication (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), code division multiple access (CDMA), time division multiple access (TDMA), Wideband Code Division Multiple Access (WCDMA), High Speed Downlink Packet Access (HSDPA), Long Term Evolution (LTE), and the like. In essence, wireless network 108 may include virtually any wireless communication mechanism by which information may travel between client computers 103-105 and another computer, network, a cloud-based network, a cloud instance, or the like.

Network 110 is configured to couple network computers with other computers, including, application server computer 116, file system management server computer 118, cloud computing environment 120, client computers 102, and client computers 103-105 through wireless network 108, or the like. Network 110 is enabled to employ any form of computer readable media for communicating information from one electronic device to another. Also, network 110 can include the Internet in addition to local area networks (LANs), wide area networks (WANs), direct connections, such as through a universal serial bus (USB) port, Ethernet port, other forms of computer-readable media, or any combination thereof. On an interconnected set of LANs, including those based on differing architectures and protocols, a router acts as a link between LANs, enabling messages to be sent from one to another. In addition, communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, or other carrier mechanisms including, for example, E-carriers, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art. Moreover, communication links may further employ any of a variety of digital signaling technologies, including without limit, for example, DS-0, DS-1, DS-2, DS-3, DS-4, OC-3, OC-12, OC-48, or the like. Furthermore, remote computers and other related electronic devices could be remotely connected to either LANs or WANs via a modem and temporary telephone link. In one embodiment, network 110 may be configured to transport information of an Internet Protocol (IP).

Additionally, communication media typically embodies computer readable instructions, data structures, program modules, or other transport mechanism and includes any information non-transitory delivery media or transitory delivery media. By way of example, communication media includes wired media such as twisted pair, coaxial cable, fiber optics, wave guides, and other wired media and wireless media such as acoustic, RF, infrared, and other wireless media.

In some embodiments, cloud computing environment 120 may be one or more public or private cloud computing environments. In some embodiments, cloud computing environments may be provided by various vendors or developed internally or privately. Cloud computing environments typically provide virtualized network computers (e.g., compute instances), virtualized storage (e.g., storage volumes), virtualized network interfaces, or the like. Various cloud computing environments may be assumed to have one or more APIs or interfaces that enable users or services to provision resources, provision storage, configure networking, monitoring usage/status, or the like. One of ordinary skill in the art will be well acquainted with public or private cloud computing environments.

Also, one embodiment of file system management server computer 118 is described in more detail below in conjunction with FIG. 3. Although FIG. 1 illustrates file system management server computer 118, or the like, as a single computer, the innovations or embodiments described herein are not so limited. For example, one or more functions of file system management server computer 118, or the like, may be distributed across one or more distinct network computers. Moreover, in one or more embodiments, file system management server computer 118 may be implemented using a plurality of network computers. Further, in one or more of the various embodiments, file system management server computer 118, or the like, may be implemented using one or more cloud instances in one or more cloud networks, such as, cloud computing environment 120. Accordingly, these innovations and embodiments are not to be construed as being limited to a single environment, and other configurations, and other architectures are also envisaged.

Illustrative Client Computer

FIG. 2 shows one embodiment of client computer 200 that may include many more or less components than those shown. Client computer 200 may represent, for example, one or more embodiment of mobile computers or client computers shown in FIG. 1.

Client computer 200 may include processor 202 in communication with memory 204 via bus 228. Client computer 200 may also include power supply 230, network interface 232, audio interface 256, display 250, keypad 252, illuminator 254, video interface 242, input/output interface 238, haptic interface 264, global positioning systems (GPS) receiver 258, open air gesture interface 260, temperature interface 262, camera(s) 240, projector 246, pointing device interface 266, processor-readable stationary storage device 234, and processor-readable removable storage device 236. Client computer 200 may optionally communicate with a base station (not shown), or directly with another computer. And in one embodiment, although not shown, a gyroscope may be employed within client computer 200 to measuring or maintaining an orientation of client computer 200.

Power supply 230 may provide power to client computer 200. A rechargeable or non-rechargeable battery may be used to provide power. The power may also be provided by an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the battery.

Network interface 232 includes circuitry for coupling client computer 200 to one or more networks, and is constructed for use with one or more communication protocols and technologies including, but not limited to, protocols and technologies that implement any portion of the OSI model for mobile communication (GSM), CDMA, time division multiple access (TDMA), UDP, TCP/IP, SMS, MMS, GPRS, WAP, UWB, WiMax, SIP/RTP, GPRS, EDGE, WCDMA, LTE, UMTS, OFDM, CDMA2000, EV-DO, HSDPA, 5G, or any of a variety of other wireless communication protocols. Network interface 232 is sometimes known as a transceiver, transceiving device, or network interface card (MC).

Audio interface 256 may be arranged to produce and receive audio signals such as the sound of a human voice. For example, audio interface 256 may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgment for some action. A microphone in audio interface 256 can also be used for input to or control of client computer 200, e.g., using voice recognition, detecting touch based on sound, and the like.

Display 250 may be a liquid crystal display (LCD), gas plasma, electronic ink, light emitting diode (LED), Organic LED (OLED) or any other type of light reflective or light transmissive display that can be used with a computer. Display 250 may also include a touch interface 244 arranged to receive input from an object such as a stylus or a digit from a human hand, and may use resistive, capacitive, surface acoustic wave (SAW), infrared, radar, or other technologies to sense touch or gestures.

Projector 246 may be a remote handheld projector or an integrated projector that is capable of projecting an image on a remote wall or any other reflective object such as a remote screen.

Video interface 242 may be arranged to capture video images, such as a still photo, a video segment, an infrared video, or the like. For example, video interface 242 may be coupled to a digital video camera, a web-camera, or the like. Video interface 242 may comprise a lens, an image sensor, and other electronics. Image sensors may include a complementary metal-oxide-semiconductor (CMOS) integrated circuit, charge-coupled device (CCD), or any other integrated circuit for sensing light.

Keypad 252 may comprise any input device arranged to receive input from a user. For example, keypad 252 may include a push button numeric dial, or a keyboard. Keypad 252 may also include command buttons that are associated with selecting and sending images.

Illuminator 254 may provide a status indication or provide light. Illuminator 254 may remain active for specific periods of time or in response to event messages. For example, when illuminator 254 is active, it may back-light the buttons on keypad 252 and stay on while the client computer is powered. Also, illuminator 254 may back-light these buttons in various patterns when particular actions are performed, such as dialing another client computer. Illuminator 254 may also cause light sources positioned within a transparent or translucent case of the client computer to illuminate in response to actions.

Further, client computer 200 may also comprise hardware security module (HSM) 268 for providing additional tamper resistant safeguards for generating, storing or using security/cryptographic information such as, keys, digital certificates, passwords, passphrases, two-factor authentication information, or the like. In some embodiments, hardware security module may be employed to support one or more standard public key infrastructures (PKI), and may be employed to generate, manage, or store keys pairs, or the like. In some embodiments, HSM 268 may be a stand-alone computer, in other cases, HSM 268 may be arranged as a hardware card that may be added to a client computer.

Client computer 200 may also comprise input/output interface 238 for communicating with external peripheral devices or other computers such as other client computers and network computers. The peripheral devices may include an audio headset, virtual reality headsets, display screen glasses, remote speaker system, remote speaker and microphone system, and the like. Input/output interface 238 can utilize one or more technologies, such as Universal Serial Bus (USB), Infrared, WiFi, WiMax, Bluetooth™, and the like.

Input/output interface 238 may also include one or more sensors for determining geolocation information (e.g., GPS), monitoring electrical power conditions (e.g., voltage sensors, current sensors, frequency sensors, and so on), monitoring weather (e.g., thermostats, barometers, anemometers, humidity detectors, precipitation scales, or the like), or the like. Sensors may be one or more hardware sensors that collect or measure data that is external to client computer 200.

Haptic interface 264 may be arranged to provide tactile feedback to a user of the client computer. For example, the haptic interface 264 may be employed to vibrate client computer 200 in a particular way when another user of a computer is calling. Temperature interface 262 may be used to provide a temperature measurement input or a temperature changing output to a user of client computer 200. Open air gesture interface 260 may sense physical gestures of a user of client computer 200, for example, by using single or stereo video cameras, radar, a gyroscopic sensor inside a computer held or worn by the user, or the like. Camera 240 may be used to track physical eye movements of a user of client computer 200.

GPS transceiver 258 can determine the physical coordinates of client computer 200 on the surface of the Earth, which typically outputs a location as latitude and longitude values. GPS transceiver 258 can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), Enhanced Observed Time Difference (E-OTD), Cell Identifier (CI), Service Area Identifier (SAI), Enhanced Timing Advance (ETA), Base Station Subsystem (BSS), or the like, to further determine the physical location of client computer 200 on the surface of the Earth. It is understood that under different conditions, GPS transceiver 258 can determine a physical location for client computer 200. In one or more embodiments, however, client computer 200 may, through other components, provide other information that may be employed to determine a physical location of the client computer, including for example, a Media Access Control (MAC) address, IP address, and the like.

In at least one of the various embodiments, applications, such as, operating system 206, other client apps 224, web browser 226, or the like, may be arranged to employ geo-location information to select one or more localization features, such as, time zones, languages, currencies, calendar formatting, or the like. Localization features may be used in data objects, file system meta-data, user-interfaces, reports, as well as internal processes or databases. In at least one of the various embodiments, geo-location information used for selecting localization information may be provided by GPS 258. Also, in some embodiments, geolocation information may include information provided using one or more geolocation protocols over the networks, such as, wireless network 108 or network 111.

Human interface components can be peripheral devices that are physically separate from client computer 200, allowing for remote input or output to client computer 200. For example, information routed as described here through human interface components such as display 250 or keyboard 252 can instead be routed through network interface 232 to appropriate human interface components located remotely. Examples of human interface peripheral components that may be remote include, but are not limited to, audio devices, pointing devices, keypads, displays, cameras, projectors, and the like. These peripheral components may communicate over a Pico Network such as Bluetooth™, Zigbee™ and the like. One non-limiting example of a client computer with such peripheral human interface components is a wearable computer, which might include a remote pico projector along with one or more cameras that remotely communicate with a separately located client computer to sense a user's gestures toward portions of an image projected by the pico projector onto a reflected surface such as a wall or the user's hand.

A client computer may include web browser application 226 that is configured to receive and to send web pages, web-based messages, graphics, text, multimedia, and the like. The client computer's browser application may employ virtually any programming language, including a wireless application protocol messages (WAP), and the like. In one or more embodiments, the browser application is enabled to employ Handheld Device Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML), eXtensible Markup Language (XML), HTML5, and the like.

Memory 204 may include RAM, ROM, or other types of memory. Memory 204 illustrates an example of computer-readable storage media (devices) for storage of information such as computer-readable instructions, data structures, program modules or other data. Memory 204 may store BIOS 208 for controlling low-level operation of client computer 200. The memory may also store operating system 206 for controlling the operation of client computer 200. It will be appreciated that this component may include a general-purpose operating system such as a version of UNIX, or Linux®, or a specialized client computer communication operating system such as Windows Phone™, or the Apple Corporation's iOS or macOS® operating systems. The operating system may include, or interface various runtime engines, including Java virtual machines, or the like, that may enable control of hardware components or operating system operations via application programs supported by the various runtime engines.

Memory 204 may further include one or more data storage 210, which can be utilized by client computer 200 to store, among other things, applications 220 or other data. For example, data storage 210 may also be employed to store information that describes various capabilities of client computer 200. The information may then be provided to another device or computer based on any of a variety of methods, including being sent as part of a header during a communication, sent upon request, or the like. Data storage 210 may also be employed to store social networking information including address books, buddy lists, aliases, user profile information, or the like. Data storage 210 may further include program code, data, algorithms, and the like, for use by a processor, such as processor 202 to execute and perform actions. In one embodiment, at least some of data storage 210 might also be stored on another component of client computer 200, including, but not limited to, non-transitory processor-readable removable storage device 236, processor-readable stationary storage device 234, or even external to the client computer.

Applications 220 may include computer executable instructions which, when executed by client computer 200, transmit, receive, or otherwise process instructions and data. Applications 220 may include other client applications 224, web browser 226, or the like. Client computers may be arranged to exchange communications one or more servers or one or more other client computers.

Other examples of application programs include calendars, search programs, email client applications, IM applications, SMS applications, Voice Over Internet Protocol (VOIP) applications, contact managers, task managers, transcoders, database programs, word processing programs, security applications, spreadsheet programs, games, search programs, visualization applications, and so forth.

Additionally, in one or more embodiments (not shown in the figures), client computer 200 may include an embedded logic hardware device instead of a CPU, such as, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), Programmable Array Logic (PAL), or the like, or combination thereof. The embedded logic hardware device may directly execute its embedded logic to perform actions. Also, in one or more embodiments (not shown in the figures), client computer 200 may include one or more hardware micro-controllers instead of CPUs. In one or more embodiments, the one or more micro-controllers may directly execute their own embedded logic to perform actions and access its own internal memory and its own external Input and Output Interfaces (e.g., hardware pins or wireless transceivers) to perform actions, such as System On a Chip (SOC), or the like.

Illustrative Network Computer

FIG. 3 shows one embodiment of network computer 300 that may be included in a system implementing one or more of the various embodiments. Network computer 300 may include many more or less components than those shown in FIG. 3. However, the components shown are sufficient to disclose an illustrative embodiment for practicing these innovations. Network computer 300 may represent, for example, one or more embodiments of a file system management server computer such as file system management server computer 118, or the like, of FIG. 1. Also, in some embodiments, network computer 300 may represent virtualized network computers in cloud computing environments, or the like.

Network computers, such as, network computer 300 may include a processor 302 that may be in communication with a memory 304 via a bus 328. In some embodiments, processor 302 may be comprised of one or more hardware processors, or one or more processor cores. In some cases, one or more of the one or more processors may be specialized processors designed to perform one or more specialized actions, such as, those described herein. Network computer 300 also includes a power supply 330, network interface 332, audio interface 356, display 350, keyboard 352, input/output interface 338, processor-readable stationary storage device 334, and processor-readable removable storage device 336. Power supply 330 provides power to network computer 300.

Network interface 332 includes circuitry for coupling network computer 300 to one or more networks, and is constructed for use with one or more communication protocols and technologies including, but not limited to, protocols and technologies that implement any portion of the Open Systems Interconnection model (OSI model), global system for mobile communication (GSM), code division multiple access (CDMA), time division multiple access (TDMA), user datagram protocol (UDP), transmission control protocol/Internet protocol (TCP/IP), Short Message Service (SMS), Multimedia Messaging Service (MMS), general packet radio service (GPRS), WAP, ultra-wide band (UWB), IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMax), Session Initiation Protocol/Real-time Transport Protocol (SIP/RTP), 5G, or any of a variety of other wired and wireless communication protocols. Network interface 332 is sometimes known as a transceiver, transceiving device, or network interface card (NIC). Network computer 300 may optionally communicate with a base station (not shown), or directly with another computer.

Audio interface 356 is arranged to produce and receive audio signals such as the sound of a human voice. For example, audio interface 356 may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgment for some action. A microphone in audio interface 356 can also be used for input to or control of network computer 300, for example, using voice recognition.

Display 350 may be a liquid crystal display (LCD), gas plasma, electronic ink, light emitting diode (LED), Organic LED (OLED) or any other type of light reflective or light transmissive display that can be used with a computer. In some embodiments, display 350 may be a handheld projector or pico projector capable of projecting an image on a wall or other object.

Network computer 300 may also comprise input/output interface 338 for communicating with external devices or computers not shown in FIG. 3. Input/output interface 338 can utilize one or more wired or wireless communication technologies, such as USB™, Firewire™, WiFi, WiMax, Thunderbolt™, Infrared, Bluetooth™, Zigbee™, serial port, parallel port, and the like.

Also, input/output interface 338 may also include one or more sensors for determining geolocation information (e.g., GPS), monitoring electrical power conditions (e.g., voltage sensors, current sensors, frequency sensors, and so on), monitoring weather (e.g., thermostats, barometers, anemometers, humidity detectors, precipitation scales, or the like), or the like. Sensors may be one or more hardware sensors that collect or measure data that is external to network computer 300. Human interface components can be physically separate from network computer 300, allowing for remote input or output to network computer 300. For example, information routed as described here through human interface components such as display 350 or keyboard 352 can instead be routed through the network interface 332 to appropriate human interface components located elsewhere on the network. Human interface components include any component that allows the computer to take input from, or send output to, a human user of a computer. Accordingly, pointing devices such as mice, styluses, track balls, or the like, may communicate through pointing device interface 358 to receive user input.

GPS transceiver 340 can determine the physical coordinates of network computer 300 on the surface of the Earth, which typically outputs a location as latitude and longitude values. GPS transceiver 340 can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), Enhanced Observed Time Difference (E-OTD), Cell Identifier (CI), Service Area Identifier (SAI), Enhanced Timing Advance (ETA), Base Station Subsystem (BSS), or the like, to further determine the physical location of network computer 300 on the surface of the Earth. It is understood that under different conditions, GPS transceiver 340 can determine a physical location for network computer 300. In one or more embodiments, however, network computer 300 may, through other components, provide other information that may be employed to determine a physical location of the client computer, including for example, a Media Access Control (MAC) address, IP address, and the like.

In at least one of the various embodiments, applications, such as, operating system 306, file system engine 322, web services 329, or the like, may be arranged to employ geo-location information to select one or more localization features, such as, time zones, languages, currencies, currency formatting, calendar formatting, or the like. Localization features may be used in user interfaces, dashboards, reports, as well as internal processes or databases. In at least one of the various embodiments, geo-location information used for selecting localization information may be provided by GPS 340. Also, in some embodiments, geolocation information may include information provided using one or more geolocation protocols over the networks, such as, wireless network 108 or network 111.

Memory 304 may include Random Access Memory (RAM), Read-Only Memory (ROM), or other types of memory. Memory 304 illustrates an example of computer-readable storage media (devices) for storage of information such as computer-readable instructions, data structures, program modules or other data. Memory 304 stores a basic input/output system (BIOS) 308 for controlling low-level operation of network computer 300. The memory also stores operating system 306 for controlling the operation of network computer 300. It will be appreciated that this component may include a general-purpose operating system such as a version of UNIX, or Linux®, or a specialized operating system such as Microsoft Corporation's Windows® operating system, or the Apple Corporation's macOS® operating system. The operating system may include, or interface with one or more virtual machine modules, such as, a Java virtual machine module that enables control of hardware components or operating system operations via Java application programs. Likewise, other runtime environments may be included.

Memory 304 may further include one or more data storage 310, which can be utilized by network computer 300 to store, among other things, applications 320 or other data. For example, data storage 310 may also be employed to store information that describes various capabilities of network computer 300. The information may then be provided to another device or computer based on any of a variety of methods, including being sent as part of a header during a communication, sent upon request, or the like. Data storage 310 may also be employed to store social networking information including address books, friend lists, aliases, user profile information, or the like. Data storage 310 may further include program code, data, algorithms, and the like, for use by a processor, such as processor 302 to execute and perform actions such as those actions described below. In one embodiment, at least some of data storage 310 might also be stored on another component of network computer 300, including, but not limited to, non-transitory media inside processor-readable removable storage device 336, processor-readable stationary storage device 334, or any other computer-readable storage device within network computer 300, or even external to network computer 300. Data storage 310 may include, for example, file storage 314, file system data 316, or the like.

Applications 320 may include computer executable instructions which, when executed by network computer 300, transmit, receive, or otherwise process messages (e.g., SMS, Multimedia Messaging Service (MMS), Instant Message (IM), email, or other messages), audio, video, and enable telecommunication with another user of another mobile computer. Other examples of application programs include calendars, search programs, email client applications, IM applications, SMS applications, Voice Over Internet Protocol (VOIP) applications, contact managers, task managers, transcoders, database programs, word processing programs, security applications, spreadsheet programs, games, search programs, and so forth. Applications 320 may include file system engine 322, web services 329, or the like, that may be arranged to perform actions for embodiments described below. In one or more of the various embodiments, one or more of the applications may be implemented as modules or components of another application. Further, in one or more of the various embodiments, applications may be implemented as operating system extensions, modules, plugins, or the like.

Furthermore, in one or more of the various embodiments, file system engine 322, web services 329, or the like, may be operative in a cloud-based computing environment. In one or more of the various embodiments, these applications, and others, that comprise the management platform may be executing within virtual machines or virtual servers that may be managed in a cloud-based based computing environment. In one or more of the various embodiments, in this context the applications may flow from one physical network computer within the cloud-based environment to another depending on performance and scaling considerations automatically managed by the cloud computing environment. Likewise, in one or more of the various embodiments, virtual machines or virtual servers dedicated to file system engine 322, web services 329, or the like, may be provisioned and de-commissioned automatically.

Also, in one or more of the various embodiments, file system engine 322, web services 329, or the like, may be located in virtual servers running in a cloud-based computing environment rather than being tied to one or more specific physical network computers.

Further, network computer 300 may also comprise hardware security module (HSM) 360 for providing additional tamper resistant safeguards for generating, storing or using security/cryptographic information such as, keys, digital certificates, passwords, passphrases, two-factor authentication information, or the like. In some embodiments, hardware security module may be employed to support one or more standard public key infrastructures (PKI), and may be employed to generate, manage, or store keys pairs, or the like. In some embodiments, HSM 360 may be a stand-alone network computer, in other cases, HSM 360 may be arranged as a hardware card that may be installed in a network computer.

Additionally, in one or more embodiments (not shown in the figures), network computer 300 may include an embedded logic hardware device instead of a CPU, such as, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), Programmable Array Logic (PAL), or the like, or combination thereof. The embedded logic hardware device may directly execute its embedded logic to perform actions. Also, in one or more embodiments (not shown in the figures), the network computer may include one or more hardware microcontrollers instead of a CPU. In one or more embodiments, the one or more microcontrollers may directly execute their own embedded logic to perform actions and access their own internal memory and their own external Input and Output Interfaces (e.g., hardware pins or wireless transceivers) to perform actions, such as System On a Chip (SOC), or the like.

Illustrative Logical System Architecture

FIG. 4 illustrates a logical architecture of system 400 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments. In one or more of the various embodiments, one or more file systems, such as, file system 402 may be arranged to be communicatively coupled to one or more networks, such as, networks 408. Accordingly, in one or more of the various embodiments, one or more clients, such as, client computer 410 or client computer 412 may be arranged to access file system 402 over networks 408. In some embodiments, clients of file system 402 may include users, services, programs, computers, devices, or the like, that may be enabled to perform one or more data related operations, such as, creating, reading, updating, or deleting data (e.g., file system objects, documents, or the like) that may be stored in file system 402.

In some embodiments, file system 402 may comprise one or more file system management computers, such as file system management computer 404. Also, in one or more of the various embodiments, file systems, such as file system 402 may include one or more file system objects, such as file system object 406. In one or more of the various embodiments, file system object 406 may be considered to represent the various file system objects, documents objects, or the like, that may be stored in file system 402. In some embodiments, file system objects may include files, documents, directories, folders, backups, snapshots, replication snapshots, replication information, or the like.

In one or more of the various embodiments, the implementation details that enable file system 402 to provide file system services may be hidden from clients, such that they may use file system 402 the same way they use other conventional local or remote file systems. Accordingly, in one or more of the various embodiments, clients may be unaware that they are using a distributed file system because file system engines may be arranged to mimic the interface or behavior of one or more conventional file systems.

Also, while file system 402 is illustrated as using one file system management computer with one set of file system objects, these innovations are not so limited. Innovations herein contemplate file systems that may include one or more file system management computers or one or more file system object data stores. In some embodiments, file system objects may be located remotely from one or more file system management computers. Also, a logical file system object store or file system may be spread across two or more cloud computing environments, storage clusters, or the like.

FIG. 5 shows a logical schematic of system 500 that is a portion of a data storage system for in-place erasure code transcoding for distributed file systems in accordance with at least one of the various embodiments. In at least one of the various embodiments, system 500 may be comprised of a file system management server computer, such as, file system management server computer 502, as well as, one or more storage computers, such as, storage node 504, storage node 506, storage node 508, or the like. In at least one of the various embodiments, file system management server computer 502, storage node 504, storage node 506, or storage node 508, may be comprised of network computers, similar to network computer 300.

In at least one of the various embodiments, each storage node may be interconnected over a network, such as, network 510. In at least one of the various embodiments, network 510 may be comprised similarly as wireless network 108 or network 110.

In at least one of the various embodiments, the storage nodes may be arranged to include one or more storage volumes, such as, storage devices 510, storage devices 512, or storage devices 514. In various embodiments, storage nodes may include more or fewer storage devices than illustrated in FIG. 5.

In one or more of the various embodiments, storage devices may be comprised of one or more physical storage devices, such as, hard disk drives (HDDs), solid state drives (SSDs) or the like.

In one or more of the various embodiments, one or more storage devices may be comprised virtualized storage objects provided by a cloud computing environment.

In at least one of the various embodiments, the functionality of file system management server computer 502 may be incorporated directly into one or more storage nodes, such as, storage node 504, storage node 506, storage node 508, or the like. In such embodiments a file system management application, such as, file system engine 322 or layout engine 324 may be operative on one or more of the storage nodes. Further, in at least one of the various embodiments, some or all functionality of the file system management server computer may be implemented directly on each storage node.

Further, in at least one of the various embodiments, file system management server computer 502 may be arranged to manage one or more distributed tasks of varying types that may be executed on the file system. In at least one of the various embodiments, task types may include, repair tasks, erasure coding (e.g., encoding and decoding) tasks, distributed data writes, cryptographic tasks, compression tasks, decompression tasks, arbitrary compute tasks, or the like.

In one or more of the various embodiments, file system engines may be present on each storage node. Accordingly, in some embodiments, file system engines on the different nodes in file system cluster may be arranged to elect a file system management server computer from among the one or more nodes in the file system cluster. One of ordinary skill in the art will appreciate the custom or conventional election methods may be employed to elect a management node from among the nodes in file system without departing from the scope of the innovations described herein. Further, in some embodiments, file system engines may be arranged to determine a particular election strategy from configuration information to account for local requirements or local circumstance. Also, in some embodiments, conditions that trigger election of a management node may vary depending of file system policy. Accordingly, in some embodiments, file system engines may be arranged to determine if an election may be held based on rules or conditions provided via configuration information to account for local requirements or local circumstances.

FIG. 6 illustrates a logical schematic of file system 600 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments.

In some embodiments, file system 600 may be comprised of a cluster of nodes. In this example, file system 600 includes three nodes each with four storage devices. In FIG. 6, the left ‘axis’ represent the nodes and storage devices. Accordingly, the first four rows from the top represent the first node and its four storage devices. Likewise, in this example, the next four rows represent the second node and its four storage devices. For brevity and clarity the rows are labeled using. to represent individual nodes and their respective storage devices. Thus, in this example, file system 600 includes three nodes each with four storage devices.

Further, in this example, the top axis (1, . . . , 15) represents boundaries or divisions between different block stores on each storage device. In some embodiments, portions of a storage device that correspond to block store may be referred to as slots. In this example, each storage device has room for 15 block stores. Thus, in this example, each storage device has 15 slots that each can be assigned one block store. Accordingly, a slot represents the portion of a storage device that may be required to store one block store.

In this example, slots in file system 600 that are illustrated to include an “X” may be considered to be slots that are used to store a block store. In some embodiments, some slots may be reserved for unused user capacity, administration space, reserved spare storage space, or the like. In some cases, for some embodiments, spare space in a file system (on one or more storage devices) may be reserved for re-protect or recovery operations to enable the file system to automatically recover from data failures that may be occur in a file system cluster. In this example, empty/unused slots are illustrated absent an X.

In one or more of the various embodiments, block stores may be associated with protection blocks. In some embodiments, protection groups in a file system may be sized to the same value throughout the file system. For example, a 100 GB protection group may be comprised of ten 10 GB block stores. Further, in some embodiments, protection group may store erasure code data used to enable data recovery if block stores in a protection group may be experience data failure. For example, a protection group configured to have a protection level of “1” may be considered protected against the loss of one of its included block stores. Similarly, for example, a a protection group configured to have a protection level of “3” may be considered protected against the loss of three of its included block stores. Note, the particular erasure coding algorithms or methods may vary such that one of ordinary skill in the art will appreciate that different erasure code algorithms may be selected depending on local circumstance or local requirements. Accordingly, in some cases, file system engines may be arranged to determine the particular erasure code methods based on configuration information.

In some embodiments, individual block stores associated with a protection group may be distributed across the file system cluster based on file system policy. For example, a file system policy may declare that a maximum of one block store of a protection group may be stored on the same storage device. Thus, in this example, if a storage device fails, the affected protection groups may recover and re-protected using erasure code information or data stored in their remaining block stores. Also, in some embodiments, a file system may be configured to limit the number of block stores of a given protection group that may be stored on the same file system node.

In some embodiments, allocation rules may be configured for a file system based on local requirements. For example, if an organization is configured to use protection groups that can avoid data loss even if two block stores are lost (e.g., protection level 2), the allocation policy may enforce a limit of two block stores of a single protection group on each file system. Thus, in this example, if an entire file system is lost, at most only two block stores from each protection group in the file system may be lost, enabling them all to be restored from the remaining block stores located on remaining nodes. In contrast, in some embodiments, if a protection group configured for protection level 2 had three block stores on the same node or storage device, the failure of that node or storage device would result in data loss since the number lost block stores would exceed the protection level of the protection group.

Accordingly, in some embodiments, file system engines may be arranged to distribute block stores associated with the same protection group across the file system cluster. In this example, protection group 604 represents a protection group with four associated block stores. In this example, the block stores that comprise protection group 604 may be observed in layout 602, indicating how they may be distributed across the file system. In this example, the block stores for protection group 604 are stored the 4th slot of storage device 3 of node 1; the 7th slot of storage device 2 on node 2; the 10th slot on storage device 2 of node 3; and the 13th slot of storage device 4 on node 3.

Further, in some embodiments, file system may be configured such that each protection group and block store has the same capacity. Further, in some embodiments, each protection group in the file system may have the same protection level. However, in some cases, for some embodiments, one or more protection groups may be configured to have different protection levels. For example, if a file system may be arranged to direct some data or data types to particular protection groups, those particular protection groups may be configured to have different protection levels. However, this may result in more complex management overhead so it may be advantageous to restrict protection groups in a file system to having the same capacity.

In some cases, for various reasons, an organization may desire to change the erasure code for a file system. For example, in some embodiments, an organization may desire increased protection level (or decreased protection level). Likewise, in some cases, for some embodiments, organizations may want to add more capacity to an existing file system. However, naively adding more capacity may result in less efficient storage. Thus, in some cases, organizations may be motivated to modify erasure coding for a file system for various reasons.

Conventionally, erasure coding methods may be classified based on the amount of protected blocks and the number required to restore lost blocks. For example, if a 10 block storage system allocates 9 blocks ( 9/10) of its capacity to data and one tenth ( 1/10) of its capacity for erasure code information, it may be referred to as using a 10/9 erasure code. Thus, a 10/9 erasure code system will have an efficiency of 90% because of the 10 blocks in the system, 9 are available for data storage. Likewise, a system with an erasure code of 10/8 would be considered less efficient because it has * blocks for data and 2 blocks for erasure code information resulting in an efficiency of 80%. Thus, naively increasing protection levels may decrease storage efficiency.

Similarly, naively increasing capacity may result in large amounts of potential capacity being unnecessarily allocation to erasure coding. For example, a 10 TB storage system that is 90% efficient would reserve 1 TB for erasure coding. If the 10 TB storage system is doubled to 20 TB, 2 TB would be reserved for erasure coding without providing increased protection levels.

In some embodiments, adding capacity implies adding more protection groups and distributing their associated block stores across the file system. Naive capacity increases would add more protection groups, each using that same sized block stores as the existing protection groups. However, in this case, the erasure code and erasure code efficiency would remain unchanged which may result in an undesirable amount of capacity being reserved for erasure coding.

Further, in some embodiments, adding capacity may coincide with an organization's intention to increase the protection level of its protection groups without reducing the storage efficiency of the protection groups. Conventionally, if more block stores (or portions of block stores) are allocated for storing erasure code information the overall storage efficiency of a protection group and the file system as a whole will be reduced. For example, converting a protection group from a 10/8 erasure code that protects against one data failure to a 10/8 erasure code that protects against two data failures would consume 20% versus 10%. Also, it would reduce the effective capacity of each protection group because more block stores would be dedicated to erasure code information.

Alternatively, in some embodiments, file system engines may be arranged to enable erasure code of protection groups to modified by reducing the size of the block stores associated with each protection group. For example, if a protection group has 10 block stores with 9 reserved for data and 1 reserved for erasure code information, re-configuring the protection group to use smaller block stores may enable the storage efficiency to be preserved or improved while maintaining the same or greater protection level. For example, the protection group with 10 block stores may be reconfigured to have 20 half-sized block stores. Thus, same as before, a protection level of 1, would require one block store reserved for erasure code information while 19 may be used for data. Similarly, in some embodiments, doubling the block stores while halving their size, would enable configuring the protection group to have protection level of two without reducing storage efficient. For example, in some embodiments, a ten-block stores wide protection group using an 10/9 erasure code that may be converted to use an 20/18 erasure code would have protection level of two without decreasing storage efficiency.

Note, in some embodiments, various file systems may employ a variety of layout policies, protection policies, or the like. Accordingly, in some embodiments, different file systems may employ different erasure coding, protection groups sizing, block store sizing, block store distribution policies, or the like, without departing from the scope of the innovations described herein. Accordingly, for brevity and clarity, details of particular erasure code algorithms, layout polices, and so on, are omitted from this description.

FIG. 7A illustrates a logical schematic of file system 700 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments.

Organizations may have a variety of reasons for modifying erasure codes. For example, in some embodiments, it may be advantageous to modify erasure codes if additional storage capacity may be added to file system because naively expanding capacity absent modifying erasure codes may result in an undesirable or otherwise disadvantageous amount of the storage capacity being dedicated to erasure code information.

Further, in many cases, it may be undesirable or disadvantageous for organizations to convert a file system from one erasure code to another in an offline mode that disables the file system while the file system is transcoded from one erasure code to another. Accordingly, in some embodiments, innovations described herein enable organizations to change erasure codes while the file system remains operational.

In some embodiments, transcoding a file system from one erasure code to another may require sufficient working space that is otherwise unused by the file system to enable in-place or online erasure code transcoding to take place. In some cases, erasure code modification may be desired if capacity is being added to an existing file system. Accordingly, in such scenarios, it may be expected that the original file system is reaching its effective capacity. Thus, in some embodiments, it may be likely that the current file system does not have enough unused capacity to support online or in-place erasure code transcoding.

Accordingly, in some embodiments, file system engines may be arranged to performing erasure code transcoding if the capacity of the file system is being increased. Thus, in some embodiments, the storage being added to the file system may provide the necessary workspace to enable erasure code transcoding.

In this example, for some embodiments, the original nodes and storage devices for file system 700 may be represented by layout 702. In this example, similar to layout 602 for file system 600, layout 702 shows slots and block stores used in file system 700. In this example, the current or original file system may be represented by layout portion 704. In one or more of the various embodiments, layout portion 706 may be considered to represent additional capacity that may be added to file system 700.

In one or more of the various embodiments, initially the slots in the newly added capacity (new nodes and new storage devices) may be unused such that the file system engines may be enabled to use the unused capacity to perform the actions for converting file system 700 to use a different erasure code.

Note, for brevity and clarity, in this example, a doubling of capacity is shown. However, the innovations described herein are not so limited. Accordingly, in some embodiments, more or less capacity may be added as long as the additional capacity may be sufficient to provide the working space for transcoding the file system to the new erasure code. In some embodiments, file system engines may be arranged to compute a minimum capacity increase based on the amount of unused capacity that may be required to perform the transcoding.

Also, for brevity and clarity, in this example, the new nodes and storage devices associated with layout portion 706 are illustrated as having the same number of storage devices and same amount of slots per storage device. In practice, in some embodiments, a file system may include nodes with different amount of storage devices or storage devices with different numbers of slots.

FIG. 7B illustrates a logical schematic of file system 700 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments.

In some embodiments, if additional capacity may be added to a file system layout (e.g., layout portion 706), file system engines may be arranged to balance the distribution of block stores in the file system to use the additional capacity. Accordingly, in some embodiments, file system engines may be arranged to create additional unused capacity (empty slots) on the nodes or storage devices of the original layout portion (e.g., layout portion 704). Thus, in this example, for some embodiments, half of the block stores from layout portion 704 may be copied to layout portion 706. Note, in some embodiments, file system engines may be arranged to copy these block stores using conventional or existing file system operations. Accordingly, in some embodiments, while the copying may consume bandwidth, compute cycles, or the like, the file system may otherwise remain operational. For example, in some embodiments, file system engines may copy block stores from layout portion 704 to layout portion 706 using existing file system features, such as, concurrency, locking, data transfer, indexing, or the like, that may be provided via ‘normal’ file system services that are mixed-in with servicing client activity or client requests.

FIG. 7C illustrates a logical schematic of file system 700 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments.

In one or more of the various embodiments, if the block stores from the original file system have been balanced or redistributed, as described above, file system engines may be arranged to clear space on each nodes and each storage devices to make room for block stores that may be transcoded to the new erasure code. Accordingly, in some embodiments, file system engines may be arranged to copy block stores from the last slots of the storage devices to empty slots that may be nearest to the beginning of the storage devices.

Accordingly, for example, the block store in the second slot of the third storage device of the second node (2.3, 2) of layout 702 represents a block store that was copied from the last slot of the third storage device of the second node. In some embodiments, file system engines may be arranged to copy block stores stored in the last slots into empty slots that are closer to the beginning of the slots until a desired number of slots may be cleared of block stores.

Further, in some embodiments, modifying the erasure code may require additional block stores. Accordingly, in some embodiments, file system engines may be arranged to divide the original slots into smaller block stores to support different erasure codes. Increasing the number of block stores per protection group enables the capacity of protection group to remain unchanged while enabling more efficient or resilient erasure codes. In this example, slots 708 illustrate how the original slot size may be reduced to enable more slots to be opened. Note, in some embodiments, these slots may have less capacity such that they block stores they support may have less capacity as well. But the protection groups that may eventually rely on these smaller slots may have the same capacity because they will map more block stores that are smaller than the original block stores.

Accordingly, in some embodiments, file system engines may be arranged to deprovision the original slots that, in this example, were included in rows 708. Thus, in some embodiments, the block stores previously stored in those slots may be moved to other slots. Then, if required, the file system engine may be arranged to reprovision slots in those portions of the file system/storage devices to match the size needed for new erasure code. For example, if a new erasure code requires twice as many block stores per protection group as the current/previous erasure code, the newly provisioned slots may be half the size of the prior slots.

FIG. 7D illustrates a logical schematic of file system 700 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments.

In this example, for some embodiments, the file system engine has continued to move block stores from slots at the end of the storage devices to other empty slots. Here, in this example, three bands of original sized block stores have been moved to original sized slots. In this example, for some embodiments, the file system engine has reprovisioned the empty space (e.g., slots 710) into slots that may be half the size of the original slots. Note, one of ordinary experience in the art will appreciate the “new” slots may be reprovisioned to a size based on the particular erasure code, data protection algorithms, or the like, rather than being limited to any particular fraction of the previous slot-size.

In some embodiments, file system engines may be arranged to continue moving original sized block stores and reorganizing the ‘new’ slots at least until there may be enough room in the new slots to store one or more protection groups. Accordingly, in some embodiments, file system engines may be arranged to monitor the capacity of the new slots to determine if one or more protection groups may be moved into the new slots. In some embodiments, if unused space is limited in the original size slots, file system engines may be arranged to begin moving protection groups as soon as possible. Otherwise, in some embodiments, file system engines may be arranged to move protection groups based on other rules or policies. For example, in some embodiments, file system engines may be configured to continue moving original sized block stores until there may be enough room for a defined number of protection groups before beginning to move block stores from the original sized slots to the resized slots. Thus, in some embodiments, the file system will maintain at least the same fault tolerance/protection levels during the transition to the new erasure code.

In one or more of the various embodiments, the portion of the file system that is reconfigured to have new-sized block stores may be considered to be a separate logical partition. Thus, in some embodiments, file system engines may allocate new or pending write operations to the new sized partition. Generally, in some embodiments, file system engines may be arranged to randomly balance incoming data writes to particular nodes, storage devices, protection groups, or the like, as per its normal operation policies. Accordingly, in some embodiments, data from some new writes may be assigned to protection groups that are stored in the partition with the new-sized slots (e.g., partition 710). Thus, in one or more of the various embodiments, file system engines may be arranged to encode such data using the new erasure code before storing it in the new partitions.

FIG. 8 illustrates a logical schematic of protections groups for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments. As described above, for some embodiments, protection groups may be composed of one or more block stores. In some embodiments, file system engines may be arranged to distribute individual block stores that comprise protection groups in slots that are spread throughout the file system. Thus, in this example, even though protection group 802A is represented as storing block stores contiguously, in practice file system engines may be arranged to spread these block stores around the file system to conform to data safety policies, or the like. See, FIG. 6 and its description.

Also, in this example, protection group 802A may be considered to represent a protection group before the data is transcoded to a new erasure code and protection group 802B may represent the same protection group after it has been transcoded to a new erasure code. This example illustrates how the capacity of protection groups remains the same but with an increased number of block stores after transcoding to a new erasure code. For example, in some embodiments, block store 804 may be transcoded into block store 806 and block store 808. Note, in this example, the number of block stores is doubled. However, in practice, the number of block stores in the new version of the protection groups may vary depending on the particular erasure code being used or other file system policy considerations. Also, in some embodiments, as block stores may be composed of smaller file system objects (e.g., blocks), the contents of one particular block store may be distributed to any number of block stores in the protection group. Accordingly, the apparent direct mapping of block store 804 directly to block store 806 and block 808 shown in FIG. 8 should be considered a simplified non-limiting example.

Generalized Operations

FIGS. 9-11 represent generalized operations for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments. In one or more of the various embodiments, processes 900, 1000, and 1100 described in conjunction with FIGS. 9-11 may be implemented by or executed by one or more processors on a single network computer, such as network computer 300 of FIG. 3. In other embodiments, these processes, or portions thereof, may be implemented by or executed on a plurality of network computers, such as network computer 300 of FIG. 3. In yet other embodiments, these processes, or portions thereof, may be implemented by or executed on one or more virtualized computers, such as, those in a cloud-based environment. However, embodiments are not so limited and various combinations of network computers, client computers, or the like may be utilized. Further, in one or more of the various embodiments, the processes described in conjunction with FIGS. 9-11 may perform actions for in-place erasure code transcoding for distributed file systems in accordance with at least one of the various embodiments or architectures such as those described in conjunction with FIGS. 4-8. Further, in one or more of the various embodiments, some or all of the actions performed by processes 900, 1000, and 1100 may be executed in part by file system engine 322.

FIG. 9 illustrates an overview flowchart for process 900 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments. After a start flowchart block, at flowchart block 902, in one or more of the various embodiments, a new or updated erasure code specification may be provided to a file system engine. As described above, erasure code specifications may declare or define various features associated with protecting against data loss in case of storage failures. For example, erasure code specification may declare protection levels, specific erasure code algorithms, or the like. Note, one of ordinary skill in the art will appreciate that the innovations disclosed herein are generally independent from the specific erasure code algorithms that may be used. Accordingly, in some embodiments, file system engines may be arranged to determine the particular erasure code or erasure code specification for a file system based on configuration information to account for local requirements or local circumstances.

At flowchart block 904, in one or more of the various embodiments, optionally, additional storage nodes or storage devices may be provided to a file system. As described herein, it may be advantageous for organizations to modify erasure code specifications if they are adding storage to a file system. Namely, because, for example, adding storage capacity without updating the erasure code may result in less than optimal storage efficiency. Other reasons may include changes in data loss risk policies, changes in device capacity, device performance characteristics, or the like. Note, adding additional storage at this point may not increase the amount of storage available to users because, in some embodiments, the amount of user accessible storage may be tied to the number of protection groups in the file system. Thus, in some embodiments, at this stage, the number of available protection groups may not have increased even though there may be more additional storage space because of the addition of storage nodes or storage devices.

In some embodiments, the file system may have sufficient unused or unallocated space to enable in-place erasure code transcoding to the new erasure code specification. Thus, in some cases, additional storage may not be required for in-place erasure code transcoding.

Note, this flowchart block is indicated as being optional because in some cases the file system may include sufficient unused space to enable in-place erasure code transcoding for distributed file systems rather than requiring additional storage nodes or storage devices to provide the necessary working space for erasure code transcoding.

At flowchart block 906, in one or more of the various embodiments, file system engines may be arranged to distribute block stores in the file system into the new storage space. In some embodiments, file system engines may be arranged to move a proportion of the block stores from the original storage space to the added storage space. Accordingly, in some embodiments, additional room may be provided to facility efficient conversion to the new erasure code specification.

At flowchart block 908, in one or more of the various embodiments, file system engines may be arranged to incrementally clear storage slots from a partition that used the new erasure code. As described above, in some embodiments, file system engines may incrementally move block stores from slots at the ‘end’ of storage devices to slots nearest the beginning of the storage devices. Accordingly, in some embodiments, a portion of the file system may be cleared of block stores. In some cases, for brevity or clarity, the cleared space may be referred to as a new partition since the file system engines may logically track the boundary between the slots that are cleared and the other non-cleared slots in the file system.

At flowchart block 910, in one or more of the various embodiments, file system engines may be arranged to incrementally transcode and move block stores into the cleared partition. In one or more of the various embodiments, file system engines may reformat the new partition to support block sizes based on the new erasure code specification and move block stores from the original partition to the new partition. Accordingly, in some embodiments, file system engines may be arranged to transcode the block stores being moved into the new erasure code. In some embodiments, file system engines may be arranged to move all the block stores for the same protection group at the same time so the new erasure code specification may be applied to the protection group as a whole.

At flowchart block 912, in one or more of the various embodiments, file system engines may be arranged to enable file system clients/users to access the new file system capacity. In some embodiments, file system engines may generate or enable additional protection groups in the remaining storage space. Accordingly, in some embodiments, if the protection groups using the old erasure code specification have been converted to the new erasure code specification, the file system engines may release additional protection groups to the file system for use by clients/users. Going forward these released protection groups may use the new erasure code specification.

In one or more of the various embodiments, file system engines may be arranged to incrementally release transcoded storage capacity to the users of the file system as it is provisioned or transcoded.

At flowchart decision block 914, in one or more of the various embodiments, if the transcoding to the new erasure code may be complete, control may be returned to a calling process; otherwise, control may loop back to block 908.

FIG. 10 illustrates a flowchart for process 1000 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments. After a start flowchart block, at flowchart block 1002, in one or more of the various embodiments, optionally, new or additional storage nodes or storage devices may be added to the file system.

In some cases, organizations may be motivated to modify erasure code specification for various reasons, such as, changes to data loss risk policies, data, desired storage efficiency, or the like. For example, as described above, naively adding storage capacity to a file system may lead to a loss in storage efficiency for some erasure codes or non-optimal erasure code for the resulting file system. Thus, in some cases, it may be advantageous for organizations to change erasure codes if they may be expanding the capacity of a file system.

In some cases, the current file system may be close to its capacity before an organization decides to change erasure codes. Accordingly, in some embodiments, the file system may not have enough unused space to provide working space that may be required for converting to a new erasure code without disruption to the operation of the file system. For example, in many cases, it may be disadvantageous to shutdown the file system and use other off-line/auxiliary storage to perform the conversion. Thus, it may be advantageous to convert a file system to a different erasure code when the additional capacity is being added to the system. In some embodiments, this may enable the file system engine to use the additional storage space to facilitate the conversion to the new erasure code before increasing the releasing the additional capacity for use by users/clients.

Accordingly, in some embodiments, file system engines may be arranged to recognize the added storage nodes or storage devices for use in the conversion to the new erasure code specification while not immediately releasing the storage space to the file system as a whole. Accordingly, in some embodiments, the added storage nodes or storage devices may be unavailable for general user level capacity until the conversion to the new erasure code specification may be completed.

In some cases, there may be enough unused capacity in the current set of storage nodes or storage devices to enable file system engines to convert the file system to the new erasure code specification. For example, if a new file system is deployed with a first erasure code specification, the organization may soon determined they need increased protection from data loss. In this case, for some embodiments, the file system may be converted to the new erasure code specification without attaching additional storage nodes or storage devices.

In one or more of the various embodiments, user capacity may be determined by the number protection groups that are available for storing user data. Accordingly, in some embodiments, simply adding new storage nodes or storage devices without formatting/configuring more protection groups for the users may provide an increased working space without effectively increasing the amount of storage that may be available to file system clients.

At flowchart block 1004, in one or more of the various embodiments, file system engines may be arranged to determine one or more block stores to move. In one or more of the various embodiments, file system engines may be configured to employ various selection strategies for determining which block stores should be moved from the original storage nodes or storage devices to new storage nodes or storage devices. For example, in some cases, file system engines may be arranged to randomly select block stores to move from the original storage devices to the newly added storage space. In other cases, other considerations may be taken, such as treating recently accessed or actively accessed block stores differently from less active block stores. For example, in some embodiments, file system engines may be configured to move block stores based on one or more activity metrics. Accordingly, in some embodiments, file system engines may be arranged to employ rules, instructions, or the like, provided via configuration information to determine which how to select block stores for moving to the added storage to account for local requirements or local circumstances.

Further, in some embodiments, other transient circumstances, such as, active locks, caching considerations, or the like, may influence if or when block stores are moved from the original storage to the new storage.

At flowchart block 1006, in one or more of the various embodiments, file system engines may be arranged to move the one or more block stores from the original slots to new slots. In one or more of the various embodiments, file system engines may be arranged to move the selected block stores to the added storage. In some embodiments, file system engines may be arranged to employ otherwise built-in functionality for moving data within the file system. Accordingly, in some embodiments, actions or operations related to caching, lock contention, or the like, may be performed as part of the general feature set of the file system. Likewise, in some embodiments, since many block stores are located on different storage nodes or storage devices, the moving of block stores to the added storage may be a highly parallelizable operation. In some embodiments, file system engines may be arranged to determine the amount of file system resources, such as, bandwidth, compute resources, or the like, based on configuration information. Thus, in some cases, moving the block stores may be prioritized or de-prioritized based on one or more file system policies.

At flowchart decision block 1008, in one or more of the various embodiments, if there may be more block stores to move, control may loop back to flowchart block 1006; otherwise, control may be returned to a calling process.

In one or more of the various embodiments, file system engines may be configured to move a portion of block stores sufficient to ensure that there may be enough working space in the original storage spaces to enable the transcoding to enable conversion to the new erasure code specification. In some cases, for some embodiments, file system engines may be configured to move a proportion of block stores based on the proportion of new storage space that is added. In other cases, for some embodiments, file system engines may be arranged to re-balance the block stores in the file system evenly across the old storage and the new storage.

Note, in some embodiments, as mentioned, moving the block stores or evenly re-balancing them may not increase the amount of storage available to users because new protection groups are not being made available. Here, the file system engines may be moving block stores while leaving their association with their protection groups in place.

In some embodiments, file system engines may be arranged to update internal indexes to maintain the relationships between the block stores and their protection groups. Note, one of ordinary skill in the art will appreciate that the particular data structures, file system tables, or the like, used for associating block stores with protection groups may vary depending on the underlying architecture of the file system without departing from the scope of the innovations disclosed herein.

FIG. 11 illustrates a flowchart for process 1100 for in-place erasure code transcoding for distributed file systems in accordance with one or more of the various embodiments. After a start flowchart block, at flowchart block 1102, in one or more of the various embodiments, file system engines may be provided a new erasure code specification and determined a new block store size. As described above, erasure code specifications may specify various characteristics or criteria for a data protection policy. Accordingly, in some embodiments, file system engines may be arranged to determine a new block store size that may enable the file system to conform to the new erasure code specification while keeping the storage size/capacity of protection groups unchanged.

At flowchart block 1104, in one or more of the various embodiments, file system engines may be arranged to file system engines may be arranged to clear space for a new partition. In one or more of the various embodiments, file system engines may be arranged to designate a portion of the existing file system to be a new partition. The new partition may be designated to store data using the new erasure code specification. Also, in some cases, portions of the new partition may be temporarily used as a working space to perform erasure code transcoding if needed.

In some embodiments, file system engines may be arranged to reserve one or more slots on one or more of the storage devices that comprise the file system as the new partition. In the examples, shown above, file system engines may reserve an equal number of slots from storage devices for the new partition. However, in some embodiments, in practice one or more storage devices may have a different number of slots. Thus, in some embodiments, in some cases, the number of slots reserved for the new partition may be different across storage nodes or storage devices. However, in some embodiments, generally, file system engines may be arranged to assign slots at the nearest the end of storage devices to the new partition.

At flowchart block 1106, in one or more of the various embodiments, file system engines may be arranged to format/prepare the cleared partition to employ the new block store size. In some embodiments, file systems may be arranged to employ various data structures, configuration values, constraints, parameters, or the like, that may declare or enforce block store sizes. Accordingly, in some embodiments, formatting the cleared partition may include modifying one or more data structures, configuration values, constraints, parameters, or the like, to set the block store size for the new partition to conform the new partition to the new erasure code specification. Note, the particular action may depend on the underlying structure of the particular file system. For example, in some embodiments, formatting a partition to a new block store size may include setting a single value (a new block store size) in a configuration set. However, one of ordinary skill in the art will appreciate the implementation details associated with setting the block store size of a particular file system or file system partition may be well-known for a given file system.

At flowchart decision block 1108, in one or more of the various embodiments, file system engines may be arranged to if there may be protection groups to move to the new partition, control may flow to flowchart block 1104; otherwise, control may flow to flowchart block 1110.

In one or more of the various embodiments, file system engines may be arranged to apply the new erasure code specification to protection groups rather than to individual block stores. Accordingly, in some embodiments, file system engines may be arranged to move the block stores associated with the same protection group to the new partition. Thus, in some embodiments, if the new partition has room for at least one protection group, file system engines may begin moving block stores for the at least one protection group to the new partition.

Further, in some embodiments, file system engines may be configured to defer moving block stores until there may be enough room in the new partition to hold two or more protection groups rather than one protection group. For example, in some embodiments, a file system engine may be configured to move protection groups in groups of five, or the like, rather than being limited to moving one at a time. Generally, the determination of how many protection groups to move at a time may depend on file system policies, system resource/bandwidth allocation, priority determinations, emergencies, or the like. Accordingly, in one or more of the various embodiments, file system engines may be arranged to move and transcode data associated with a protection group to the new partition if it may be considered feasible and safe. For example, there must be sufficient space in the new partition and the file system must be able guarantee that configured data protection levels will be met after the move.

At flowchart block 1110, in one or more of the various embodiments, file system engines may be arranged to determine one or more block stores associated with a protection group.

In one or more of the various embodiments, each protection group may be associated with a number of block stores. For example, if protection groups in a file system are configured to be 100 GB and block stores are configured to be 1 GB, there may be 100 block stores per protection group.

In some embodiments, block stores for a protection group may be distributed throughout the ‘old’ partition in the file system. Accordingly, in some embodiments, file system engines may be arranged to determine block stores that are stored in storage nodes or storage devices across the file system even though the block stores are associated with the same protection group.

At flowchart block 1112, in one or more of the various embodiments, file system engines may be arranged to transcode and move block stores to the cleared partition.

In one or more of the various embodiments, file system engines may be arranged to apply the new erasure code specification to each protection group. Accordingly, in some embodiments, file system engines may generate new protection groups that use the new erasure code specification and new block store size by designating a new protection group in the new partition such that data moved from the old protection groups is transcoded and stored in the new protection group using block stores with the new block store size. In some embodiments, the operations include identifying the protection group of interest and its associated block stores; transcoding the data from those block stores to conform to the new erasure code specification; storing the transcoded block stores in the new partition.

In some embodiments, transcoding may include updating one or more data structures, indexes, file system tables, or the like, to reflect that the data from the ‘old’ protection group is located in the new protection group. Accordingly, in some embodiments, if a protection group has been transcoded and moved to the new protection group in the new partition it may be immediately available for client access. From the point of view of the file system clients the transcoding/move operation may be opaque or otherwise unnoticed because it occurs below the level of the client view of the file system.

At flowchart decision block 1114, in one or more of the various embodiments, if there may be more protection groups to transcode and move, control may loop back to flowchart block 1104 or flowchart block 1110; otherwise, control may be returned to a calling process. In some embodiments, if there may be space available in the new partition for more protection groups, control may flow to flowchart block 1110 or if more space needs to be cleared in the new partition, control may flow to flowchart block 1104.

It will be understood that each block in each flowchart illustration, and combinations of blocks in each flowchart illustration, can be implemented by computer program instructions. These program instructions may be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in each flowchart block or blocks. The computer program instructions may be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process such that the instructions, which execute on the processor, provide steps for implementing the actions specified in each flowchart block or blocks. The computer program instructions may also cause at least some of the operational steps shown in the blocks of each flowchart to be performed in parallel. Moreover, some of the steps may also be performed across more than one processor, such as might arise in a multi-processor computer system. In addition, one or more blocks or combinations of blocks in each flowchart illustration may also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the invention.

Accordingly, each block in each flowchart illustration supports combinations of means for performing the specified actions, combinations of steps for performing the specified actions and program instruction means for performing the specified actions. It will also be understood that each block in each flowchart illustration, and combinations of blocks in each flowchart illustration, can be implemented by special purpose hardware based systems, which perform the specified actions or steps, or combinations of special purpose hardware and computer instructions. The foregoing example should not be construed as limiting or exhaustive, but rather, an illustrative use case to show an implementation of at least one of the various embodiments of the invention.

Further, in one or more embodiments (not shown in the figures), the logic in the illustrative flowcharts may be executed using an embedded logic hardware device instead of a CPU, such as, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), Programmable Array Logic (PAL), or the like, or combination thereof. The embedded logic hardware device may directly execute its embedded logic to perform actions. In one or more embodiments, a microcontroller may be arranged to directly execute its own embedded logic to perform actions and access its own internal memory and its own external Input and Output Interfaces (e.g., hardware pins or wireless transceivers) to perform actions, such as System On a Chip (SOC), or the like.

Claims

1. A method for managing data over a network using one or more processors that execute instructions to perform actions, comprising: providing a file system that includes a plurality of protection groups that each are associated with a plurality of block stores, wherein each block store associated with the plurality of protection groups is encoded based on a first erasure code and a first block store size;storing each of the one or more block stores in one or more of plurality of slots that are defined for separately storing a block store on a different one of a plurality of storage devices that are separately located in the file system;dividing the file system into a first partition and a second partition, wherein a portion of a storage space in the file system is shifted from the first partition to the second partition to provide sufficient storage space for one or more of the plurality of protection groups in the second partition based on a specification for a second erasure code, and wherein the first partition is associated with the first erasure code and the second partition is associated with the second erasure code;in response to adding one or more additional storage devices to the storage space of the file system, providing additional storage space to the second partition;in response to the second partition having sufficient storage space to store one or more of the plurality of protection groups, performing further actions, including: determining one or more block stores in the first partition associated with the one or more protection groups;transcoding contents of the one or more block stores into one or more other block stores based on the second erasure code and a second block store size, wherein the one or more other block stores are sized based on the second block store size for the second erasure code;storing the one or more other block stores in the second partition, wherein the one or more other block stores are stored in one or more of plurality of slots that are defined for separately storing the one or more other block stores on different storage devices that are separately located in the file system;deleting the one or more block stores from the first partition; andshifting another portion of the storage space from the first partition to the second partition, wherein the shifted other portion increases a size of the second partition to provide sufficient storage space for one or more other protection groups and the first partition is decreased in size based on the deletion of the one or more block stores; andin response to the second partition reaching a maximum size, reporting that the file system is encoded based on the second erasure code.
2. The method of claim 1, further comprising: providing one or more client requests to the file system; andsatisfying the one or more client requests using contents from one or more of the first partition or the second partition.
3. The method of claim 1, further comprising: moving a portion of plurality of the block stores in the first partition to provide storage space for the second partition.
4. The method of claim 1, further comprising: in response to one or more storage devices being added to the file system, distributing a portion of the plurality of block stores to the one or more added storage devices to provide working space in the file system to transcode the plurality of block stores based on the second erasure code.
5. The method of claim 1, wherein transcoding the contents of the one or more block stores into one or more other block stores, further comprises: disassociating the one or more block stores from the one or more protection groups; andassociating the one or more other block stores with the one or more protection groups, wherein a storage capacity, protection level, and availability of each of the one or more protection groups remains unchanged.
6. The method of claim 1, further comprising: in response to modifying the file system with one or more additional storage devices, performing additional actions, including: determining a storage inefficiency value for the modified file system based on the first erasure code;determining a data loss risk value for the modified file system based on the first erasure code; andin response to one or more of the storage inefficiency value or the data loss risk value exceeding a threshold value, converting the modified file system to protect its contents based on the second erasure code.
7. A system for managing data comprising: a network computer, comprising: a memory that stores at least instructions; andone or more processors that execute instructions that are configured to cause performance of actions, including: providing a file system that includes a plurality of protection groups that each are associated with a plurality of block stores, wherein each block store associated with the plurality of protection groups is encoded based on a first erasure code and a first block store size;storing each of the one or more block stores in one or more of plurality of slots that are defined for separately storing a block store on a different one of a plurality of storage devices that are separately located in the file system;dividing the file system into a first partition and a second partition, wherein a portion of a storage space in the file system is shifted from the first partition to the second partition to provide sufficient storage space for one or more of the plurality of protection groups in the second partition based on a specification for a second erasure code, and wherein the first partition is associated with the first erasure code and the second partition is associated with the second erasure code;in response to adding one or more additional storage devices to the storage space of the file system, providing additional storage space to the second partition;in response to the second partition having sufficient storage space to store one or more of the plurality of protection groups, performing further actions, including: determining one or more block stores in the first partition associated with the one or more protection groups;transcoding contents of the one or more block stores into one or more other block stores based on the second erasure code and a second block store size, wherein the one or more other block stores are sized based on the second block store size for the second erasure code;storing the one or more other block stores in the second partition, wherein the one or more other block stores are stored in one or more of plurality of slots that are defined for separately storing the one or more other block stores on different storage devices that are separately located in the file system;deleting the one or more block stores from the first partition; andshifting another portion of the storage space from the first partition to the second partition, wherein the shifted other portion increases a size of the second partition to provide sufficient storage space for one or more other protection groups and the first partition is decreased in size based on the deletion of the one or more block stores; andin response to the second partition reaching a maximum size, reporting that the file system is encoded based on the second erasure code; anda client computer, comprising: a memory that stores at least instructions; andone or more processors that execute instructions that are configured to cause performance of actions, including, providing one or more of one or more client requests or information associated with the second erasure code.
8. The system of claim 7, wherein the one or more network computer processors execute instructions that perform actions, further comprising: providing one or more client requests to the file system; andsatisfying the one or more client requests using contents from one or more of the first partition or the second partition.
9. The system of claim 7, wherein the one or more network computer processors execute instructions that perform actions, further comprising: moving a portion of plurality of the block stores in the first partition to provide storage space for the second partition.
10. The system of claim 7, wherein the one or more network computer processors execute instructions that perform actions, further comprising: in response to one or more storage devices being added to the file system, distributing a portion of the plurality of block stores to the one or more added storage devices to provide working space in the file system to transcode the plurality of block stores based on the second erasure code.
11. The system of claim 7, wherein transcoding the contents of the one or more block stores into one or more other block stores, further comprises: disassociating the one or more block stores from the one or more protection groups; andassociating the one or more other block stores with the one or more protection groups, wherein a storage capacity, protection level, and availability of each of the one or more protection groups remains unchanged.
12. The system of claim 7, wherein the one or more network computer processors execute instructions that perform actions, further comprising: in response to modifying the file system with one or more additional storage devices, performing additional actions, including: determining a storage inefficiency value for the modified file system based on the first erasure code;determining a data loss risk value for the modified file system based on the first erasure code; andin response to one or more of the storage inefficiency value or the data loss risk value exceeding a threshold value, converting the modified file system to protect its contents based on the second erasure code.
13. A processor readable non-transitory storage media that includes instructions that are configured to cause actions for managing data in over a network, wherein execution of the instructions by one or more processors on one or more network computers performs actions, comprising: providing a file system that includes a plurality of protection groups that each are associated with a plurality of block stores, wherein each block store associated with the plurality of protection groups is encoded based on a first erasure code and a first block store size;storing each of the one or more block stores in one or more of plurality of slots that are defined for separately storing a block store on a different one of a plurality of storage devices that are separately located in the file system;dividing the file system into a first partition and a second partition, wherein a portion of a storage space in the file system is shifted from the first partition to the second partition to provide sufficient storage space for one or more of the plurality of protection groups in the second partition based on a specification for a second erasure code, and wherein the first partition is associated with the first erasure code and the second partition is associated with the second erasure code;in response to adding one or more additional storage devices to the storage space of the file system, providing additional storage space to the second partition;in response to the second partition having sufficient storage space to store one or more of the plurality of protection groups, performing further actions, including: determining one or more block stores in the first partition associated with the one or more protection groups;transcoding contents of the one or more block stores into one or more other block stores based on the second erasure code and a second block store size, wherein the one or more other block stores are sized based on the second block store size for the second erasure code;storing the one or more other block stores in the second partition, wherein the one or more other block stores are stored in one or more of plurality of slots that are defined for separately storing the one or more other block stores on different storage devices that are separately located in the file system;deleting the one or more block stores from the first partition; andshifting another portion of the storage space from the first partition to the second partition, wherein the shifted other portion increases a size of the second partition to provide sufficient storage space for one or more other protection groups and the first partition is decreased in size based on the deletion of the one or more block stores; andin response to the second partition reaching a maximum size, reporting that the file system is encoded based on the second erasure code.
14. The media of claim 13, further comprising: providing one or more client requests to the file system; andsatisfying the one or more client requests using contents from one or more of the first partition or the second partition.
15. The media of claim 13, further comprising: moving a portion of plurality of the block stores in the first partition to provide storage space for the second partition.
16. The media of claim 13, further comprising: in response to one or more storage devices being added to the file system, distributing a portion of the plurality of block stores to the one or more added storage devices to provide working space in the file system to transcode the plurality of block stores based on the second erasure code.
17. The media of claim 13, wherein transcoding the contents of the one or more block stores into one or more other block stores, further comprises: disassociating the one or more block stores from the one or more protection groups; andassociating the one or more other block stores with the one or more protection groups, wherein a storage capacity, protection level, and availability of each of the one or more protection groups remains unchanged.
18. The media of claim 13, further comprising: in response to modifying the file system with one or more additional storage devices, performing additional actions, including: determining a storage inefficiency value for the modified file system based on the first erasure code;determining a data loss risk value for the modified file system based on the first erasure code; andin response to one or more of the storage inefficiency value or the data loss risk value exceeding a threshold value, converting the modified file system to protect its contents based on the second erasure code.
19. A network computer for managing data, comprising: a memory that stores at least instructions; andone or more processors that execute instructions that are configured to cause performance of actions, including: providing a file system that includes a plurality of protection groups that each are associated with a plurality of block stores, wherein each block store associated with the plurality of protection groups is encoded based on a first erasure code and a first block store size;storing each of the one or more block stores in one or more of plurality of slots that are defined for separately storing a block store on a different one of a plurality of storage devices that are separately located in the file system;dividing the file system into a first partition and a second partition, wherein a portion of a storage space in the file system is shifted from the first partition to the second partition to provide sufficient storage space for one or more of the plurality of protection groups in the second partition based on a specification for a second erasure code, and wherein the first partition is associated with the first erasure code and the second partition is associated with the second erasure code;in response to adding one or more additional storage devices to the storage space of the file system, providing additional storage space to the second partition;in response to the second partition having sufficient storage space to store one or more of the plurality of protection groups, performing further actions, including: determining one or more block stores in the first partition associated with the one or more protection groups;transcoding contents of the one or more block stores into one or more other block stores based on the second erasure code and a second block store size, wherein the one or more other block stores are sized based on the second block store size for the second erasure code;storing the one or more other block stores in the second partition, wherein the one or more other block stores are stored in one or more of plurality of slots that are defined for separately storing the one or more other block stores on different storage devices that are separately located in the file system;deleting the one or more block stores from the first partition; andshifting another portion of the storage space from the first partition to the second partition, wherein the shifted other portion increases a size of the second partition to provide sufficient storage space for one or more other protection groups and the first partition is decreased in size based on the deletion of the one or more block stores; andin response to the second partition reaching a maximum size, reporting that the file system is encoded based on the second erasure code.
20. The network computer of claim 19, wherein the one or more processors execute instructions that perform actions further comprising: providing one or more client requests to the file system; andsatisfying the one or more client requests using contents from one or more of the first partition or the second partition.
21. The network computer of claim 19, wherein the one or more processors execute instructions that perform actions further comprising: moving a portion of plurality of the block stores in the first partition to provide storage space for the second partition.
22. The network computer of claim 19, wherein the one or more processors execute instructions that perform actions further comprising: in response to one or more storage devices being added to the file system, distributing a portion of the plurality of block stores to the one or more added storage devices to provide working space in the file system to transcode the plurality of block stores based on the second erasure code.
23. The network computer of claim 19, wherein transcoding the contents of the one or more block stores into one or more other block stores, further comprises: disassociating the one or more block stores from the one or more protection groups; andassociating the one or more other block stores with the one or more protection groups, wherein a storage capacity, protection level, and availability of each of the one or more protection groups remains unchanged.
24. The network computer of claim 19, wherein the one or more processors execute instructions that perform actions further comprising: in response to modifying the file system with one or more additional storage devices, performing additional actions, including: determining a storage inefficiency value for the modified file system based on the first erasure code;determining a data loss risk value for the modified file system based on the first erasure code; andin response to one or more of the storage inefficiency value or the data loss risk value exceeding a threshold value, converting the modified file system to protect its contents based on the second erasure code.

US Referenced Citations (458)

Number	Name	Date	Kind
5165031	Pruul et al.	Nov 1992	A
5283875	Gibson et al.	Feb 1994	A
5319773	Britton et al.	Jun 1994	A
5410684	Ainsworth et al.	Apr 1995	A
5410719	Shackleford	Apr 1995	A
5442561	Yoshizawa et al.	Aug 1995	A
5953719	Kleewein et al.	Sep 1999	A
6049809	Raman et al.	Apr 2000	A
6236996	Bapat et al.	May 2001	B1
6385641	Jiang et al.	May 2002	B1
6415283	Conklin	Jul 2002	B1
6496944	Hsiao et al.	Dec 2002	B1
6529998	Yochai et al.	Mar 2003	B1
6560615	Zayas et al.	May 2003	B1
6772435	Thexton et al.	Aug 2004	B1
6874130	Baweja et al.	Mar 2005	B1
6892211	Hitz et al.	May 2005	B2
6965903	Agarwal et al.	Nov 2005	B1
6965936	Wipfel et al.	Nov 2005	B1
7072911	Doman et al.	Jul 2006	B1
7165158	Yagawa	Jan 2007	B1
7213040	Stokes et al.	May 2007	B1
7330948	Deguchi et al.	Feb 2008	B2
7467333	Keeton et al.	Dec 2008	B2
7594138	Abdulvahid	Sep 2009	B2
7636743	Erofeev	Dec 2009	B2
7693876	Hackworth et al.	Apr 2010	B2
7757056	Fair	Jul 2010	B1
7761456	Cram et al.	Jul 2010	B1
7844580	Srivastava et al.	Nov 2010	B2
7933870	Webster	Apr 2011	B1
7937421	Mikesell et al.	May 2011	B2
7956293	Echigo et al.	Jun 2011	B2
7958304	Goel	Jun 2011	B1
7962709	Agrawal	Jun 2011	B2
7966293	Owara et al.	Jun 2011	B1
8027827	Bitar et al.	Sep 2011	B2
8046378	Zhuge et al.	Oct 2011	B1
8108429	Sim-Tang et al.	Jan 2012	B2
8296312	Leung et al.	Oct 2012	B1
8341540	Haynes et al.	Dec 2012	B1
8355407	Wookey et al.	Jan 2013	B2
8364648	Sim-Tang	Jan 2013	B1
8423733	Ozdemir	Apr 2013	B1
8423821	Keith, Jr.	Apr 2013	B1
8448170	Wipfel et al.	May 2013	B2
8463825	Harty et al.	Jun 2013	B1
8489656	Erofeev	Jul 2013	B2
8504733	Iyer et al.	Aug 2013	B1
8515911	Zhou et al.	Aug 2013	B1
8612404	Bone et al.	Dec 2013	B2
8612488	Subramanya et al.	Dec 2013	B1
8645323	Jackiewicz et al.	Feb 2014	B2
8661447	Olliff et al.	Feb 2014	B1
8725691	Natanzon	May 2014	B1
8776050	Plouffe et al.	Jul 2014	B2
8782655	Blanding et al.	Jul 2014	B2
8805786	Natanzon	Aug 2014	B1
8806154	Gupta et al.	Aug 2014	B1
8838887	Burke et al.	Sep 2014	B1
8838931	Marshak et al.	Sep 2014	B1
8849754	Craggs	Sep 2014	B2
8849764	Long et al.	Sep 2014	B1
8849809	Seshadri	Sep 2014	B1
8868797	Kirac et al.	Oct 2014	B1
8924364	Zhong et al.	Dec 2014	B1
8972694	Dolan et al.	Mar 2015	B1
9015214	Nishida et al.	Apr 2015	B2
9026765	Marshak et al.	May 2015	B1
9031994	Cao et al.	May 2015	B1
9032170	Vaghani et al.	May 2015	B2
9047017	Dolan et al.	Jun 2015	B1
9141633	Li et al.	Sep 2015	B1
9143379	Berger et al.	Sep 2015	B1
9158653	Gold	Oct 2015	B2
9171145	Dash et al.	Oct 2015	B2
9244975	Das et al.	Jan 2016	B2
9244976	Zhang et al.	Jan 2016	B1
9361187	Jarvis	Jun 2016	B2
9384252	Akirav et al.	Jul 2016	B2
9459804	Natanzon et al.	Oct 2016	B1
9501487	Yuan et al.	Nov 2016	B1
9519664	Kharatishvili et al.	Dec 2016	B1
9547560	Lee	Jan 2017	B1
9600193	Ahrens et al.	Mar 2017	B2
9727432	Cutforth et al.	Aug 2017	B1
9747171	Beeken et al.	Aug 2017	B2
9753782	Fang et al.	Sep 2017	B2
9753932	Brow et al.	Sep 2017	B1
9753987	Dolan et al.	Sep 2017	B1
9785377	Shin et al.	Oct 2017	B2
9836480	Okun et al.	Dec 2017	B2
9846698	Panidis et al.	Dec 2017	B1
10073856	Cooper et al.	Sep 2018	B1
10095708	Passey et al.	Oct 2018	B2
10095709	Okun et al.	Oct 2018	B2
10095729	Taron et al.	Oct 2018	B2
10140185	Lopez et al.	Nov 2018	B1
10162980	Bernotavicius et al.	Dec 2018	B1
10261868	Brown et al.	Apr 2019	B2
10275493	Mostak	Apr 2019	B1
10303561	Beeken et al.	May 2019	B2
10318401	Rothschilds et al.	Jun 2019	B2
10318494	Krasnow et al.	Jun 2019	B2
10339101	Gupta	Jul 2019	B1
10346355	Godman	Jul 2019	B2
10387810	Kalush et al.	Aug 2019	B1
10409784	Krasnow et al.	Sep 2019	B1
10423609	Strauss	Sep 2019	B1
10437509	Alexeev et al.	Oct 2019	B1
10447779	Dieterich et al.	Oct 2019	B2
10459884	Godman	Oct 2019	B1
10459892	Godman et al.	Oct 2019	B2
10460122	Kirby et al.	Oct 2019	B1
10474635	Unger et al.	Nov 2019	B1
10534758	Carpenter et al.	Jan 2020	B1
10540662	Barlett et al.	Jan 2020	B2
10545986	Tappan et al.	Jan 2020	B2
10552373	Brow et al.	Feb 2020	B2
10606812	Cooper et al.	Mar 2020	B2
10614033	Rothschilds et al.	Apr 2020	B1
10614241	Kirby et al.	Apr 2020	B1
10621057	Tripathi	Apr 2020	B2
10621147	Liang et al.	Apr 2020	B1
10664408	Chatterjee et al.	May 2020	B1
10678663	Sharma et al.	Jun 2020	B1
10678671	Rothschilds et al.	Jun 2020	B2
10725977	Chmiel et al.	Jul 2020	B1
10795796	Bai et al.	Oct 2020	B1
10860372	Bai et al.	Dec 2020	B1
10860414	Urban et al.	Dec 2020	B1
10860546	Ye et al.	Dec 2020	B2
10860547	Passey et al.	Dec 2020	B2
10877942	Okun et al.	Dec 2020	B2
10936538	Unger et al.	Mar 2021	B1
10936551	Unger et al.	Mar 2021	B1
11023535	Greenwood et al.	Jun 2021	B1
11132126	Chmiel et al.	Sep 2021	B1
11132336	Passey et al.	Sep 2021	B2
11150823	Gao	Oct 2021	B2
11151001	Su et al.	Oct 2021	B2
11151092	Chmiel et al.	Oct 2021	B2
11157458	Carter et al.	Oct 2021	B1
11249907	Brewer	Feb 2022	B1
11256682	Taron et al.	Feb 2022	B2
11265262	Makie et al.	Mar 2022	B1
11294604	McMullan et al.	Apr 2022	B1
11294718	Bai et al.	Apr 2022	B2
11347699	Carpenter et al.	May 2022	B2
11354273	O'Neill et al.	Jun 2022	B1
11360936	Haber et al.	Jun 2022	B2
11372735	Su et al.	Jun 2022	B2
11372819	Carter et al.	Jun 2022	B1
11435901	Chmiel et al.	Sep 2022	B1
11461241	Carpenter et al.	Oct 2022	B2
11461286	Godman et al.	Oct 2022	B2
11567660	Chmiel et al.	Jan 2023	B2
11599508	Harward et al.	Mar 2023	B1
11630832	Choi et al.	Apr 2023	B2
11669255	Hansen et al.	Jun 2023	B2
11722150	Fachan et al.	Aug 2023	B1
11729269	Meernik et al.	Aug 2023	B1
11734147	Bai et al.	Aug 2023	B2
11775481	Unger et al.	Oct 2023	B2
20010039622	Hitz et al.	Nov 2001	A1
20020059439	Arroyo et al.	May 2002	A1
20020065835	Fujisaki	May 2002	A1
20020083073	Vaidya et al.	Jun 2002	A1
20020099691	Lore et al.	Jul 2002	A1
20020178271	Graham et al.	Nov 2002	A1
20030033308	Patel et al.	Feb 2003	A1
20030145009	Forman et al.	Jul 2003	A1
20030177379	Hori et al.	Sep 2003	A1
20030182313	Federwisch et al.	Sep 2003	A1
20040030727	Armangau et al.	Feb 2004	A1
20040093474	Lin et al.	May 2004	A1
20040098425	Wiss et al.	May 2004	A1
20040153479	Mikesell et al.	Aug 2004	A1
20040255048	Lev Ran et al.	Dec 2004	A1
20050015674	Haugh	Jan 2005	A1
20050027748	Kisley	Feb 2005	A1
20050065986	Bixby et al.	Mar 2005	A1
20050091663	Bagsby	Apr 2005	A1
20050114593	Cassell et al.	May 2005	A1
20050114726	Ouchi	May 2005	A1
20050119996	Ohata et al.	Jun 2005	A1
20050154866	Steely, Jr. et al.	Jul 2005	A1
20050182992	Land	Aug 2005	A1
20050187992	Prahlad et al.	Aug 2005	A1
20050195660	Kavuri et al.	Sep 2005	A1
20050223019	Das et al.	Oct 2005	A1
20060004890	Semple et al.	Jan 2006	A1
20060053139	Marzinski et al.	Mar 2006	A1
20060089982	Abbott et al.	Apr 2006	A1
20060090036	Zohar et al.	Apr 2006	A1
20060123005	Burnett et al.	Jun 2006	A1
20060173842	Horvitz et al.	Aug 2006	A1
20060271604	Shoens	Nov 2006	A1
20070005297	Beresniewicz et al.	Jan 2007	A1
20070011302	Groner et al.	Jan 2007	A1
20070027985	Ramany et al.	Feb 2007	A1
20070061783	Prakash	Mar 2007	A1
20070100855	T. Kohl	May 2007	A1
20070106706	Ahrens et al.	May 2007	A1
20070118561	Idicula et al.	May 2007	A1
20070143371	Kottomtharayil	Jun 2007	A1
20080028006	Liu et al.	Jan 2008	A1
20080059399	DeLorme et al.	Mar 2008	A1
20080059541	Fachan et al.	Mar 2008	A1
20080082593	Komarov et al.	Apr 2008	A1
20080162608	Torii et al.	Jul 2008	A1
20080172366	Hannel et al.	Jul 2008	A1
20080228772	Plamondon	Sep 2008	A1
20080250357	Lee et al.	Oct 2008	A1
20080256474	Chakra et al.	Oct 2008	A1
20080270469	Myerson et al.	Oct 2008	A1
20080270928	Chakra et al.	Oct 2008	A1
20080282244	Wu et al.	Nov 2008	A1
20080288306	Maclntyre et al.	Nov 2008	A1
20080301256	McWilliams et al.	Dec 2008	A1
20080313217	Dunsmore et al.	Dec 2008	A1
20090077087	Urano et al.	Mar 2009	A1
20090138500	Yuan et al.	May 2009	A1
20090199190	Chen et al.	Aug 2009	A1
20090222509	King et al.	Sep 2009	A1
20090240539	Slawson et al.	Sep 2009	A1
20090274047	Kruys et al.	Nov 2009	A1
20090319566	Wald et al.	Dec 2009	A1
20090327642	Ogihara et al.	Dec 2009	A1
20100030825	Matsuzawa et al.	Feb 2010	A1
20100036895	Boyd et al.	Feb 2010	A1
20100088317	Bone et al.	Apr 2010	A1
20100161557	Anderson et al.	Jun 2010	A1
20100179959	Shoens	Jul 2010	A1
20100217948	Mason et al.	Aug 2010	A1
20100241668	Susanto et al.	Sep 2010	A1
20100281214	Jernigan, IV	Nov 2010	A1
20100287512	Gan et al.	Nov 2010	A1
20110039622	Levenson	Feb 2011	A1
20110066668	Guarraci	Mar 2011	A1
20110082836	Wang et al.	Apr 2011	A1
20110125799	Kandasamy et al.	May 2011	A1
20110125973	Lev et al.	May 2011	A1
20110161381	Wang et al.	Jun 2011	A1
20110161964	Piazza et al.	Jun 2011	A1
20110196833	Drobychev et al.	Aug 2011	A1
20110196899	Hughes et al.	Aug 2011	A1
20110202925	Banerjee et al.	Aug 2011	A1
20110246724	Marathe et al.	Oct 2011	A1
20110302357	Sullivan	Dec 2011	A1
20120036463	Krakovsky et al.	Feb 2012	A1
20120066179	Saika	Mar 2012	A1
20120096059	Shimizu et al.	Apr 2012	A1
20120116478	Buhlmann et al.	May 2012	A1
20120136843	Bone et al.	May 2012	A1
20120151438	Bach et al.	Jun 2012	A1
20120166478	Das et al.	Jun 2012	A1
20120179886	Prahlad et al.	Jul 2012	A1
20120204060	Swift et al.	Aug 2012	A1
20120216005	Naito et al.	Aug 2012	A1
20120317079	Shoens et al.	Dec 2012	A1
20130019072	Strasser et al.	Jan 2013	A1
20130024609	Gorobets et al.	Jan 2013	A1
20130031232	Clymer et al.	Jan 2013	A1
20130073819	Havewala et al.	Mar 2013	A1
20130086121	Preslan	Apr 2013	A1
20130091168	Bhave et al.	Apr 2013	A1
20130110787	Garimella et al.	May 2013	A1
20130145471	Richard et al.	Jun 2013	A1
20130191355	Bone et al.	Jul 2013	A1
20130212579	Ben-Shaul et al.	Aug 2013	A1
20130227236	Flynn et al.	Aug 2013	A1
20130254163	Savage et al.	Sep 2013	A1
20130268650	Faitelson et al.	Oct 2013	A1
20130275391	Batwara et al.	Oct 2013	A1
20130304903	Mick et al.	Nov 2013	A1
20130311454	Ezzat	Nov 2013	A1
20130318194	Timbs	Nov 2013	A1
20130325806	Bachar et al.	Dec 2013	A1
20130325808	Bachar et al.	Dec 2013	A1
20130339406	Kanfi	Dec 2013	A1
20140006354	Parkinson et al.	Jan 2014	A1
20140040199	Golab et al.	Feb 2014	A1
20140040693	Kim et al.	Feb 2014	A1
20140059158	Chen et al.	Feb 2014	A1
20140089278	Lovinger et al.	Mar 2014	A1
20140089649	Chaganti	Mar 2014	A1
20140095249	Tarakad et al.	Apr 2014	A1
20140095505	Blanchflower et al.	Apr 2014	A1
20140095560	Ikai et al.	Apr 2014	A1
20140095582	Eshel et al.	Apr 2014	A1
20140101389	Nellans et al.	Apr 2014	A1
20140156956	Ezra	Jun 2014	A1
20140181441	Kottomtharayil et al.	Jun 2014	A1
20140189257	Aritome	Jul 2014	A1
20140189267	Qi et al.	Jul 2014	A1
20140195847	Webman et al.	Jul 2014	A1
20140237193	Shivashankaraiah	Aug 2014	A1
20140258609	Cui et al.	Sep 2014	A1
20140280485	A Hummaida et al.	Sep 2014	A1
20140281307	Peterson et al.	Sep 2014	A1
20140281411	Abdallah	Sep 2014	A1
20140344222	Morris et al.	Nov 2014	A1
20140358356	Jones et al.	Dec 2014	A1
20140372384	Long et al.	Dec 2014	A1
20140372607	Gladwin et al.	Dec 2014	A1
20140373032	Merry et al.	Dec 2014	A1
20150006226	Smith et al.	Jan 2015	A1
20150012656	Phillips et al.	Jan 2015	A1
20150012666	Pannese et al.	Jan 2015	A1
20150067086	Adriaens et al.	Mar 2015	A1
20150067142	Renkema	Mar 2015	A1
20150106145	Hamilton et al.	Apr 2015	A1
20150135331	Das	May 2015	A1
20150143026	Reddy et al.	May 2015	A1
20150149736	Kwon et al.	May 2015	A1
20150186217	Eslami Sarab	Jul 2015	A1
20150186410	Petculescu et al.	Jul 2015	A1
20150186483	Tappan et al.	Jul 2015	A1
20150186527	Rao et al.	Jul 2015	A1
20150186529	Rope et al.	Jul 2015	A1
20150193347	Kluesing et al.	Jul 2015	A1
20150215405	Baek et al.	Jul 2015	A1
20150234716	Brooker et al.	Aug 2015	A1
20150234879	Baldwin et al.	Aug 2015	A1
20150242263	Klose	Aug 2015	A1
20150248253	Kim et al.	Sep 2015	A1
20150278282	Sardina et al.	Oct 2015	A1
20150278329	Hrle et al.	Oct 2015	A1
20150310034	Godman et al.	Oct 2015	A1
20150310035	Godman et al.	Oct 2015	A1
20150310054	Passey et al.	Oct 2015	A1
20150347126	Tibble et al.	Dec 2015	A1
20160034356	Aron et al.	Feb 2016	A1
20160034481	Kumarasamy et al.	Feb 2016	A1
20160071233	Macko et al.	Mar 2016	A1
20160110105	Karamcheti et al.	Apr 2016	A1
20160139836	Nallathambi et al.	May 2016	A1
20160139952	Geng et al.	May 2016	A1
20160147654	Zhao et al.	May 2016	A1
20160224430	Long et al.	Aug 2016	A1
20160239185	Balimidi et al.	Aug 2016	A1
20160246816	Abiri et al.	Aug 2016	A1
20160269501	Usgaonkar et al.	Sep 2016	A1
20160292013	Li et al.	Oct 2016	A1
20160292429	Manville et al.	Oct 2016	A1
20160306810	Ni et al.	Oct 2016	A1
20160314046	Kumarasamy	Oct 2016	A1
20160335278	Tabaaloute et al.	Nov 2016	A1
20160357677	Hooker et al.	Dec 2016	A1
20160359859	Capone	Dec 2016	A1
20160371296	Passey et al.	Dec 2016	A1
20160371297	Okun et al.	Dec 2016	A1
20160380878	Bugenhagen et al.	Dec 2016	A1
20170024152	Bhagi et al.	Jan 2017	A1
20170032006	Anglin et al.	Feb 2017	A1
20170046143	Kochhar et al.	Feb 2017	A1
20170052898	Ash et al.	Feb 2017	A1
20170078164	Hildebrand et al.	Mar 2017	A1
20170091046	Bangalore et al.	Mar 2017	A1
20170118287	Beck	Apr 2017	A1
20170123883	Hall	May 2017	A1
20170123935	Pandit et al.	May 2017	A1
20170163728	Chawla et al.	Jun 2017	A1
20170201582	Zhang et al.	Jul 2017	A1
20170206231	Binder et al.	Jul 2017	A1
20170270180	State	Sep 2017	A1
20170286455	Li et al.	Oct 2017	A1
20170316321	Whitney et al.	Nov 2017	A1
20170336983	Roh et al.	Nov 2017	A1
20170344598	Constantinescu et al.	Nov 2017	A1
20170344905	Hack et al.	Nov 2017	A1
20170366609	Dieterich et al.	Dec 2017	A1
20180040029	Zeng et al.	Feb 2018	A1
20180059946	Kunii et al.	Mar 2018	A1
20180089031	Mitkar et al.	Mar 2018	A1
20180101546	Krasnow et al.	Apr 2018	A1
20180129443	Karve et al.	May 2018	A1
20180165300	Okun et al.	Jun 2018	A1
20180165321	Taron et al.	Jun 2018	A1
20180176082	Katz et al.	Jun 2018	A1
20180176120	Katz et al.	Jun 2018	A1
20180181583	Godman	Jun 2018	A1
20180203798	Hughes et al.	Jul 2018	A1
20180232386	Brow et al.	Aug 2018	A1
20180276078	Blea et al.	Sep 2018	A1
20180288057	Varadamma et al.	Oct 2018	A1
20180307579	Rothchilds et al.	Oct 2018	A1
20180314423	Gong et al.	Nov 2018	A1
20180357291	Choi et al.	Dec 2018	A1
20180365115	Fang et al.	Dec 2018	A1
20190087770	Walsh et al.	Mar 2019	A1
20190095112	Lingarajappa	Mar 2019	A1
20190102700	Babu et al.	Apr 2019	A1
20190163589	McBride et al.	May 2019	A1
20190163591	Ouyang et al.	May 2019	A1
20190196879	Dutta et al.	Jun 2019	A1
20190212921	Liang et al.	Jul 2019	A1
20190220189	Yang et al.	Jul 2019	A1
20190243818	Taron et al.	Aug 2019	A1
20190251065	Passey et al.	Aug 2019	A1
20190251066	Okun et al.	Aug 2019	A1
20190286521	Okpotse et al.	Sep 2019	A1
20190286528	Wu et al.	Sep 2019	A1
20190286543	Rothschilds et al.	Sep 2019	A1
20190294591	Krasnow et al.	Sep 2019	A1
20190332576	Godman	Oct 2019	A1
20190332579	Cooper et al.	Oct 2019	A1
20190377802	Haber et al.	Dec 2019	A1
20190384640	Swamy et al.	Dec 2019	A1
20200004977	Araujo et al.	Jan 2020	A1
20200026438	Peleg et al.	Jan 2020	A1
20200034077	Haravu et al.	Jan 2020	A1
20200050391	Meyerowitz et al.	Feb 2020	A1
20200142878	Varadarajan et al.	May 2020	A1
20200174692	Dave et al.	Jun 2020	A1
20200201824	Nishimoto et al.	Jun 2020	A1
20200210385	Carpenter et al.	Jul 2020	A1
20200242075	Davis et al.	Jul 2020	A1
20200242082	Chmiel et al.	Jul 2020	A1
20200286270	Lymperopoulos et al.	Sep 2020	A1
20200341689	Smith	Oct 2020	A1
20200387315	Sterns et al.	Dec 2020	A1
20200409583	Kusters et al.	Dec 2020	A1
20210004355	Iwase	Jan 2021	A1
20210042263	Zdornov et al.	Feb 2021	A1
20210042282	Cseri et al.	Feb 2021	A1
20210056074	Zhu	Feb 2021	A1
20210110150	Kakrana et al.	Apr 2021	A1
20210117868	Sriharsha	Apr 2021	A1
20210191650	Vansteenkiste et al.	Jun 2021	A1
20210232427	Bai et al.	Jul 2021	A1
20210232464	Su et al.	Jul 2021	A1
20210232481	Bai et al.	Jul 2021	A1
20210240393	Jo et al.	Aug 2021	A1
20210240678	Patel et al.	Aug 2021	A1
20210279187	Puder et al.	Sep 2021	A1
20210311841	McNutt	Oct 2021	A1
20210374105	Kodama et al.	Dec 2021	A1
20220019361	Kurata et al.	Jan 2022	A1
20220035716	Su et al.	Feb 2022	A1
20220035831	Beers	Feb 2022	A1
20220058055	Amemiya et al.	Feb 2022	A1
20220066882	Wang et al.	Mar 2022	A1
20220091739	Kumar et al.	Mar 2022	A1
20220100705	Unger et al.	Mar 2022	A1
20220107729	Hua	Apr 2022	A1
20220124152	Gallego et al.	Apr 2022	A1
20220138150	Chmiel et al.	May 2022	A1
20220283956	Carpenter et al.	Sep 2022	A1
20220300155	Chmiel et al.	Sep 2022	A1
20220300159	Chmiel et al.	Sep 2022	A1
20230004312	Hansen et al.	Jan 2023	A1
20230057068	Bhandarkar et al.	Feb 2023	A1
20230057600	Malley et al.	Feb 2023	A1
20230106208	Nossenson et al.	Apr 2023	A1
20230342053	Varghese et al.	Oct 2023	A1
20240020268	Haber et al.	Jan 2024	A1

Foreign Referenced Citations (14)

Number	Date	Country
1217551	Jun 2002	EP
1498829	Jan 2005	EP
3311312	Dec 2016	EP
3333732	Jun 2018	EP
3361397	Aug 2018	EP
3361397	Nov 2020	EP
3333732	Mar 2023	EP
1999044145	Sep 1999	WO
0072201	Nov 2000	WO
2009007250	Jan 2009	WO
2012029259	Mar 2012	WO
2016205752	Dec 2016	WO
2021151107	Jul 2021	WO
2021189055	Sep 2021	WO

Non-Patent Literature Citations (247)

Entry
Office Communication for U.S. Appl. No. 16/226,587 dated Aug. 5, 2019, pp. 1-46.
Office Communication for U.S. Appl. No. 16/228,716 dated Jun. 24, 2019, pp. 1-10.
Office Communication for U.S. Appl. No. 16/231,354 dated Jul. 10, 2019, pp. 1-8.
Office Communication for U.S. Appl. No. 16/262,756 dated Aug. 5, 2019, pp. 1-35.
Office Communication for U.S. Appl. No. 15/967,499 dated Jun. 27, 2018, pp. 1-16.
Office Communication for U.S. Appl. No. 16/226,587 dated Feb. 25, 2019, pp. 1-43.
Office Communication for U.S. Appl. No. 16/228,716 dated Feb. 28, 2019, pp. 1-15.
Office Communication for U.S. Appl. No. 16/231,354 dated Mar. 25, 2019, pp. 1-10.
Office Communication for U.S. Appl. No. 16/262,756 dated Apr. 2, 2019, pp. 1-29.
Office Communication for U.S. Appl. No. 16/262,790 dated Aug. 23, 2019, pp. 1-16.
Office Communication for U.S. Appl. No. 16/262,790 dated Apr. 18, 2019, pp. 1-14.
Office Communication for U.S. Appl. No. 16/262,756 dated Oct. 25, 2019, pp. 1-4.
Office Communication for U.S. Appl. No. 16/659,488 dated Dec. 30, 2019, pp. 1-6.
Office Communication for U.S. Appl. No. 14/595,598 dated Dec. 31, 2019, pp. 1-16.
Office Communication for U.S. Appl. No. 16/004,208 dated Aug. 27, 2018, pp. 1-11.
Office Communication for U.S. Appl. No. 16/234,395 dated Aug. 8, 2019, pp. 1-10.
Office Communication for U.S. Appl. No. 16/234,334 dated Apr. 5, 2019, pp. 1-15.
Office Communication for U.S. Appl. No. 16/234,395 dated Mar. 28, 2019, pp. 1-10.
Kappes, Giorgos et al., “Dike: Virtualization-aware Access Control for Multitenant Filesystems”, Feb. 18, 2013, pp. 1-6.
Hitz, Dave et al., “Merging NT and UNIX filesystem Permissions”, Proceedings of the 2nd USENIX Windows NT Symposium, Seattle, Washington, Aug. 3-4, 1998, pp. 1-10.
Office Communication for U.S. Appl. No. 16/234,334 dated Oct. 11, 2019, pp. 1-16.
Office Communication for U.S. Appl. No. 15/473,051 dated Jun. 30, 2017, pp. 1-23.
Extended European Search Report for European Patent Application No. 18155779.4 dated Apr. 17, 2018, pp. 1-15.
Office Communication for U.S. Appl. No. 16/004,182 dated Aug. 23, 2018, pp. 1-43.
Office Communication for U.S. Appl. No. 16/004,182 dated Mar. 5, 2019, pp. 1-46.
Office Communication for U.S. Appl. No. 16/004,182 dated Jul. 3, 2019, pp. 1-45.
Office Communication for U.S. Appl. No. 15/694,604 dated Jun. 3, 2019, pp. 1-8.
Office Communication for U.S. Appl. No. 16/004,182 dated May 22, 2019, pp. 1-4.
Office Communication for U.S. Appl. No. 14/595,043 dated May 4, 2017, pp. 1-30.
Office Communication for U.S. Appl. No. 14/595,043 dated Feb. 23, 2018, pp. 1-16.
Office Communication for U.S. Appl. No. 14/595,043 dated May 25, 2018, pp. 1-7.
Office Communication for U.S. Appl. No. 14/595,043 dated Oct. 5, 2018, pp. 1-17.
Office Communication for U.S. Appl. No. 14/595,043 dated Jun. 7, 2019, pp. 1-19.
Office Communication for U.S. Appl. No. 14/595,043 dated Aug. 27, 2019, pp. 1-17.
Office Communication for U.S. Appl. No. 14/658,015 dated Apr. 27, 2017, pp. 1-7.
Office Communication for U.S. Appl. No. 14/658,015 dated Jan. 4, 2018, pp. 1-28.
Office Communication for U.S. Appl. No. 14/658,015 dated Jul. 13, 2018, pp. 1-8.
Office Communication for U.S. Appl. No. 14/859,061 dated Sep. 22, 2017, pp. 1-16.
Office Communication for U.S. Appl. No. 15/831,236 dated Mar. 30, 2018, pp. 1-8.
Office Communication for U.S. Appl. No. 15/831,236 dated Aug. 15, 2018, pp. 1-14.
Office Communication for U.S. Appl. No. 14/859,114 dated Jul. 24, 2017, pp. 1-41.
Office Communication for U.S. Appl. No. 14/859,114 dated Feb. 21, 2018, pp. 1-25.
Office Communication for U.S. Appl. No. 14/859,114 dated May 11, 2018, pp. 1-5.
Office Communication for U.S. Appl. No. 14/859,114 dated Jun. 27, 2018, pp. 1-33.
Office Communication for U.S. Appl. No. 14/859,114 dated Nov. 19, 2018, pp. 1-35.
Office Communication for U.S. Appl. No. 14/859,114 dated Jan. 31, 2019, pp. 1-4.
Office Communication for U.S. Appl. No. 14/859,114 dated Mar. 7, 2019, pp. 1-32.
Office Communication for U.S. Appl. No. 14/859,114 dated Jun. 26, 2019, pp. 1-21.
Office Communication for U.S. Appl. No. 14/859,114 dated Sep. 13, 2019, pp. 1-6.
Office Communication for U.S. Appl. No. 14/859,114 dated Nov. 26, 2019, pp. 1-21.
Office Communication for U.S. Appl. No. 15/288,853 dated Sep. 19, 2018, pp. 1-13.
Chimera, Richard, “Value Bars: An Information Visualization and Navigation Tool for Multi-attribute Listings”, CHI '92, Monterey, CA, May 3-7, 1992, pp. 293-294.
Office Communication for U.S. Appl. No. 15/288,853 dated Mar. 25, 2019, pp. 1-10.
Cudre-Mauroux, Philippe et al., “TrajStore: An Adaptive Storage System for Very Large Trajectory Sets”, ICDE 2010, Long Beach, CA, Mar. 1-6, 2010, pp. 109-120.
Office Communication for U.S. Appl. No. 16/436,825 dated Jul. 11, 2019, pp. 1-9.
Office Communication for U.S. Appl. No. 15/474,047 dated Sep. 18, 2017, pp. 1-14.
Office Communication for U.S. Appl. No. 15/474,047 dated Mar. 9, 2018, pp. 1-8.
Office Communication for U.S. Appl. No. 15/474,047 dated Jun. 11, 2018, pp. 1-6.
Office Communication for U.S. Appl. No. 15/474,047 dated Aug. 15, 2018, pp. 1-11.
Office Communication for U.S. Appl. No. 15/957,809 dated Jun. 28, 2018, pp. 1-27.
Office Communication for U.S. Appl. No. 15/957,809 dated Jan. 24, 2019, pp. 1-11.
Office Communication for U.S. Appl. No. 16/434,157 dated Jul. 25, 2019, pp. 1-8.
Office Communication for U.S. Appl. No. 15/854,447 dated May 6, 2019, pp. 1-9.
Office Communication for U.S. Appl. No. 16/505,562 dated Aug. 30, 2019, pp. 1-11.
Extended European Search Report for European Patent Application No. 17206518.7 dated Apr. 5, 2018, pp. 1-8.
Karatza et al., “Epoch Load Sharing in a Network of Workstations,” Simulation Symposium, 2001. Proceedings. 34th Annual Apr. 22-26, 2001, Piscataway, nj, usa, IEEE, XP010541274, ISBN: 978-0-7695-1092-7, pp. 36-42.
Office Communication for U.S. Appl. No. 16/004,182 dated Jan. 7, 2020, pp. 1-46.
Office Communication for U.S. Appl. No. 16/125,573 dated Nov. 21, 2019, pp. 1-13.
Office Communication for U.S. Appl. No. 16/226,587 dated Oct. 24, 2019, pp. 1-4.
Office Communication for U.S. Appl. No. 16/262,790 dated Dec. 12, 2019, pp. 1-10.
Office Communication for U.S. Appl. No. 16/234,334 dated Jan. 16, 2020, pp. 1-8.
Office Communication for U.S. Appl. No. 15/694,604 dated Nov. 20, 2019, pp. 1-8.
Office Communication for U.S. Appl. No. 16/262,756 dated Jan. 28, 2020, pp. 1-21.
Office Communication for U.S. Appl. No. 16/434,157 dated Jan. 29, 2020, pp. 1-9.
Office Communication for U.S. Appl. No. 16/262,790 dated Feb. 6, 2020, pp. 1-8.
Office Communication for U.S. Appl. No. 14/859,114 dated Mar. 13, 2020, pp. 1-21.
Office Communication for U.S. Appl. No. 16/752,451 dated Mar. 12, 2020, pp. 1-14.
Office Communication for U.S. Appl. No. 16/775,041 dated Mar. 11, 2020, pp. 1-8.
Office Communication for U.S. Appl. No. 16/779,362 dated Mar. 26, 2020, pp. 1-10.
Wikipedia clustered file system page from date Jul. 9, 2019, retrieved using the WayBackMachine, From https://web.archive.org/web/20190709083400/https://en.wikipedia.org/wiki/Clustered_file_system (Year: 2019), pp. 1-6.
Wikipedia raft page from date Jul. 16, 2019, retrieved using the WayBackMachine, from https://web.archive.org/web/20190716115001/https://en.wikipedia.org/wiki/Raft (computer_science) (Year: 2019), pp. 1-4.
Office Communication for U.S. Appl. No. 16/004,182 dated Mar. 23, 2020, pp. 1-4.
Office Communication for U.S. Appl. No. 16/752,509 dated Apr. 2, 2020, pp. 1-8.
Office Communication for U.S. Appl. No. 16/152,277 dated Apr. 3, 2020, pp. 1-10.
Office Communication for U.S. Appl. No. 16/004,182 dated Apr. 28, 2020, pp. 1-51.
Office Communication for U.S. Appl. No. 16/152,259 dated Apr. 29, 2020, pp. 1-19.
Office Communication for U.S. Appl. No. 14/859,114 dated Jun. 5, 2020, pp. 1-5.
Office Communication for U.S. Appl. No. 16/262,756 dated Jun. 8, 2020, pp. 1-22.
Office Communication for U.S. Appl. No. 14/595,598 dated Jul. 9, 2020, pp. 1-19.
Office Communication for U.S. Appl. No. 16/752,451 dated Jul. 23, 2020, pp. 1-8.
Office Communication for U.S. Appl. No. 14/859,114 dated Jul. 23, 2020, pp. 1-21.
Office Communication for U.S. Appl. No. 16/152,615 dated Aug. 6, 2020, pp. 1-7.
Office Communication for U.S. Appl. No. 16/779,362 dated Aug. 7, 2020, pp. 1-11.
Office Communication for U.S. Appl. No. 16/883,922 dated Aug. 7, 2020, pp. 1-13.
Office Communication for U.S. Appl. No. 16/775,041 dated Aug. 18, 2020, pp. 1-9.
Office Communication for U.S. Appl. No. 16/883,879 dated Sep. 1, 2020, pp. 1-11.
Extended European Search Report for European Patent Application No. 16812585.4 dated Nov. 7, 2018, pp. 1-9.
Comer, Douglas, “The Ubiquitous B-Tree,” Computing Surveys, vol. 11, No. 2, Jun. 1979. Computer Science Department, Purdue University, West Lafayette, Indiana 47907, pp. 121-137.
Examination Report for European Patent Application No. 16812585.4 dated Jan. 2, 2020, pp. 1-6.
International Search Report and Written Opinion for International Patent Application No. PCT/US2016/038242 dated Oct. 11, 2016, pp. 1-11.
Office Communication for U.S. Appl. No. 14/595,598 dated Jul. 31, 2019, pp. 1-5.
Office Communication for U.S. Appl. No. 14/595,598 dated Sep. 20, 2018, pp. 1-18.
Office Communication for U.S. Appl. No. 14/595,598 dated Dec. 15, 2017, pp. 1-18.
Office Communication for U.S. Appl. No. 14/595,598 dated Feb. 24, 2017, pp. 1-8.
Office Communication for U.S. Appl. No. 14/595,598 dated Apr. 19, 2018, pp. 1-5.
Bloom, Burton H., “Space/Time Trade-offs in Hash Coding with Allowable Errors,” Communications of the ACM, vol. 13, No. 7, Jul. 1970. Computer Usage Company, Newton Upper Falls, Massachusetts, pp. 422-426.
Office Communication for U.S. Appl. No. 16/262,756 dated Aug. 24, 2020, pp. 1-7.
Examination Report for European Patent Application No. 18155779.4 dated Oct. 8, 2019, pp. 1-4.
Office Communication for U.S. Appl. No. 16/152,259 dated Aug. 28, 2020, pp. 1-5.
Office Communication for U.S. Appl. No. 16/752,509 dated Aug. 11, 2020, pp. 1-7.
Office Communication for U.S. Appl. No. 14/595,598 dated Sep. 25, 2020, pp. 1-7.
Office Communication for U.S. Appl. No. 16/152,277 dated Oct. 16, 2020, pp. 1-10.
Office Communication for U.S. Appl. No. 16/152,615 dated Oct. 20, 2020, pp. 1-7.
Office Communication for U.S. Appl. No. 16/775,041 dated Nov. 3, 2020, pp. 1-5.
Office Communication for U.S. Appl. No. 17/062,500 dated Nov. 12, 2020, pp. 1-12.
Office Communication for U.S. Appl. No. 16/004,182 dated Nov. 30, 2020, pp. 1-55.
Office Communication for U.S. Appl. No. 14/859,114 dated Dec. 1, 2020, pp. 1-24.
Office Communication for U.S. Appl. No. 16/883,922 dated Dec. 2, 2020, pp. 1-9.
Office Communication for U.S. Appl. No. 16/883,879 dated Dec. 8, 2020, pp. 1-5.
Office Communication for U.S. Appl. No. 16/152,277 dated Dec. 28, 2020, pp. 1-5.
Office Communication for U.S. Appl. No. 16/004,182 dated Jan. 28, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 14/595,598 dated Feb. 4, 2021, pp. 1-19.
Office Communication for U.S. Appl. No. 17/115,529 dated Feb. 8, 2021, pp. 1-15.
Office Communication for U.S. Appl. No. 16/262,756 dated Feb. 10, 2021, pp. 1-19.
Office Communication for U.S. Appl. No. 17/114,384 dated Feb. 17, 2021, pp. 1-12.
Examination Report for European Patent Application No. 17206518.7 dated Feb. 23, 2021, pp. 1-6.
Office Communication for U.S. Appl. No. 14/859,114 dated Mar. 8, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 16/004,182 dated Mar. 8, 2021, pp. 1-60.
Office Communication for U.S. Appl. No. 17/062,500 dated Mar. 9, 2021, pp. 1-17.
Office Communication for U.S. Appl. No. 16/152,277 dated Mar. 18, 2021, pp. 1-10.
Office Communication for U.S. Appl. No. 17/160,698 dated Mar. 18, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 17/062,500 dated May 18, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 17/203,371 dated May 20, 2021, pp. 1-10.
Office Communication for U.S. Appl. No. 17/115,529 dated May 25, 2021, pp. 1-18.
Office Communication for U.S. Appl. No. 14/859,114 dated May 26, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 16/262,756 dated May 27, 2021, pp. 1-7.
Office Communication for U.S. Appl. No. 17/114,384 dated May 27, 2021, pp. 1-13.
Office Communication for U.S. Appl. No. 17/190,653 dated May 27, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 16/741,567 dated Jun. 8, 2021, pp. 1-5.
Office Communication for U.S. Appl. No. 17/203,452 dated Jun. 23, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 16/152,277 dated Jun. 25, 2021, pp. 1-10.
Office Communication for U.S. Appl. No. 16/004,182 dated Jul. 1, 2021, pp. 1-58.
Office Communication for U.S. Appl. No. 17/160,698 dated Jul. 2, 2021, pp. 1-12.
International Search Report and Written Opinion for International Patent Application No. PCT/US2021/023531 dated Jul. 6, 2021, pp. 1-7.
Office Communication for U.S. Appl. No. 17/062,500 dated Jul. 12, 2021, pp. 1-18.
Office Communication for U.S. Appl. No. 16/775,041 dated Jul. 21, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 17/114,384 dated Aug. 3, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 14/595,598 dated Aug. 6, 2021, pp. 1-20.
Office Communication for U.S. Appl. No. 17/115,529 dated Aug. 12, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 17/190,653 dated Aug. 27, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 17/114,384 dated Sep. 2, 2021, pp. 1-5.
Office Communication for U.S. Appl. No. 16/152,277 dated Sep. 3, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 16/004,182 dated Sep. 10, 2021, pp. 1-4.
Office Communication for U.S. Appl. No. 16/004,182 dated Sep. 29, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 16/152,277 dated Oct. 18, 2021, pp. 1-5.
International Search Report and Written Opinion for International Patent Application No. PCT/US2021/023525 dated Oct. 12, 2021, pp. 1-7.
Office Communication for U.S. Appl. No. 17/115,529 dated Oct. 22, 2021, pp. 1-20.
Office Communication for U.S. Appl. No. 17/062,500 dated Oct. 27, 2021, pp. 1-17.
Office Communication for U.S. Appl. No. 14/595,598 dated Oct. 28, 2021, pp. 1-6.
Office Communication for U.S. Appl. No. 16/741,567 dated Oct. 28, 2021, pp. 1-11.
Office Communication for U.S. Appl. No. 17/203,452 dated Nov. 2, 2021, pp. 1-13.
Office Communication for U.S. Appl. No. 17/190,653 dated Nov. 10, 2021, pp. 1-6.
Office Communication for U.S. Appl. No. 17/484,167 dated Nov. 18, 2021, pp. 1-15.
Office Communication for U.S. Appl. No. 17/504,289 dated Dec. 7, 2021, pp. 1-15.
Office Communication for U.S. Appl. No. 17/114,384 dated Dec. 14, 2021, pp. 1-7.
Office Communication for U.S. Appl. No. 17/190,653 dated Dec. 21, 2021, pp. 1-12.
Office Communication for U.S. Appl. No. 17/508,869 dated Dec. 22, 2021, pp. 1-9.
Office Communication for U.S. Appl. No. 17/491,017 dated Dec. 23, 2021, pp. 1-41.
Office Communication for U.S. Appl. No. 14/595,598 dated Dec. 29, 2021, pp. 1-19.
Office Communication for U.S. Appl. No. 17/062,500 dated Jan. 7, 2022, pp. 1-4.
Office Communication for U.S. Appl. No. 16/741,567 dated Jan. 11, 2022, pp. 1-6.
Office Communication for U.S. Appl. No. 17/203,452 dated Jan. 14, 2022, pp. 1-4.
Office Communication for U.S. Appl. No. 17/510,043 dated Jan. 21, 2022, pp. 1-13.
Office Communication for U.S. Appl. No. 16/741,567 dated Feb. 7, 2022, pp. 1-8.
Office Communication for U.S. Appl. No. 17/530,420 dated Feb. 10, 2022, pp. 1-24.
Office Communication for U.S. Appl. No. 16/004,182 dated Feb. 18, 2022, pp. 1-11.
Office Communication for U.S. Appl. No. 17/115,529 dated Feb. 18, 2022, pp. 1-20.
Office Communication for U.S. Appl. No. 17/203,452 dated Feb. 24, 2022, pp. 1-14.
Office Communication for U.S. Appl. No. 17/484,167 dated Mar. 11, 2022, pp. 1-11.
Office Communication for U.S. Appl. No. 17/062,500 dated Mar. 22, 2022, pp. 1-19.
Office Communication for U.S. Appl. No. 17/504,289 dated Mar. 28, 2022, pp. 1-9.
Office Communication for U.S. Appl. No. 17/588,120 dated Apr. 11, 2022, pp. 1-36.
Office Communication for U.S. Appl. No. 17/588,895 dated Apr. 27, 2022, pp. 1-6.
Office Communication for U.S. Appl. No. 17/190,653 dated Apr. 28, 2022, pp. 1-13.
Office Communication for U.S. Appl. No. 17/510,043 dated Apr. 29, 2022, pp. 1-10.
Office Communication for U.S. Appl. No. 17/115,529 dated Apr. 29, 2022, pp. 1-4.
Office Communication for U.S. Appl. No. 17/491,017 dated May 12, 2022, pp. 1-50.
Office Communication for U.S. Appl. No. 17/484,167 dated May 17, 2022, pp. 1-3.
Office Communication for U.S. Appl. No. 17/484,167 dated Jun. 10, 2022, pp. 1-5.
Office Communication for U.S. Appl. No. 17/203,452 dated Jun. 22, 2022, pp. 1-22.
Office Communication for U.S. Appl. No. 14/595,598 dated Jul. 13, 2022, pp. 1-9.
Office Communication for U.S. Appl. No. 17/062,500 dated Jul. 26, 2022, pp. 1-20.
Office Communication for U.S. Appl. No. 17/588,120 dated Jul. 27, 2022, pp. 1-34.
Office Communication for U.S. Appl. No. 17/190,653 dated Aug. 2, 2022, pp. 1-8.
Office Communication for U.S. Appl. No. 17/115,529 dated Aug. 8, 2022, pp. 1-21.
Office Communication for U.S. Appl. No. 17/588,895 dated Aug. 12, 2022, pp. 1-12.
Office Communication for U.S. Appl. No. 17/491,017 dated Aug. 17, 2022, pp. 1-5.
Office Communication for U.S. Appl. No. 17/203,452 dated Sep. 8, 2022, pp. 1-4.
Office Communication for U.S. Appl. No. 17/491,017 dated Sep. 15, 2022, pp. 1-55.
Office Communication for U.S. Appl. No. 17/864,190 dated Sep. 19, 2022, pp. 1-10.
Office Communication for U.S. Appl. No. 17/062,500 dated Oct. 5, 2022, pp. 1-4.
Office Communication for U.S. Appl. No. 17/203,452 dated Oct. 19, 2022, pp. 1-9.
Office Communication for U.S. Appl. No. 17/588,120 dated Oct. 21, 2022, pp. 1-5.
Office Communication for U.S. Appl. No. 17/203,452 dated Nov. 9, 2022, pp. 1-2.
Office Communication for U.S. Appl. No. 17/588,895 dated Nov. 9, 2022, pp. 1-11.
Office Communication for U.S. Appl. No. 17/954,640 dated Nov. 30, 2022, pp. 1-10.
Office Communication for U.S. Appl. No. 17/115,529 dated Dec. 9, 2022, pp. 1-21.
Office Communication for U.S. Appl. No. 17/864,190 dated Jan. 24, 2023, pp. 1-12.
Office Communication for U.S. Appl. No. 17/588,120 dated Feb. 1, 2023, pp. 1-15.
Office Communication for U.S. Appl. No. 17/491,017 dated Feb. 10, 2023, pp. 1-57.
Office Communication for U.S. Appl. No. 17/062,500 dated Feb. 27, 2023, pp. 1-23.
Office Communication for U.S. Appl. No. 17/954,640 dated Mar. 15, 2023, pp. 1-9.
Office Communication for U.S. Appl. No. 17/864,190 dated Apr. 28, 2023, pp. 1-5.
Office Communication for U.S. Appl. No. 17/491,017 dated May 4, 2023, pp. 1-6.
Office Communication for U.S. Appl. No. 17/973,944 dated May 10, 2023, pp. 1-9.
Office Communication for U.S. Appl. No. 17/115,529 dated May 22, 2023, pp. 1-25.
Office Communication for U.S. Appl. No. 17/115,529 dated Dec. 13, 2023, 4 Pages.
Office Communication for U.S. Appl. No. 17/115,529 dated Jan. 12, 2024, 26 Pages.
Office Communication for U.S. Appl. No. 18/503,791 dated Jan. 4, 2024, 27 Pages.
Office Communication for U.S. Appl. No. 16/152,277 dated Oct. 26, 2021, 2 Pages.
Office Communication for U.S. Appl. No. 17/062,500 dated Jun. 13, 2023, 8 Pages.
Office Communication for U.S. Appl. No. 16/004,182 dated Mar. 17, 2022, 3 Pages.
Office Communication for U.S. Appl. No. 17/491,017 dated Aug. 8, 2023, 13 Pages.
Office Communication for U.S. Appl. No. 14/595,598 dated May 16, 2019, 18 Pages.
Office Communication for U.S. Appl. No. 16/226,587 dated Jan. 27, 2020, 13 Pages.
Office Communication for U.S. Appl. No. 16/741,567 dated Feb. 24, 2022, 2 Pages.
Office Communication for U.S. Appl. No. 16/262,790 dated Nov. 8, 2019, 5 Pages.
Office Communication for U.S. Appl. No. 17/504,289 dated Apr. 20, 2022, 2 Pages.
Office Communication for U.S. Appl. No. 16/659,488 dated May 6, 2020, 8 Pages.
International Preliminary Report on Patentability Chapter I for International Patent Application No. PCT/ US2021/023531 dated Aug. 4, 2022, 5 Pages.
International Preliminary Report on Patentability Chapter I for International Patent Application No. PCT/ US2021/023525 dated Aug. 4, 2022, 5 Pages.
International Preliminary Report on Patentability Chapter I for International Patent Application No. PCT/ US2016/038242 dated Dec. 28, 2017, 8 Pages.
Office Action for European Patent Application No. 17206518.7 dated Mar. 15, 2022, 5 Pages.
Intention to Grant for European Patent Application No. 17206518.7 dated Sep. 30, 2022, 6 Pages.
Office Communication for U.S. Appl. No. 17/508,869 dated Mar. 8, 2022, 2 Pages.
Office Communication for U.S. Appl. No. 17/508,869 dated Jan. 5, 2022, 3 Pages.
Office Communication for U.S. Appl. No. 17/530,420 dated May 4, 2022, 3 Pages.
Office Communication for U.S. Appl. No. 17/530,420 dated May 12, 2022, 3 Pages.
Office Communication for European Patent Application No. 16812585.4 dated Apr. 1, 2021, 9 pages.
Intention to Grant for European Patent Application No. 18155779.4 dated Jun. 12, 2020, 10 Pages.
Office Communication for U.S. Appl. No. 17/115,529 dated Sep. 12, 2023, 25 Pages.
Office Communication for U.S. Appl. No. 17/864,190 dated Aug. 25, 2023, 12 Pages.
Office Communication for U.S. Appl. No. 17/864,190 dated Nov. 17, 2023, 12 Pages.
Office Communication for European Patent Application No. 18155779.4 dated Apr. 17, 2018, 4 Pages.
Office Communication for U.S. Appl. No. 17/864,190 dated Feb. 8, 2024, 5 Pages.
Office Communication for U.S. Appl. No. 18/503,918 dated Jan. 24, 2024, 12 Pages.
Office Communication for U.S. Appl. No. 18/503,918 dated Jan. 31, 2024, 8 Pages.

In-place erasure code transcoding for distributed file systems

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

CPC

International Classifications

Abstract

Description

Claims

US Referenced Citations (458)

Foreign Referenced Citations (14)

Non-Patent Literature Citations (247)