WO2025170203A1 - Server and method for managing memory pool, and non-transitory computer-readable recoding medium - Google Patents

Abstract

A server is disclosed. The server may include a memory in which a plurality of memory pools for processing a plurality of system tasks, respectively, are configured, wherein each of the plurality of memory pools is divided into memory blocks having a specified size. The server may obtain a user request for processing data having a size of N data blocks from an electronic device through a communication circuit. The server may identify a first memory pool for processing the user request among the plurality of memory pools. The server may allocate first memory blocks of the first memory pool to process the user request, on the basis that all first system tasks waiting in a first system task queue for the first memory pool are processed. The server may process the data on the basis of the allocation of the first memory blocks to process the user request.

Description

Server, method, and non-transitory computer-readable recording medium for managing a memory pool

The following descriptions relate to a server, a method, and a non-transitory computer-readable recording medium for managing a memory pool.

A server can provide storage services. For storage services, the server can manage storage in various storage methods. For example, storage methods include block, file, or object methods.

Additionally, the server may store the original and copies of the data in different storages to protect and recover the user's data, and may limit traffic or service requests to provide stable service.

The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art related to the present disclosure.

A server is disclosed. The server may include a communication circuit. The server may include at least one processor including a processing circuit. The server may include a memory configured with a plurality of memory pools for processing a plurality of system tasks, storing instructions, and including one or more storage media. Each of the plurality of memory pools may be divided into memory blocks of a specified size. The instructions, when individually or collectively executed by the at least one processor, may cause the server to obtain a user request for processing data of a size of n data blocks from an electronic device via the communication circuit. The instructions, when individually or collectively executed by the at least one processor, may cause the server to identify a first memory pool among the plurality of memory pools for processing the user request. The instructions, when individually or collectively executed by the at least one processor, may cause the server to allocate first memory blocks of the first memory pool to process the user request based on all first system tasks waiting in a first system task queue for the first memory pool being processed. The size of each of the first memory blocks may correspond to the size of each of the n data blocks and k parity blocks. Each of the data blocks may have the same size as each of the parity blocks. The instructions, when individually or collectively executed by the at least one processor, may cause the server to process the data based on the allocation of the first memory blocks to process the user request.

A method is disclosed. The method can be performed in an electronic device including a memory, wherein a plurality of memory pools are set for processing a plurality of system tasks, respectively, and each of the plurality of memory pools is divided into memory blocks of a specified size. The method can include an operation of obtaining a user request for processing data of a size of n data blocks from the electronic device through a communication circuit. The method can include an operation of identifying a first memory pool for processing the user request among the plurality of memory pools. The method can include an operation of allocating first memory blocks of the first memory pool to process the user request based on processing all first system tasks waiting in a first system task queue for the first memory pool. The size of each of the first memory blocks can correspond to the size of each of the n data blocks and k parity blocks. Each of the data blocks can have the same size as each of the parity blocks. The method can include an operation of processing the data based on the allocation of the first memory blocks to process the user request.

A non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium can store a program including instructions. The instructions, when individually or collectively executed by at least one processor of an electronic device including a memory, wherein a plurality of memory pools are set for processing a plurality of system tasks, respectively, and each of the plurality of memory pools is divided into memory blocks of a specified size, can cause the electronic device to obtain a user request for processing data of a size of n data blocks from the electronic device through a communication circuit. The instructions, when individually or collectively executed by the at least one processor, can cause the electronic device to identify a first memory pool among the plurality of memory pools for processing the user request. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to allocate first memory blocks of the first memory pool to process the user request based on all first system tasks waiting in a first system task queue for the first memory pool being processed. A size of each of the first memory blocks may correspond to a size of each of the n data blocks and k parity blocks. Each of the data blocks may have the same size as each of the parity blocks. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to process the data based on the allocation of the first memory blocks to process the user request.

A server is disclosed. The server may include communication circuitry, at least one processor including processing circuitry, and at least one memory, which may be external to the at least one processor and the communication circuitry and which temporarily stores instructions while being used by the at least one processor. The instructions, when individually or collectively executed by the at least one processor, may cause the server to receive user data from an electronic device via the communication circuitry. The instructions, when individually or collectively executed by the at least one processor, may cause the server to allocate a plurality of memory blocks of the at least one memory for encoding the user data. The plurality of memory blocks may have a predefined and identical fixed size prior to receiving the user data. The instructions, when individually or collectively executed by the at least one processor, may cause the server to: divide the user data into data blocks, each of the data blocks having the fixed size, as the server encodes the user data. The instructions, when individually or collectively executed by the at least one processor, may cause the server to generate parity blocks for repairing at least one erroneous block among the data blocks. Each of the parity blocks may have the fixed size. The instructions, when individually or collectively executed by the at least one processor, may cause the server to store the data blocks and the parity blocks in the plurality of memory blocks allocated for encoding the user data. The instructions, when individually or collectively executed by the at least one processor, may cause the server to transmit the data blocks and the parity blocks to storage devices via the communication circuitry, such that they are distributed among the storage devices.

A server is disclosed. The server may include communication circuitry, at least one processor including processing circuitry, and at least one memory, which is external to the at least one processor and the communication circuitry and temporarily stores instructions while being used by the at least one processor. The instructions, when individually or collectively executed by the at least one processor, may cause the server to receive a request related to user data from an electronic device via the communication circuitry. The instructions, when individually or collectively executed by the at least one processor, may cause the server to identify the user data encoded into data blocks and parity blocks. The data blocks may be divided by the server from the user data. The parity blocks may be generated by the server to repair at least one error block of the data block. The data blocks and the parity blocks may have the same fixed size. The instructions, when individually or collectively executed by the at least one processor, may cause the server to allocate a plurality of memory blocks of the at least one memory for decoding the data blocks and the parity blocks. The plurality of memory blocks may have the fixed size predefined before receiving the request. The instructions, when individually or collectively executed by the at least one processor, may cause the server to generate the user data by decoding the data blocks and the parity blocks. The instructions, when individually or collectively executed by the at least one processor, may cause the server to store the generated user data in the plurality of memory blocks. The instructions, when individually or collectively executed by the at least one processor, may cause the server to transmit the generated user data stored in the plurality of memory blocks to the electronic device via the communication circuit.

In connection with the description of the drawings, the same or similar reference numerals may be used for the same or similar components.

FIG. 1 is a block diagram of a server according to one embodiment.

FIG. 2a illustrates an example of queues for a memory pool, according to one embodiment.

FIG. 2b is a block diagram of queues for a memory pool, according to one embodiment.

FIG. 3A illustrates an example of an operation of a server encoding data, according to one embodiment.

FIG. 3b illustrates an example of an operation of a server decoding data, according to one embodiment.

Figure 4 is a flowchart illustrating the operation of a server according to one embodiment.

FIG. 5A is a flowchart illustrating the operation of a server according to one embodiment.

FIG. 5b is a flowchart illustrating the operation of a server according to one embodiment.

FIG. 6A is a flowchart illustrating the operation of a server according to one embodiment.

Figure 6b is a flowchart illustrating the operation of a server according to one embodiment.

FIG. 7a is a flowchart illustrating the operation of a server according to one embodiment.

Figure 7b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 8a is a flowchart illustrating the operation of a server according to one embodiment.

Figure 8b is a flowchart illustrating the operation of a server according to one embodiment.

FIG. 9A is a flowchart illustrating the operation of a server according to one embodiment.

FIG. 9b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 10 is a block diagram of a server according to one embodiment.

FIG. 11 is a block diagram of an electronic device within a network environment according to various embodiments.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. In connection with the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and conciseness.

FIG. 1 is a block diagram of a server according to an embodiment. FIG. 2a illustrates an example of queues for a memory pool according to an embodiment. FIG. 2b is a block diagram of queues for a memory pool according to an embodiment.

Referring to FIG. 1, the server (101) may include a memory (110), a processor (120), and a communication circuit (130).

In one embodiment, the memory (110) may (at least temporarily) store instructions for executing operations of the server (101) exemplified in the descriptions of FIGS. 4 to 9B. The instructions may be executed by the processor (120). The instructions may be included in one or more programs stored in the memory (110). For example, the memory (110) may include at least a portion of the memory (1130) of FIG. 11 (or at least a portion of the non-volatile memory (1134)) or may correspond to at least a portion of the memory (1130) of FIG. 11 (or at least a portion of the non-volatile memory (1134)). For example, the memory (110) may include a main memory (e.g., random access memory (RAM)) within the server (101), a register for the processor (120), a cache for the processor (120), a register for the communication circuit (130), a buffer (or soft buffer) for the communication circuit (130), and/or an auxiliary memory (e.g., a hard disk drive (HDD), a solid state drive (SSD)) of the server (101). For example, the memory (110) may be implemented as a single chip or may be implemented as multiple chips. For example, the memory (110) may be implemented as a single integrated circuit or may be implemented as multiple integrated circuits. For example, the memory (110) may be distributedly arranged within the server (101).

In one embodiment, the processor (120) may be used to execute the operations of the server (101) exemplified in the descriptions of FIGS. 4 to 9B. For example, the processor (120) may include at least a portion of the processor (1120) of FIG. 11 or may correspond to at least a portion of the processor (1120) of FIG. 11. For example, the processor (120) may include one or more processors, including an application processor (AP) and/or a communication processor (CP). For example, the processor (120) may correspond to multiple processors that collectively perform multiple operations by dividing them among the processors. For example, the processor (120) may be implemented as a single chip, such as a system on chip (SoC), or may be implemented as multiple chips. For example, the processor (120) may be implemented as a single integrated circuit or may be implemented as multiple integrated circuits. For example, the processor (120) may be distributedly arranged within the server (101).

In one embodiment, the communication circuit (130) may be used to support wireless communication between the server (101) and another electronic device (e.g., the electronic device (103)). For example, the communication circuit (130) may include at least a portion of the communication module (1190) (or the wireless communication module (1192)) of FIG. 11, or may correspond to at least a portion of the communication module (1190) (or the wireless communication module (1192)) of FIG. 11. For example, the communication circuit (130) may include a communication circuit for a long-distance communication network. For example, the communication circuit (130) may be used to establish a communication link. For example, the communication circuit (130) may be implemented as a single chip or as multiple chips. For example, the communication circuit (130) may be implemented as a single integrated circuit or as multiple integrated circuits. For example, the communication circuit (130) may be distributed within the server (101).

Referring to FIG. 1, the memory (110) may include a data scan module (141), a data heal module (143), a disk recovery module (145), a request processing module (147), a coding module (150), a memory pool management module (160), a memory pool (170), storage (180), and a metadata database (DB) (190).

In one embodiment, the data scan module (141), the data heal module (143), the disk recovery module (145), the request processing module (147), the coding module (150), and the memory pool management module (160) may include instructions for executing operations of the server (101) exemplified in the descriptions of FIGS. 4 to 9B. In one embodiment, the data scan module (141), the data heal module (143), the disk recovery module (145), the request processing module (147), the coding module (150), and the memory pool management module (160) may be executed by the processor (120).

In one embodiment, the coding module (150) may include an encoder (151) and a decoder (155). In one embodiment, the encoder (151) and the decoder (155) may process data based on the same coding technique (e.g., erasure coding technique). For example, the sizes of the data may be different. For example, the sizes of data encoded at one time may be different. However, this is not a limitation.

In one embodiment, the encoder (151) may encode data based on a designated code (e.g., RS (Reed-Solomon) code). For example, the encoder (151) may encode N data pieces (or data chunks) of the same size into N+K data pieces (or data chunks). In one embodiment, the K data pieces may be referred to as parity pieces. In one embodiment, the sizes of the data pieces may be the same. For example, the sizes of the data pieces may be 1 megabyte or more (e.g., between 1 and 5 megabytes). For example, N and K are natural numbers, and K may be less than or equal to N. For example, N may be 6, and K may be 3. However, the present invention is not limited thereto.

In one embodiment, the decoder (155) can decode data based on a specified code (e.g., an RS code). For example, the decoder (155) can decode N+K data fragments of the same size into N data fragments.

The code for erasure coding is not limited to RS code. Depending on the embodiment, the code for erasure coding may include a Hamming code, a Bose-Chaudhuri-Hocquenghem (BCH) code, or a low-density parity check (LDPC) code. Depending on the embodiment, the code for erasure coding may be a code having the properties of a (linear) block code. However, the present invention is not limited thereto.

In one embodiment, the memory pool management module (160) can manage the memory pool (170). For example, the memory pool management module (160) can set the capacity of the memory pool (170) among the total capacity of the memory (110). For example, referring to FIGS. 2A and 2B, the memory pool management module (160) can set one or more pools (210, 230, 250) in the memory pool (170). For example, the memory pool (170) can correspond to the main memory (e.g., random access memory (RAM)) in the server (101). For example, the memory pool (170) can be located outside the processor (120) and the communication circuit (130) in the server (101). For example, the memory pool (170) can temporarily store instructions while being used. For example, the capacities excluding the capacity of the memory pool (170) from the total capacity of the main memory (e.g., RAM (random access memory)) within the server (101) may have blocks of variable sizes. For example, the capacities excluding the capacity of the memory pool (170) from the total capacity of the main memory (e.g., RAM (random access memory)) within the server (101) may be allocated for tasks other than user-requested tasks and system tasks (e.g., heal tasks, scan tasks, recovery tasks) (e.g., processes of other applications). The capacity of the memory allocated for other tasks may be variably set for each process.

For example, the memory pool management module (160) may set a scan memory pool (210) to which a memory area for processing a task of the data scan module (141) is allocated in the memory pool (170). For example, the memory pool management module (160) may set a scan memory pool (210) to which a memory area of a fixed size is allocated in the memory pool (170).

For example, the memory pool management module (160) can set a recovery memory pool (230) to which a memory area for processing a task of the disk recovery module (145) is allocated in the memory pool (170). For example, the memory pool management module (160) can set a recovery module (145) to which a memory area of a fixed size is allocated in the memory pool (170).

For example, the memory pool management module (160) can set a root memory pool (250) to which a memory area for processing the top-level system task (e.g., a task input to the root queue (251)) in the memory pool (170) is allocated. For example, the root memory pool (250) can be a memory pool to which a memory area for processing the task of the data hill module (143) is allocated in the memory pool (170). For example, the memory pool management module (160) can set a root memory pool (250) to which a memory area of a variable size is allocated in the memory pool (170). For example, when the number of hill tasks is large (or when it is greater than a reference number), the memory pool management module (160) can increase the size of the memory pool (170) (or the root memory pool (250)). For example, if the number of hill tasks is small (or less than a standard number), the memory pool management module (160) may reduce the size of the memory pool (170) (or the root memory pool (250)). However, this is not limited thereto.

In one embodiment, the memory blocks of the scan memory pool (210), the recovery memory pool (230), and the root memory pool (250) may have the same size. For example, each of the memory blocks of the scan memory pool (210), the recovery memory pool (230), and the root memory pool (250) may have the same size as a data chunk (or a data fragment) (or a parity fragment). For example, each of the memory blocks of the scan memory pool (210), the recovery memory pool (230), and the root memory pool (250) may have the same predefined fixed size. For example, each of the memory blocks of the scan memory pool (210), the recovery memory pool (230), and the root memory pool (250) may be set when the server (101) boots. However, the present invention is not limited thereto.

In one embodiment, a scan queue (211) may be connected to a scan memory pool (210). In one embodiment, the connection of a scan queue (211) to a scan memory pool (210) may refer to that at least one queue of the scan queue (211) is processed using a memory area of the scan memory pool (210). In one embodiment, a task of a data scan module (141) may be input (or enqueued) (or pushed) to the scan queue (211). In one embodiment, tasks stored in the scan queue (211) may be output (or dequeued) (or popped) (or pulled) based on an input order (or a first in first out (FIFO) method).

In one embodiment, a memory area of the scan memory pool (210) may be allocated for processing a task output from the scan queue (211). Based on the completion of processing of the task, the memory area of the scan memory pool (210) allocated for the task may be deallocated.

In one embodiment, the scan memory pool (210) may not have any queues other than the scan queue (211) connected to it. In one embodiment, the scan memory pool (210) may not include any subqueues of the scan queue (211).

In one embodiment, a recovery queue (231) may be connected to the recovery memory pool (230). In one embodiment, the connection of the recovery queue (231) to the recovery memory pool (230) may indicate that at least one queue of the recovery queue (231) is processed using the memory area of the recovery memory pool (230). In one embodiment, the recovery queue (231) may be input (or enqueued) (or pushed) by a task of the disk recovery module (145). In one embodiment, the tasks stored in the recovery queue (231) may be output (or dequeued) (or popped) (or pulled) based on the input order (or first-in, first-out).

In one embodiment, a memory area of the recovery memory pool (230) may be allocated for processing a task output from the recovery queue (231). Based on the completion of processing of the task, the memory area of the recovery memory pool (230) allocated for the task may be deallocated.

In one embodiment, a queue other than the recovery queue (231) may be connected to the recovery memory pool (230). In one embodiment, the recovery memory pool (230) may include a subqueue of the recovery queue (231). For example, the recovery memory pool (230) may be connected to a request queue (240) as a subqueue of the recovery queue (231). In one embodiment, the connection of the request queue (240) as a subqueue to the recovery memory pool (230) may indicate that at least one queue of the request queue (240) is processed using the memory area of the recovery memory pool (230). In one embodiment, the request queue (240) may be a place where a task of the request processing module (147) may be input (or enqueued) (or pushed). In one embodiment, tasks stored in the request queue (240) may be output (or dequeued) (or popped) (or pulled) based on the input order (or first-in, first-out). In one embodiment, tasks stored in the request queue (240) may be output (or dequeued) (or popped) (or pulled) when there are no tasks in the upper queue, the recovery queue (231). In one embodiment, a memory area of the recovery memory pool (230) may be allocated for processing tasks output from the request queue (240). Based on the completion of processing of a task, the memory area of the request queue (240) allocated for the task may be deallocated.

In one embodiment, the request queue (240) may include a plurality of request queues (241, 243, 245). In one embodiment, tasks input to each of the plurality of request queues (241, 243, 245) may be output (or dequeued) (or popped) (or pulled) in a round-robin manner. For example, tasks may be output (or dequeued) (or popped) (or pulled) in the order of the request queue (241), the request queue (243), and the request queue (245).

In one embodiment, a root queue (251) may be connected to the root memory pool (250) as a top-level queue. In one embodiment, a hill queue (261) may be connected to the root memory pool (250) as a second-level queue. In one embodiment, the connection of the root queue (251) and the hill queue (261) to the root memory pool (250) may indicate that at least one queue of the root queue (251) or the hill queue (261) is processed using a memory area of the root memory pool (250).

In one embodiment, the hill queue (261) can be input (or enqueued) (or pushed) by tasks of the data hill module (143). In one embodiment, the tasks stored in the hill queue (261) can be output (or dequeued) (or popped) (or pulled) based on the input order (or first-in, first-out).

In one embodiment, a memory area of the root memory pool (250) may be allocated for processing a task output from the heal queue (261). Upon completion of processing of the task, the memory area of the root memory pool (250) allocated for the task may be deallocated.

In one embodiment, the root memory pool (250) may be connected to a queue other than the root queue (251) and the hill queue (261). In one embodiment, the root memory pool (250) may include a subqueue of the hill queue (261). For example, the root memory pool (250) may be connected to a request queue (270) as a subqueue of the hill queue (261). In one embodiment, the connection of the request queue (270) as a subqueue to the root memory pool (250) may indicate that at least one queue of the request queue (270) is processed using the memory area of the root memory pool (250). In one embodiment, the request queue (270) may be a place where a task of the request processing module (147) may be input (or enqueued) (or pushed). In one embodiment, tasks stored in the request queue (270) may be output (or dequeued) (or popped) (or pulled) based on the input order (or first-in, first-out). In one embodiment, tasks stored in the request queue (270) may be output (or dequeued) (or popped) (or pulled) when there are no tasks in the upper queue, the root memory pool (250). In one embodiment, a memory area of the root memory pool (250) may be allocated for processing tasks output from the request queue (270). Based on the completion of processing of a task, the memory area of the request queue (270) allocated for the task may be deallocated.

In one embodiment, the request queue (270) may include a plurality of request queues (271, 273, 275). In one embodiment, tasks input to each of the plurality of request queues (271, 273, 275) may be output (or dequeued) (or popped) (or pulled) in a round-robin manner. For example, tasks may be output (or dequeued) (or popped) (or pulled) in the order of the request queue (271), the request queue (273), and the request queue (275).

In one embodiment, the memory pool (170) may be memory allocated from the main memory (e.g., RAM, registers for the processor (120), cache for the processor (120)) (or volatile memory) of the server (101). In one embodiment, the storage (180) may be auxiliary memory (e.g., HDD, SSD) (or non-volatile memory) of the server (101).

In one embodiment, the metadata DB (190) can store (or manage) the location and/or status of data chunks stored in the storage (180).

Below, the operation of the server (101) performing a scan task, a heal task, a recovery task, and a task according to a user request is described.

Scan task

In one embodiment, the data scan module (141) may operate in the background. In one embodiment, the data scan module (141) may be executed by the processor (120) regardless of a user request.

In one embodiment, the data scan module (141) can identify a scan request. For example, the data scan module (141) can repeatedly identify a scan request. For example, the data scan module (141) can identify a scan event that occurs repeatedly to check the status of all data chunks (or data pieces) (or data blocks) stored in the storage (180). For example, the data scan module (141) can identify a scan event that occurs repeatedly to sequentially check all data chunks. In one embodiment, the repeated occurrence of a scan event can indicate that the scan event is repeated at a regular cycle. In one embodiment, the repeated occurrence of a scan event can indicate that the scan event is repeated irregularly.

In one embodiment, the data scan module (141) may input (or enqueue) (or push) a scan request (or identification information of the scan request) (or a scan task) (or identification information of the scan task) into the scan queue (211) to process a scan task according to the scan request. In one embodiment, the data scan module (141) may input (or enqueue) (or push) a scan request including information on the number of memory blocks required to process the scan task into the scan queue (211). For example, the number of memory blocks required to process the scan task may be the number of data chunks that the data scan module (141) can process simultaneously. For example, the number of memory blocks required to process the scan task may be 1. However, the present invention is not limited thereto.

In one embodiment, the data scan module (141) can identify the processing order of scan requests added to the scan queue (211). In one embodiment, the data scan module (141) can identify the processing order of scan requests based on the input order (or first-in, first-out) of the scan requests. In one embodiment, the data scan module (141) can identify that memory blocks of the scan memory pool (210) for processing the scan request are allocated based on the input order (or first-in, first-out) of the scan requests. In one embodiment, the data scan module (141) can identify that memory blocks of the scan memory pool (210) are allocated in the number of memory blocks required. For example, the data scan module (141) can identify that memory blocks of the scan memory pool (210) are allocated based on receiving a signal from the memory pool management module (160) indicating that memory blocks are allocated. However, the present invention is not limited thereto.

In one embodiment, the data scan module (141) may process a scan request based on which memory blocks of the scan memory pool (210) are allocated for the scan request. For example, the data scan module (141) may load a data chunk stored in storage (180) into a memory block of the scan memory pool (210).

In one embodiment, the data scan module (141) can check whether a data chunk stored in a memory block of the scan memory pool (210) is damaged (or hashed). For example, the data scan module (141) can check whether a data chunk is damaged (or hashed) based on a checksum (or hash value) of the data chunk.

In one embodiment, the data scan module (141) may record information about a data chunk (or abnormal data chunk) that is identified as damaged (hereinafter, damaged data chunk) in the metadata DB (190) (or metadata of the metadata DB (190)). In one embodiment, the data scan module (141) may record a mark (or a symbol) indicating that the data chunk is damaged (hereinafter, damaged mark) in the metadata of the damaged data chunk.

In one embodiment, the data scan module (141) may deallocate a memory block of the scan memory pool (210) allocated for a scan request based on completion of the verification of whether the data chunk is damaged (or has integrity). For example, the data scan module (141) may transmit a signal indicating completion of the verification of whether the data chunk is damaged (or has integrity) to the memory pool management module (160). In one embodiment, the memory pool management module (160) may deallocate a memory block of the scan memory pool (210) allocated for a scan request based on the signal. In one embodiment, the deallocated memory block may be reused to process another scan request of the data scan module (141). For example, the size of the memory block allocated to process another scan request of the data scan module (141) may be an integer multiple of the size of the memory block (or the size of the data block) (or the size of the data chunk).

In one embodiment, the data scan module (141) may notify the data heal module (143) that a corrupt data chunk has been identified based on the identification of the corrupt data chunk.

Hill Task

In one embodiment, the data hill module (143) may operate in the background. In one embodiment, the data hill module (143) may be executed by the processor (120) regardless of a user request.

In one embodiment, the data heal module (143) can identify (or generate) a heal request. For example, the data heal module (143) can repeatedly identify whether a corrupted data chunk exists through the metadata DB (190). For example, the data heal module (143) can identify whether a corrupted data chunk exists based on a notification from the data scan module (141). For example, the data heal module (143) can identify (or generate) a heal event based on the presence of a corrupted data chunk.

In one embodiment, the data hill module (143) may input (or enqueue) (or push) a hill request (or identification information of the hill request) (or a hill task) (or identification information of the hill task) into the hill queue (261) to process a hill task according to the hill request. In one embodiment, the data hill module (143) may input (or enqueue) (or push) a hill request including information on the number of memory blocks required to process the hill task into the hill queue (261). For example, the number of memory blocks required to process the hill task may be the number of data chunks required for encoding or decoding according to a specified coding technique. For example, the number of memory blocks required to process the hill task may be N+K. However, the present invention is not limited thereto.

In one embodiment, the data hill module (143) can identify the processing order of hill requests added to the hill queue (261). In one embodiment, the data hill module (143) can identify the processing order of hill requests based on the input order (or first-in, first-out) of hill requests. In one embodiment, the data hill module (143) can identify that memory blocks of the root memory pool (250) for processing hill requests are allocated based on the input order (or first-in, first-out) of hill requests. In one embodiment, the data hill module (143) can identify that memory blocks of the root memory pool (250) are allocated in the number of memory blocks required. For example, the data hill module (143) can identify that memory blocks of the root memory pool (250) are allocated based on receiving a signal from the memory pool management module (160) indicating that memory blocks are allocated. However, the present invention is not limited thereto.

In one embodiment, the data heal module (143) may process a heal request based on whether a memory block of the root memory pool (250) is allocated for the heal request. For example, the data heal module (143) may load a corrupted data chunk stored in storage (180) into a memory block of the root memory pool (250).

In one embodiment, the data heal module (143) may load at least one data chunk (hereinafter, “associated data chunk”) associated with a corrupted data chunk into a memory block of the root memory pool (250) based on whether a memory block of the root memory pool (250) is allocated for a heal request. In one embodiment, the corrupted data chunk and the at least one associated data chunk may be data chunks generated by encoding data of a specified size according to a specified coding technique. In one embodiment, the number of corrupted data chunks and the at least one associated data chunk may be N+K. In one embodiment, each of the corrupted data chunk and the at least one associated data chunk may be either a data fragment or a parity fragment.

In one embodiment, the data heal module (143) can repair the damaged data chunk based on loading the damaged data chunk and at least one associated data chunk (via the coding module (150)). For example, the data heal module (143) can decode the damaged data chunk and at least one associated data chunk into original data (via the coding module (150)). For example, the data heal module (143) can generate a repaired data chunk corresponding to the damaged data chunk by encoding the decoded original data (via the coding module (150)).

In one embodiment, the data heal module (143) may store the recovered data chunk in storage (180). For example, the data heal module (143) may store the recovered data chunk in a memory block of the root memory pool (250) allocated for the heal request, and then transmit the recovered data chunk to be distributed to storage (180).

In one embodiment, the data heal module (143) may deallocate a memory block of the root memory pool (250) allocated for a heal request based on the completion of recovery of a corrupted data chunk. For example, the data heal module (143) may transmit a signal indicating the completion of recovery of a data chunk to the memory pool management module (160). In one embodiment, the memory pool management module (160) may deallocate a memory block of the root memory pool (250) allocated for a heal request based on the signal. In one embodiment, the deallocated memory block may be reused to process another heal request of the data heal module (143) and/or another user request of the request processing module (147). For example, the size of a memory block allocated to process another heal request and/or another user request may be an integer multiple of the size of the memory block (or the size of the data block) (or the size of the data chunk).

In one embodiment, the data heal module (143) may update the metadata database (190) (or metadata of the metadata database (190)) based on the completion of the recovery of the corrupted data chunk. For example, the data heal module (143) may update the metadata of the recovered corrupted data chunk based on the completion of the recovery of the corrupted data chunk. For example, the data heal module (143) may update the metadata to indicate that the data chunk is normal.

Recovery task

In one embodiment, the server (101) may change the disk mode of the storage (180) scheduled for replacement to a read-only mode or an unavailable mode (or a maintenance mode). In one embodiment, the server (101) may not store data in the storage (180) scheduled for replacement based on a request to store data in the storage (180) scheduled for replacement. In one embodiment, the server (101) may record data information in metadata for the data requested to be stored in the storage (180) scheduled for replacement based on a request to store data in the storage (180) scheduled for replacement.

In one embodiment, the server (101) may physically replace the storage (180) after the disk mode of the storage (180) scheduled for replacement is changed.

In one embodiment, the server (101) may perform disk recovery on the storage (180) after the storage (180) has been physically replaced. In one embodiment, the server (101) may perform disk recovery after changing the disk mode of the physically replaced storage (180) to disk recovery mode. In one embodiment, a list of data to be recovered on the physically replaced storage (180) may be recorded in metadata.

In one embodiment, the disk recovery module (145) can determine whether the storage (180) is replaced. In one embodiment, the disk recovery module (145) can identify that the storage (180) has been replaced based on obtaining a signal indicating that the storage (180) has been replaced. For example, the signal indicating that the storage (180) has been replaced may be a signal generated based on a user input (or an administrator input). For example, the signal indicating that the storage (180) has been replaced may be a signal generated by components of the server (101).

In one embodiment, the disk recovery module (145) may identify (or generate) a recovery request. For example, the disk recovery module (145) may identify (or generate) a recovery request based on identifying a replacement of the storage (180). For example, the disk recovery module (145) may identify (or generate) a recovery request based on obtaining a signal indicating that the storage (180) is being replaced.

In one embodiment, the disk recovery module (145) may input (or enqueue) (or push) a recovery request (or identification information of the recovery request) (or a recovery task) (or identification information of the recovery task) into the recovery queue (231) to process a recovery task according to the recovery request. In one embodiment, the disk recovery module (145) may input (or enqueue) (or push) a recovery request including information on the number of memory blocks required to process the recovery task into the recovery queue (231). For example, the number of memory blocks required to process the recovery task may be the number of data chunks required for encoding or decoding according to a specified coding technique. For example, the number of memory blocks required to process the recovery task may be N+K. However, the present invention is not limited thereto.

In one embodiment, the disk recovery module (145) can identify the processing order of recovery requests added to the recovery queue (231). In one embodiment, the disk recovery module (145) can identify the processing order of recovery requests based on the input order (or first-in, first-out) of the recovery requests. In one embodiment, the disk recovery module (145) can identify that a memory block of the recovery memory pool (230) for processing the recovery request is allocated based on the input order (or first-in, first-out) of the recovery requests. In one embodiment, the disk recovery module (145) can identify that as many memory blocks of the recovery memory pool (230) as the number of required memory blocks are allocated. For example, the disk recovery module (145) may identify that memory blocks of the recovery memory pool (230) are allocated based on receiving a signal from the memory pool management module (160) indicating that memory blocks are allocated, but is not limited thereto.

In one embodiment, the disk recovery module (145) may process a recovery request based on which memory block of the recovery memory pool (230) is allocated for the recovery request. For example, the disk recovery module (145) may load a data chunk stored in another storage into a memory block of the recovery memory pool (230). For example, the disk recovery module (145) may load at least one data chunk (hereinafter, “associated data chunk”) associated with a data chunk stored in a storage prior to the replacement of the storage (180) (hereinafter, “failed data chunk”) from another storage into a memory block of the recovery memory pool (230). In one embodiment, the failed data chunk and the at least one associated data chunk may be N+K data chunks generated by encoding data of a specified size according to a specified coding technique.

In one embodiment, the disk recovery module (145) can recover a failed data chunk based on the loading of at least one associated data chunk. For example, the disk recovery module (145) can decode at least one associated data chunk into original data. For example, the disk recovery module (145) can recover a failed data chunk by encoding the decoded original data.

In one embodiment, the disk recovery module (145) may store the recovered fault data chunk in the replaced storage (180). For example, the disk recovery module (145) may store the recovered fault data chunk in a memory block of the recovery memory pool (230) allocated for the recovery request, and then transmit the recovered fault data chunk to be distributed to the storage (180).

In one embodiment, the disk recovery module (145) may deallocate a memory block of the recovery memory pool (230) allocated for a recovery request based on the completion of recovery of the data chunk. For example, the disk recovery module (145) may transmit a signal indicating that recovery of the data chunk is completed to the memory pool management module (160). In one embodiment, the memory pool management module (160) may deallocate a memory block of the recovery memory pool (230) allocated for a recovery request based on the signal. In one embodiment, the deallocated memory block may be reused to process a recovery request of the disk recovery module (145) and/or a user request of the request processing module (147). For example, the size of a memory block allocated to process another recovery request and/or another user request may be an integer multiple of the size of the memory block (or the size of the data block) (or the size of the data chunk).

Tasks based on user requests

In one embodiment, the request processing module (147) may operate in the foreground. In one embodiment, the request processing module (147) may be executed by the processor (120) to process a user request.

In one embodiment, the request processing module (147) may identify a user request. For example, the request processing module (147) may identify a user request received from the electronic device (103) via the communication circuit (130). For example, the user request may include storing data and/or reading data. For example, storing data may include storing multimedia content (e.g., images, videos). For example, reading data may include streaming multimedia content. However, the present invention is not limited thereto.

In one embodiment, the request processing module (147) may input (or enqueue) (or push) a user request (or identification information of the user request) (or a task) (or identification information of the task) into the request queue (240, 270) to process a task according to a user request. In one embodiment, the request processing module (147) may input (or enqueue) (or push) a user request including information on the number of memory blocks required to process the task into the request queue (240, 270). For example, the number of memory blocks required to process the task according to the user request may be the number of data chunks required for encoding or decoding according to a specified coding technique. For example, the number of memory blocks required to process the task according to the user request may be N+K. However, the present invention is not limited thereto.

In one embodiment, the request processing module (147) may input a user request into one of the request queues (240, 270). For example, the request processing module (147) may identify a request queue into which the user request is to be input based on the number of requests added to a higher queue (e.g., recovery queue (231) or heal queue (261)) of each of the request queues (240, 270). For example, the request processing module (147) may identify a request queue into which the user request is to be input based on the number of requests added to each of the request queues (240, 270). For example, the request processing module (147) may identify a request queue into which the user request is to be input based on an expected waiting time of each of the request queues (240, 270). For example, the request processing module (147) may identify the request queue with the shortest expected waiting time among the request queues (240, 270) as the request queue into which the user request will be input. For example, the expected waiting time may be a value obtained by multiplying the number of requests to be processed first by the expected processing time of each request. The requests to be processed first may include requests added to a higher queue (e.g., recovery queue (231) or heal queue (261)). The requests to be processed first may include requests added first to each of the request queues (240, 270). According to an embodiment, when the request queue (240) includes a plurality of request queues (241, 243, 245), the request processing module (147) may identify a request queue into which a user request is to be input based on a processing order (e.g., a round-robin order) among the plurality of request queues (241, 243, 245) (having the same priority). According to an embodiment, when the request queue (270) includes a plurality of request queues (271, 273, 275), the request processing module (147) may identify a request queue into which a user request is to be input based on a processing order (e.g., a round-robin order) among the plurality of request queues (271, 273, 275). However, the present invention is not limited thereto.

In one embodiment, a user request of the electronic device (103) may be input to a request queue selected from among a plurality of request queues (241, 243, 245) and a pair of request queues (e.g., 241 and 271, 243 and 273, or 245 and 275) from among a plurality of request queues (271, 273, 275). For example, a first request queue pair may include request queues (241 and 271) assigned to a first type of electronic devices. For example, a second request queue pair may include request queues (243 and 273) assigned to a second type of electronic devices. For example, a third request queue pair may include request queues (245 and 275) assigned to a third type of electronic devices. Types may be distinguished by, but are not limited to, regional distinctions, and/or user account tiers (e.g., fee plans).

In one embodiment, the request processing module (147) can identify the processing order of user requests added to the request queue (240, 270). In one embodiment, the request processing module (147) can identify the processing order of user requests based on the input order (or first-in, first-out) of the user requests.

In one embodiment, the request processing module (147) can identify that a memory block of the recovery memory pool (230) for processing a user request is allocated based on the input order (or first-in, first-out) of the user requests added to the request queue (240). In one embodiment, the request processing module (147) can identify that a memory block of the recovery memory pool (230) for processing a user request is allocated after all recovery requests of the recovery queue (231) are processed. In one embodiment, the request processing module (147) can identify that as many memory blocks of the recovery memory pool (230) as the number of required memory blocks are allocated. For example, the request processing module (147) may identify that memory blocks of one of the recovery memory pool (230) or the root memory pool (250) are allocated based on receiving a signal from the memory pool management module (160) indicating that memory blocks are allocated. For example, the request processing module (147) may identify that memory blocks of a memory pool associated with a queue to which a user request has been added are allocated based on receiving a signal from the memory pool management module (160) indicating that memory blocks are allocated. However, the present invention is not limited thereto.

In one embodiment, the request processing module (147) may identify that a memory block of the root memory pool (250) for processing a user request is allocated based on the input order (or first-in, first-out) of the user requests added to the request queue (270). In one embodiment, the request processing module (147) may identify that a memory block of the root memory pool (250) for processing a user request is allocated after all recovery requests of the heal queue (261) are processed. In one embodiment, the request processing module (147) may identify that as many memory blocks of the root memory pool (250) as the number of required memory blocks are allocated.

In one embodiment, the request processing module (147) may process a user request based on whether a memory block of the recovery memory pool (230) or the root memory pool (250) is allocated for the user request. Hereinafter, processing of a user request may be described with reference to FIGS. 3A and 3B.

In one embodiment, the request processing module (147) may deallocate a memory block of the recovery memory pool (230) or the root memory pool (250) allocated for the user request based on the completion of processing the user request. In one embodiment, the deallocated memory block may be reused to process a recovery request of the disk recovery module (145), a heal request of the data heal module (143), and/or a user request of the request processing module (147). For example, if the deallocated memory block is a memory block of the recovery memory pool (230), the deallocated memory block may be reused to process the recovery request and/or the user request. For example, if the deallocated memory block is a memory block of the root memory pool (250), the deallocated memory block may be reused to process the heal request and/or the user request.

As described above, the server (101) can save data storage space required for data recovery (or data durability) through erasure coding. For example, by additionally storing only the parity generated through erasure coding, the server (101) may require less storage space than when storing copies of data.

As described above, the server (101) can utilize memory blocks equal to the number of data chunks requested for processing by matching the size of the data chunks with the size of the memory blocks. Accordingly, the server (101) can reduce wasted memory resources.

As described above, the server (101) can increase the durability of the server (101) by processing system tasks (e.g., recovery, healing, scanning) before tasks according to user requests. In addition, the server (101) can process tasks according to user requests in a memory area for processing system tasks (e.g., recovery, healing, scanning), so that the processing capacity of user requests can be adjusted according to the number of system tasks.

FIG. 3A illustrates an example of an operation of a server encoding data, according to one embodiment.

In one embodiment, the request processing module (147) may obtain a user request for storage of data (310) from the electronic device (103) via the communication circuit (130).

In one embodiment, the request processing module (147) may request the coding module (150) to encode data (310) based on the allocation of the memory area of the memory pool (170). For example, the memory area (320, 330) of the memory pool (170) allocated for encoding data (310) according to a user request may be included in the recovery memory pool (230). For example, the memory area (320, 330) of the memory pool (170) allocated for encoding data (310) may be included in the root memory pool (250). For example, the memory area (320, 330) of the memory pool (170) allocated for encoding data (310) may correspond to the size of N+K memory blocks.

In one embodiment, the encoder (151) of the coding module (150) may encode data (310) based on a coding technique (e.g., erasure coding technique) in response to a request from the request processing module (147). In one embodiment, the encoder (151) of the coding module (150) may encode data (310) based on a specified code (e.g., RS (Reed-Solomon) code). In one embodiment, the encoder (151) may divide the data (310) into N data pieces (or data chunks) (311, 313, 315), and encode the divided N data pieces (or data chunks) (311, 313, 315) into N+K data pieces (or data chunks) (321, 323, 325, 331, 335) based on a specified code. In one embodiment, the K data pieces may be referred to as parity pieces. In one embodiment, the sizes of the data pieces may be the same. For example, the sizes of the data pieces may be between 1 and 5 megabytes. For example, N and K are natural numbers, and K may be less than or equal to N. For example, N may be 6, and K may be 3. However, the present invention is not limited thereto. The code for erasure coding is not limited to RS code. Depending on the embodiment, the code for erasure coding may include a Hamming code, a Bose-Chaudhuri-Hocquenghem (BCH) code, or a low-density parity check (LDPC) code. Depending on the embodiment, the code for erasure coding may be a code having the properties of a (linear) block code. However, the present invention is not limited thereto.

For example, each of N data fragments (321, 323, 325) may correspond to N data fragments (311, 313, 315), respectively. For example, data fragment (321) may correspond to data fragment (311), data fragment (323) may correspond to data fragment (313), and data fragment (325) may correspond to data fragment (315).

In one embodiment, the request processing module (147) can (distributely) store N+K data fragments (321, 323, 325, 331, 335) in different sub-storages (341, 343, 345, 347, 359) of the storage (180). For example, the request processing module (147) can store the data fragment (321) in the sub-storage (341), store the data fragment (323) in the sub-storage (343), store the data fragment (325) in the sub-storage (345), store the data fragment (331) in the sub-storage (347), and store the data fragment (335) in the sub-storage (349). In one embodiment, the sub-storages (341, 343, 345, 347, 359) may be storages arranged in a distributed manner within the server (101), but are not limited thereto.

In one embodiment, the request processing module (147) may store location information of N+K data pieces (321, 323, 325, 331, 335) in the metadata database (190).

FIG. 3b illustrates an example of an operation of a server decoding data, according to one embodiment.

In one embodiment, the request processing module (147) may obtain a user request for storage of data (310) from the electronic device (103) via the communication circuit (130).

In one embodiment, the request processing module (147) may request the coding module (150) to decode data fragments (321, 323, 325, 331, 335) based on the memory area of the memory pool (170) being allocated.

In one embodiment, the request processing module (147) may request the coding module (150) to decode N+K data fragments (321, 323, 325, 331, 335) that are (distributedly) stored in different sub-storages (341, 343, 345, 347, 359) of the storage (180). In one embodiment, the location information of the data fragments (321, 323, 325, 331, 335) may be stored in the metadata database (190).

For example, the memory area (320, 330) of the memory pool (170) allocated for decoding data fragments (321, 323, 325, 331, 335) according to a user request may be included in the recovery memory pool (230). For example, the memory area (320, 330) of the memory pool (170) allocated for decoding data fragments (321, 323, 325, 331, 335) may be included in the root memory pool (250). For example, the size of the memory area (320, 330) of the memory pool (170) allocated for decoding data fragments (321, 323, 325, 331, 335) may correspond to the size of N+K memory blocks.

In one embodiment, the decoder (155) of the coding module (150) can decode data fragments (321, 323, 325, 331, 335) based on a coding technique (e.g., erasure coding technique) in response to a request from the request processing module (147). In one embodiment, the decoder (155) of the coding module (150) can decode data fragments (321, 323, 325, 331, 335) based on a specified code (e.g., RS (Reed-Solomon) code). In one embodiment, the decoder (155) can decode N+K data fragments (321, 323, 325, 331, 335) into N data fragments (or data chunks) (311, 313, 315) based on a designated code. In one embodiment, the K data fragments can be referred to as parity fragments. In one embodiment, the sizes of the data fragments can be the same. For example, the sizes of the data fragments can be between 1 and 5 megabytes. For example, N and K are natural numbers, and K can be less than or equal to N. For example, N can be 6, and K can be 3. However, the present invention is not limited thereto. The code for the erasure coding technique is not limited to the RS code. According to an embodiment, the code for erasure coding may include a Hamming code, a Bose-Chaudhuri-Hocquenghem (BCH) code, or a Low-Density Parity Check (LDPC) code. According to an embodiment, the code for erasure coding may be a code having the properties of a (linear) block code, but is not limited thereto.

In one embodiment, when an error occurs in K or fewer data pieces among N+K data pieces (321, 323, 325, 331, 335), the decoder (155) can recover (or decode) the remaining data pieces (hereinafter, normal data pieces) in which no error occurred into the original data (or N data pieces (311, 313, 315). However, the present invention is not limited thereto. Depending on the embodiment, the error correction capability (or error detection capability) may vary depending on the code for the erasure coding technique.

Figure 4 is a flowchart illustrating the operation of a server according to one embodiment.

Figure 4 can be described with reference to Figures 1 through 3b. In the following embodiments, the operations may be performed sequentially, but are not necessarily performed sequentially. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 410 to 430 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

Referring to FIG. 4, in one embodiment, at operation 410, the server (101) may identify a request. In one embodiment, the request may be a user request, a recovery request, a heal request, or a scan request.

For example, the server (101) may identify a scan event that occurs repeatedly to check the status of all data chunks stored in the storage (180) as a scan request. For example, the server (101) may identify a heal request based on the presence of a damaged data chunk. For example, the server (101) may identify a recovery request based on the replacement of the storage (180). For example, the server (101) may obtain a user request from the electronic device (103) via the communication circuit (130).

In operation 420, in one embodiment, the server (101) may allocate memory for the request. For example, the server (101) may allocate at least one memory block from a memory pool associated with a queue corresponding to the request for the request. For example, the server (101) may allocate at least one memory block from a memory pool associated with a queue corresponding to the request for the request based on the arrival of the request's order.

For example, the server (101) may allocate memory blocks of the scan memory pool (210) associated with the scan queue (211) for the scan request based on a scan request. For example, the server (101) may allocate memory blocks of the root memory pool (250) associated with the heal queue (261) for the heal request based on a heal request. For example, the server (101) may allocate memory blocks of the recovery memory pool (230) associated with the recovery queue (231) for the recovery request based on a recovery request. For example, the server (101) may allocate memory blocks of the recovery memory pool (230) or the root memory pool (250) associated with the request queues (240, 270) for the user request based on a user request.

In operation 430, in one embodiment, the server (101) can process the request based on the allocated memory. In one embodiment, the server (101) can use the memory block allocated for the scan request to check whether the data chunk is damaged (or has integrity). In one embodiment, the server (101) can use the memory block allocated for the heal request to repair the damaged data chunk. In one embodiment, the server (101) can use the memory block allocated for the recovery request to restore the faulty data chunk. In one embodiment, the server (101) can use the memory block allocated for the user request to store (or store after encoding) or read (or decode after reading) the data.

FIG. 5A is a flowchart illustrating the operation of a server according to one embodiment.

Figure 5a can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 510 to 540 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

Referring to FIG. 5A, in one embodiment, at operation 510, the server (101) may identify a user request. For example, the server (101) may identify a user request received from the electronic device (103) via the communication circuit (130). For example, the user request may include storing data and/or reading data. For example, storing data may include storing multimedia content (e.g., images, videos). For example, storing data may include storing personal data of the user (e.g., contacts, text messages, health status, and/or exercise records). For example, storing data may include service log data and/or binary files (e.g., smartphone firmware). For example, reading data may include streaming multimedia content. For example, reading data may include reading (for recovery) personal data of the user, service log data, and/or binary files (e.g., smartphone firmware). However, the present invention is not limited thereto.

In operation 520, in one embodiment, the server (101) may determine whether to add a user request to a first request queue. For example, the first request queue may be a request queue (240). For example, the second request queue may be a request queue (270).

For example, the server (101) can identify a request queue into which a user request is to be input based on the number of requests added to a higher queue (e.g., recovery queue (231) or heal queue (261)) of each of the request queues (240, 270). For example, the server (101) can identify a request queue into which a user request is to be input based on the number of requests added to each of the request queues (240, 270). For example, the server (101) can identify a request queue into which a user request is to be input based on an expected waiting time of each of the request queues (240, 270). For example, the expected waiting time may be a product of the number of requests to be processed first and the expected processing time of each of the requests. The requests to be processed first may include requests added to a higher queue (e.g., recovery queue (231) or heal queue (261)). Requests to be processed first may include requests that were first added to each of the request queues (240, 270). According to an embodiment, when the request queue (240) includes a plurality of request queues (241, 243, 245), the server (101) may identify a request queue into which a user request is to be input based on a processing order (e.g., a round-robin order) among the plurality of request queues (241, 243, 245). According to an embodiment, when the request queue (270) includes a plurality of request queues (271, 273, 275), the server (101) may identify a request queue into which a user request is to be input based on a processing order (e.g., a round-robin order) among the plurality of request queues (271, 273, 275). However, the present invention is not limited thereto.

At operation 520, based on the determination to add the user request to the first request queue, the server (101) may perform operation 530. At operation 520, based on the determination to add the user request to the second request queue, the server (101) may perform operation 540.

In operation 530, in one embodiment, the server (101) may add a user request to a first request queue. In one embodiment, the server (101) may input (or enqueue) (or push) a user request (or identification information of the user request) (or a task) (or identification information of the task) to the first request queue to process a task according to the user request.

In operation 540, in one embodiment, the server (101) may add a user request to a second request queue. In one embodiment, the server (101) may input (or enqueue) (or push) a user request (or identification information of the user request) (or a task) (or identification information of the task) to the second request queue to process a task according to the user request.

FIG. 5b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 5b can be described with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 550 to 580 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1). According to one embodiment, the operations of FIG. 5b may be performed in parallel with the operations of FIG. 5a.

Referring to FIG. 5B, in operation 550, in one embodiment, the server (101) can determine whether the processing order of the user requests added to the request queue is correct. In one embodiment, the server (101) can identify the processing order of the user requests based on the input order (or first-in, first-out) of the user requests. In one embodiment, the server (101) can identify the processing order of the user requests based on the input order (or first-in, first-out) of the user requests when there are no tasks in a queue (e.g., recovery queue (231), heal queue (261)) that has priority over the request queue (or when all tasks have been processed).

In operation 550, based on the arrival of the turn for processing the user request added to the request queue, the server (101) may perform operation 560. In operation 550, based on the arrival of the turn for processing the user request added to the request queue, the server (101) may perform operation 550 again.

In operation 560, in one embodiment, the server (101) may allocate memory corresponding to a user request. In one embodiment, the server (101) may allocate a memory area of N+K memory blocks corresponding to the sizes of N+K data chunks to process the user request.

In operation 570, in one embodiment, the server (101) may process a user request based on the allocated memory. For example, the server (101) may encode data according to the user request based on the allocated memory. For example, the server (101) may distribute and store N+K encoded data chunks in the storage (180).

For example, the server (101) can decode data according to a user request based on the allocated memory. For example, the server (101) can transmit decoded data from N+K data chunks distributed and stored in the storage (180) to the electronic device (103) through the communication circuit (130).

In operation 580, in one embodiment, the server (101) may deallocate allocated memory. For example, the server (101) may deallocate allocated memory based on the completion of processing a user request. For example, the server (101) may deallocate allocated memory based on the data according to the user request being encoded and then stored in the storage (180). For example, the server (101) may deallocate allocated memory based on the data according to the user request being decoded and then transmitted to the electronic device (103).

FIG. 6A is a flowchart illustrating the operation of a server according to one embodiment.

Figure 6a can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 610 and 620 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

Referring to FIG. 6A, in one embodiment, at operation 610, the server (101) may identify a recovery request. For example, the server (101) may identify (or generate) a recovery request based on identifying a replacement of the storage (180). For example, the server (101) may identify (or generate) a recovery request based on obtaining a signal indicating that the storage (180) is being replaced.

In operation 620, in one embodiment, the server (101) may add a recovery request to the recovery queue. In one embodiment, the server (101) may input (or enqueue) (or push) the recovery request (or the identification information of the recovery request) (or the recovery task) (or the identification information of the recovery task) to the recovery queue (231) to process a recovery task according to the recovery request. In one embodiment, the server (101) may input (or enqueue) (or push) a recovery request including information on the number of memory blocks required to process the recovery task to the recovery queue (231).

Figure 6b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 6b can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 630 to 660 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1). According to one embodiment, the operations of FIG. 6b may be performed in parallel with the operations of FIG. 6a.

Referring to FIG. 6B, in operation 630, in one embodiment, the server (101) can determine whether the recovery request added to the recovery queue is in a processing order. In one embodiment, the server (101) can identify the processing order of the recovery request based on the input order (or first-in, first-out) of the recovery request.

In operation 630, in one embodiment, based on the arrival of a turn for processing a recovery request added to the recovery queue, the server (101) may perform operation 640. In operation 630, based on the arrival of a turn for processing a recovery request added to the recovery queue, the server (101) may perform operation 630 again.

In operation 640, in one embodiment, the server (101) may allocate memory corresponding to the recovery request. In one embodiment, the server (101) may allocate a memory area of N+K memory blocks corresponding to the sizes of N+K data chunks to process the recovery request.

In operation 650, in one embodiment, the server (101) may process a recovery request based on allocated memory.

For example, the server (101) may load a data chunk stored in another storage into a memory block of the recovery memory pool (230). For example, the server (101) may load an associated data chunk of a failed data chunk stored in a storage before the replacement of the storage (180) from another storage into a memory block of the recovery memory pool (230). In one embodiment, the failed data chunk and the associated data chunk may be N+K data chunks generated by encoding data of a specified size according to a specified coding technique.

In one embodiment, the server (101) can recover a faulty data chunk based on the loading of the associated data chunk. For example, the server (101) can decode the associated data chunk into original data. For example, the server (101) can recover a faulty data chunk by encoding the decoded original data.

In one embodiment, the server (101) may store the recovered fault data chunk in the replaced storage (180).

In operation 660, in one embodiment, the server (101) may deallocate allocated memory. For example, the server (101) may deallocate allocated memory based on the completion of processing a recovery request. For example, the server (101) may deallocate allocated memory based on the recovery of a fault data chunk according to a recovery request and its storage (180).

Thereafter, the server (101) may generate a recovery request to recover the next failed data chunk stored in the storage prior to replacement of the storage (180). For example, the server (101) may generate a recovery request until all failed data chunks stored in the storage prior to replacement are recovered. However, this is not a limitation.

FIG. 7a is a flowchart illustrating the operation of a server according to one embodiment.

Figure 7a can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 710 and 720 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

Referring to FIG. 7A, according to one embodiment, in operation 710, the server (101) may identify a scan request. For example, the server (101) may repeatedly identify a scan request. For example, the server (101) may identify a scan event that occurs repeatedly to check the status of all data chunks (or data pieces) (or data blocks) stored in the storage (180) as a scan request.

In operation 720, in one embodiment, the server (101) may add a scan request to a scan queue. In one embodiment, the server (101) may input (or enqueue) (or push) a scan request (or identification information of the scan request) (or a scan task) (or identification information of the scan task) into the scan queue (211) to process a scan task according to the scan request. In one embodiment, the server (101) may input (or enqueue) (or push) a scan request including information on the number of memory blocks required to process the scan task into the scan queue (211).

Figure 7b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 7b can be described with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 730 to 780 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1). According to one embodiment, the operations of FIG. 7b may be performed in parallel with the operations of FIG. 7a.

Referring to FIG. 7B, in operation 730, in one embodiment, the server (101) can determine whether the scan request added to the scan queue is in the processing order. In one embodiment, the server (101) can identify the processing order of the scan request added to the scan queue (211). In one embodiment, the server (101) can identify the processing order of the scan request based on the input order (or first-in, first-out) of the scan request.

In operation 730, based on the arrival of a turn for processing a scan request added to the scan queue, the server (101) may perform operation 740. In operation 730, based on the arrival of a turn for processing a scan request added to the scan queue, the server (101) may perform operation 730 again.

In operation 740, in one embodiment, the server (101) may allocate memory corresponding to the scan request. In one embodiment, the server (101) may allocate a number of memory blocks required to process the scan task for the scan request.

In operation 750, in one embodiment, the server (101) can identify a data chunk corresponding to a scan request based on allocated memory. In one embodiment, the server (101) can check whether a data chunk stored in a memory block of the scan memory pool (210) is damaged (or hashed). For example, the server (101) can check whether a data chunk is damaged (or hashed) based on a checksum (or hash value) of the data chunk.

In operation 760, in one embodiment, the server (101) may determine whether a data chunk is corrupted.

At operation 760, based on whether the data chunk is damaged, the server (101) may perform operation 770. At operation 760, based on whether the data chunk is not damaged, the server (101) may perform operation 780.

In operation 770, in one embodiment, the server (101) may mark a damaged data chunk. In one embodiment, the server (101) may record information about a data chunk (or abnormal data chunk) identified as damaged (hereinafter, damaged data chunk) in the metadata DB (190) (or metadata of the metadata DB (190)). In one embodiment, the server (101) may write a mark (or a mark) indicating that the data chunk is damaged (hereinafter, damaged mark) in the metadata of the damaged data chunk.

In operation 780, in one embodiment, the server (101) may deallocate allocated memory. In one embodiment, the server (101) may deallocate a memory block of the scan memory pool (210) allocated for the scan request based on the completion of the verification of whether the data chunk is corrupted (or, integrity).

Figure 8a is a flowchart illustrating the operation of a server according to one embodiment.

Figure 8a can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 810 to 830 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

Referring to FIG. 8A, in one embodiment, at operation 810, the server (101) may identify whether a corrupted data chunk exists. For example, the server (101) may repeatedly identify whether a corrupted data chunk exists through the metadata DB (190). For example, the server (101) may identify whether a corrupted data chunk exists based on a notification from the data scan module (141).

In operation 820, in one embodiment, the server (101) may identify a heal request. For example, the server (101) may identify (or generate) a heal event based on the presence of a corrupted data chunk.

In operation 830, in one embodiment, the server (101) may add a hill request to the hill queue. In one embodiment, the server (101) may input (or enqueue) (or push) a hill request (or identification information of the hill request) (or a hill task) (or identification information of the hill task) into the hill queue (261) to process a hill task according to the hill request. In one embodiment, the server (101) may input (or enqueue) (or push) a hill request including information on the number of memory blocks required to process the hill task into the hill queue (261).

Figure 8b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 8b can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 840 to 870 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1). According to one embodiment, the operations of FIG. 8b may be performed in parallel with the operations of FIG. 8a.

Referring to FIG. 8b, in operation 840, in one embodiment, the server (101) can determine whether the processing order of the hill request added to the hill queue is correct.

In operation 840, based on the arrival of a turn for processing a hill request added to the hill queue, the server (101) may perform operation 850. In operation 840, based on the arrival of a turn for processing a hill request added to the hill queue, the server (101) may perform operation 840 again.

In operation 850, in one embodiment, the server (101) may allocate memory corresponding to the hill request. In one embodiment, the server (101) may allocate a memory area of N+K memory blocks corresponding to the sizes of N+K data chunks to process the hill request.

In operation 860, in one embodiment, the server (101) may restore the corrupted data chunk corresponding to the heal request based on the allocated memory.

For example, the server (101) may load the corrupted data chunk stored in the storage (180) into a memory block of the root memory pool (250). For example, the server (101) may load the corrupted data chunk and the associated data chunk into the memory block of the root memory pool (250) based on the memory block of the root memory pool (250) being allocated for a heal request. In one embodiment, the number of corrupted data chunks and at least one associated data chunk may be N+K.

In one embodiment, the server (101) can repair the damaged data chunk based on the loading of the damaged data chunk and at least one associated data chunk. For example, the server (101) can decode the damaged data chunk and at least one associated data chunk into original data. For example, the server (101) can generate a repaired data chunk corresponding to the damaged data chunk by encoding the decoded original data.

In one embodiment, the server (101) may store the recovered data chunks in storage (180).

In operation 870, in one embodiment, the server (101) may deallocate allocated memory. In one embodiment, the server (101) may deallocate a memory block of the root memory pool (250) allocated for the heal request based on the completion of the recovery of the damaged data chunk.

FIG. 9A is a flowchart illustrating the operation of a server according to one embodiment.

Figure 9a can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 910 to 960 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

The operations of FIG. 9a may be performed for each of the lower memory pools of the memory pool (170). For example, the operations of FIG. 9a may be performed independently (or in parallel) for each of the scan memory pool (210), the recovery memory pool (230), and the root memory pool (250).

Referring to FIG. 9A, in one embodiment, at operation 910, the server (101) may identify the status of a memory pool. For example, the server (101) may identify whether a memory area of the memory pool (170) has been allocated for requests. For example, the server (101) may identify whether a memory area of a designated memory pool (e.g., scan memory pool (210), recovery memory pool (230), root memory pool (250)) of the memory pool (170) has been allocated for requests.

In operation 920, in one embodiment, the server (101) may determine whether available memory exists. For example, the server (101) may identify an available memory area that has not been allocated for requests among the memory areas of the memory pool (170).

At operation 920, based on determining that available memory exists, the server (101) may perform operation 930. At operation 920, based on determining that available memory does not exist, the server (101) may perform operation 910 again.

In operation 930, in one embodiment, the server (101) may identify a queue associated with a memory pool. For example, the server (101) may identify a queue (e.g., a scan queue (211), a recovery queue (231), a heal queue (261), and/or a request queue (240, 270)) associated with a specified memory pool (e.g., a scan memory pool (210), a recovery memory pool (230), a root memory pool (250)).

In operation 940, in one embodiment, the server (101) may determine whether a task exists in a queue. For example, the server (101) may determine whether a task exists in a top-level queue (e.g., scan queue (211), recovery queue (231), heal queue (261)) directly connected to a specified memory pool.

At operation 940, based on determining that a task exists, the server (101) may perform operation 950. At operation 940, based on determining that a task does not exist, the server (101) may perform operation 960.

In operation 950, in one embodiment, the server (101) may process a task. In one embodiment, processing the task may include allocating memory for processing the task. In one embodiment, processing the task may include performing a task related to the task through the allocated memory. In one embodiment, processing the task may include deallocating the allocated memory. In one embodiment, the task may include a scan task, a heal task, a recovery task, and/or a task according to a user request. In one embodiment, if the task is a task according to a user request, processing the task may include performing operations 560 to 580 of FIG. 5B. In one embodiment, if the task is a recovery task, processing the task may include performing operations 640 to 660 of FIG. 6B. In one embodiment, if the task is a scan task, processing the task may include performing operations 740 to 780 of FIG. 7B. In one embodiment, if the task is a hill task, processing the task may include performing operations 850 to 870 of FIG. 8B.

For example, the server (101) can allocate a number of memory blocks required for processing the task to the task.

In operation 960, in one embodiment, the server (101) may determine whether a queue connected to the queue exists. For example, the server (101) may determine whether a subqueue connected to the top-level queue exists. For example, the server (101) may determine whether a request queue (240, 270) connected to the top-level queue exists.

At operation 960, based on determining that a queue connected to the queue exists, the server (101) may perform operation 940. In one embodiment, at operation 940, which is performed after operation 960, the server (101) may determine whether a task exists in a subqueue. For example, the server (101) may determine whether a task exists in a subqueue (e.g., a request queue (240, 270)) indirectly connected to a designated memory pool. At operation 940, based on determining that a task exists, the server (101) may process a task according to a user request at operation 950.

At operation 940, based on determining that the queue connected to the queue does not exist, the server (101) may perform operation 910.

FIG. 9b is a flowchart illustrating the operation of a server according to one embodiment.

Figure 9b can be explained with reference to Figures 1 to 3b. In the embodiment, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

According to one embodiment, operations 970 to 990 may be understood to be performed in a processor (e.g., processor (120) of FIG. 1) of a server (e.g., server (101) of FIG. 1).

The operations of FIG. 9b can be performed independently (or in parallel) with the operations of FIG. 9a.

Referring to FIG. 9B, in one embodiment, at operation 970, the server (101) may identify a request. In one embodiment, the request may be generated by a process running in the background and/or foreground. For example, the request may include a user request received from the electronic device (103). For example, the user request may include storing data and/or reading data. In one embodiment, the request may include a request for processing a system task. For example, the request for processing a system task may include a heal request for processing a heal task, a scan request for processing a scan task, and/or a recovery request for processing a recovery task.

In one embodiment, at operation 980, the server (101) may identify a queue corresponding to the request.

For example, the server (101) may identify the scan queue (211) as the queue corresponding to the request based on the request being a scan request. For example, the server (101) may identify the recovery queue (231) as the queue corresponding to the request based on the request being a recovery request. For example, the server (101) may identify the heal queue (261) as the queue corresponding to the request based on the request being a heal request.

For example, the server (101) may identify a request queue (240, 270) as a queue corresponding to the request based on whether the request is a user request. For example, the server (101) may identify a queue to which to add the user request among a plurality of request queues (240, 270) based on whether the request is a user request. For example, the request queue to which to input the user request may be identified based on the number of requests added to a higher queue (e.g., a recovery queue (231) or a heal queue (261)) of each of the request queues (240, 270).

In one embodiment, at operation 990, the server (101) may add a request to the identified queue.

For example, the server (101) can input (or enqueue) (or push) a scan request (or identification information of the scan request) (or scan task) (or identification information of the scan task) into the scan queue (211). For example, the server (101) can input (or enqueue) (or push) a scan request including information on the number of memory blocks required to process the scan task into the scan queue (211).

For example, the server (101) can input (or enqueue) (or push) a recovery request (or identification information of the recovery request) (or a recovery task) (or identification information of the recovery task) into the recovery queue (231). For example, the server (101) can input (or enqueue) (or push) a recovery request including information on the number of memory blocks required to process the recovery task into the recovery queue (231).

For example, the server (101) can input (or enqueue) (or push) a hill request (or identification information of the hill request) (or a hill task) (or identification information of the hill task) into the hill queue (261). For example, the server (101) can input (or enqueue) (or push) a hill request including information on the number of memory blocks required to process the hill task into the hill queue (261).

For example, the server (101) may identify a request queue (240, 270) as a queue corresponding to the request based on whether the request is a user request. For example, the server (101) may identify a queue to which to add the user request among a plurality of request queues (240, 270) based on whether the request is a user request. For example, the request queue to which to input the user request may be identified based on the number of requests added to a higher queue (e.g., a recovery queue (231) or a heal queue (261)) of each of the request queues (240, 270).

For example, the server (101) can input (or enqueue) (or push) a user request (or identification information of the user request) (or a task according to the user request) (or identification information of the task according to the user request) into the request queue (240, 270). For example, the server (101) can input (or enqueue) (or push) a user request including information on the number of memory blocks required to process a task according to the user request into the request queue (240, 270).

Figure 10 is a block diagram of a server according to one embodiment.

The server (101) of FIG. 10 may have one or more components connected via a network. For example, the server (101) may be network-connected to a plurality of storages (1010, 1030, 1050) connected via a network as storage (180). The fact that the server (101) is connected to the plurality of storages (1010, 1030, 1050) via a network may include that the plurality of storages (1010, 1030, 1050) are separate host devices for distributed storage of data.

For example, the server (101) may be connected to the metadata database (190) via a network. The fact that the server (101) is connected to the metadata database (190) via a network may include that the metadata database (190) is a separate host device for storing metadata.

In one embodiment, the server (101) may store N+K data chunks generated by encoding data according to a user request in different multiple storages (1010, 1030, 1050). For example, each of the multiple storages (1010, 1030, 1050) may store only one data chunk among the N+K data chunks.

As described above, the server (101) can provide storage services (or restore original data) through data chunks stored in other storages, even when some of the multiple storages (1010, 1030, 1050) are in an unavailable state.

FIG. 11 is a block diagram of an electronic device (1101) within a network environment (1100), according to various embodiments.

Referring to FIG. 11, in a network environment (1100), an electronic device (1101) may communicate with an electronic device (1102) via a first network (1198) (e.g., a short-range wireless communication network), or may communicate with at least one of an electronic device (1104) or a server (1108) via a second network (1199) (e.g., a long-range wireless communication network). In one embodiment, the electronic device (1101) may communicate with the electronic device (1104) via the server (1108). According to one embodiment, the electronic device (1101) may include a processor (1120), a memory (1130), an input module (1150), an audio output module (1155), a display module (1160), an audio module (1170), a sensor module (1176), an interface (1177), a connection terminal (1178), a haptic module (1179), a camera module (1180), a power management module (1188), a battery (1189), a communication module (1190), a subscriber identification module (1196), or an antenna module (1197). In some embodiments, the electronic device (1101) may omit at least one of these components (e.g., the connection terminal (1178)), or may have one or more other components added. In some embodiments, some of these components (e.g., sensor module (1176), camera module (1180), or antenna module (1197)) may be integrated into a single component (e.g., display module (1160)).

The processor (1120) may, for example, execute software (e.g., a program (1140)) to control at least one other component (e.g., a hardware or software component) of the electronic device (1101) connected to the processor (1120) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (1120) may store commands or data received from other components (e.g., a sensor module (1176) or a communication module (1190)) in a volatile memory (1132), process the commands or data stored in the volatile memory (1132), and store result data in a non-volatile memory (1134). According to one embodiment, the processor (1120) may include a main processor (1121) (e.g., a central processing unit or an application processor) or an auxiliary processor (1123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (1121). For example, when the electronic device (1101) includes the main processor (1121) and the auxiliary processor (1123), the auxiliary processor (1123) may be configured to use less power than the main processor (1121) or to be specialized for a given function. The auxiliary processor (1123) may be implemented separately from the main processor (1121) or as a part thereof.

The auxiliary processor (1123) may control at least a portion of functions or states associated with at least one component (e.g., a display module (1160), a sensor module (1176), or a communication module (1190)) of the electronic device (1101), for example, on behalf of the main processor (1121) while the main processor (1121) is in an inactive (e.g., sleep) state, or together with the main processor (1121) while the main processor (1121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (1123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (1180) or a communication module (1190)). In one embodiment, the auxiliary processor (1123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, in the electronic device (1101) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (1108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include a plurality of artificial neural network layers. The artificial neural network can be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), deep Q-networks, or a combination of two or more of the above, but is not limited to the examples described above. In addition to the hardware structure, the artificial intelligence model can additionally or alternatively include a software structure.

The memory (1130) can store various data used by at least one component (e.g., the processor (1120) or the sensor module (1176)) of the electronic device (1101). The data can include, for example, software (e.g., the program (1140)) and input data or output data for commands related thereto. The memory (1130) can include a volatile memory (1132) or a non-volatile memory (1134).

The program (1140) may be stored as software in memory (1130) and may include, for example, an operating system (1142), middleware (1144), or an application (1146).

The input module (1150) can receive commands or data to be used in a component of the electronic device (1101) (e.g., a processor (1120)) from an external source (e.g., a user) of the electronic device (1101). The input module (1150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

The audio output module (1155) can output audio signals to the outside of the electronic device (1101). The audio output module (1155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

The display module (1160) can visually provide information to an external party (e.g., a user) of the electronic device (1101). The display module (1160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. In one embodiment, the display module (1160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

The audio module (1170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (1170) can acquire sound through the input module (1150), output sound through the sound output module (1155), or an external electronic device (e.g., electronic device (1102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (1101).

The sensor module (1176) can detect the operating status (e.g., power or temperature) of the electronic device (1101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (1176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

The interface (1177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (1101) with an external electronic device (e.g., the electronic device (1102)). In one embodiment, the interface (1177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

The connection terminal (1178) may include a connector through which the electronic device (1101) may be physically connected to an external electronic device (e.g., the electronic device (1102)). In one embodiment, the connection terminal (1178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

The haptic module (1179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. In one embodiment, the haptic module (1179) may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

The camera module (1180) can capture still images and videos. In one embodiment, the camera module (1180) may include one or more lenses, image sensors, image signal processors, or flashes.

The power management module (1188) can manage the power supplied to the electronic device (1101). According to one embodiment, the power management module (1188) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

A battery (1189) may power at least one component of the electronic device (1101). In one embodiment, the battery (1189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

The communication module (1190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (1101) and an external electronic device (e.g., electronic device (1102), electronic device (1104), or server (1108)), and the performance of communication through the established communication channel. The communication module (1190) may operate independently from the processor (1120) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (1190) may include a wireless communication module (1192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (1194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, a corresponding communication module can communicate with an external electronic device (1104) via a first network (1198) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (1199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (1192) can verify or authenticate the electronic device (1101) within a communication network such as the first network (1198) or the second network (1199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (1196).

The wireless communication module (1192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (1192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (1192) may support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (1192) may support various requirements specified in the electronic device (1101), an external electronic device (e.g., the electronic device (1104)), or a network system (e.g., the second network (1199)). According to one embodiment, the wireless communication module (1192) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 664 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 6 ms or less for round trip) for URLLC realization.

The antenna module (1197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (1197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (1197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (1198) or the second network (1199), may be selected from the plurality of antennas by, for example, the communication module (1190). A signal or power may be transmitted or received between the communication module (1190) and an external electronic device via the selected at least one antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (1197).

According to various embodiments, the antenna module (1197) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band.

At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

According to one embodiment, commands or data may be transmitted or received between the electronic device (1101) and an external electronic device (1104) via a server (1108) connected to a second network (1199). Each of the external electronic devices (1102 or 1104) may be the same or a different type of device as the electronic device (1101). According to one embodiment, all or part of the operations executed in the electronic device (1101) may be executed in one or more of the external electronic devices (1102, 1104, or 1108). For example, when the electronic device (1101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (1101) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (1101). The electronic device (1101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (1101) may provide an ultra-low latency service using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (1104) may include an Internet of Things (IoT) device. The server (1108) may be an intelligent server utilizing machine learning and/or a neural network. According to one embodiment, the external electronic device (1104) or the server (1108) may be included in the second network (1199). The electronic device (1101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

As described above, the server (101) may include a communication circuit (130). The server (101) may include at least one processor (120) including a processing circuit. The server (101) may include a memory (110) in which a plurality of memory pools (210, 230, 250) for processing a plurality of system tasks, respectively, are set, instructions are stored, and one or more storage media are included. Each of the plurality of memory pools (210, 230, 250) may be divided into memory blocks of a specified size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to obtain a user request for processing data of a size of n data blocks from the electronic device (103) through the communication circuit (130). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a first memory pool (230, 250) among the plurality of memory pools (210, 230, 250) for processing the user request. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate first memory blocks of the first memory pool (230, 250) to process the user request based on all first system tasks waiting in a first system task queue (231, 261) for the first memory pool (230, 250) being processed. The size of each of the first memory blocks may correspond to the size of each of the n data blocks and k parity blocks. Each of the above data blocks may have the same size as each of the above parity blocks. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to process the data based on the allocation of the first memory blocks to process the user request.

The above instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to generate the k parity blocks for the n data blocks by encoding the data based on an erasure coding technique, based on obtaining the user request for storing the data.

The above instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to store each of the n data blocks and the k parity blocks in a plurality of different storage servers (101) via the communication circuit (130).

The above instructions, when executed individually or collectively by the at least one processor (120), may cause the server (101) to generate the data by decoding the n data blocks and the k parity blocks based on an erasure coding technique, based on obtaining the user request for reading the data.

The above instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to obtain each of the n data blocks and the k parity blocks stored in different storage servers (101) through the communication circuit (130) based on obtaining the user request for reading the data.

The plurality of system tasks may include a scan task, a recovery task, and a heal task. Each of the plurality of memory pools (210, 230, 250) may be a memory pool for one of the scan task, the recovery task, or the heal task. The memory pool for the recovery task and the memory pool for the heal task may be memory pools for processing the user request. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a memory pool with the shortest waiting time, determined based on pending tasks among the memory pools for processing the user request, as the first memory pool (230, 250).

For the first memory pool (230, 250), the processing order of multiple queues having the same priority can be determined according to the round robin technique.

The memory pool for the above scan operation and the memory pool for the above recovery operation may have fixed-size capacities. The memory pool for the above heal operation may have variable-size capacities.

The above recovery task may be a task for identifying whether there is an abnormality in the storage of each of the plurality of different storage servers (101). The scan task may be a task for identifying whether there is an abnormality in each of the data chunks of the specified size stored in the storage of each of the plurality of storage servers (101). The heal task may be a task for recovering the abnormal data chunk through the abnormal data chunk determined to be abnormal through the scan task and a plurality of associated data chunks associated with the abnormal data chunk.

The above abnormal data chunk and the plurality of associated data chunks may be generated by encoding data based on an erasure coding technique. The number of the above abnormal data chunk and the plurality of associated data chunks may be n + k.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to deallocate the first memory blocks based on completion of processing of the data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate the deallocated first memory blocks to process another task. The size of the memory block allocated to process the other task may be an integer multiple of the specified size.

The method may be performed in an electronic device (103) including a memory (110), in which a plurality of memory pools (210, 230, 250) are set for processing a plurality of system tasks, respectively, and each of the plurality of memory pools (210, 230, 250) is divided into memory blocks of a specified size. The method may include an operation of obtaining a user request for processing data of a size of n data blocks from the electronic device (103) through a communication circuit (130). The method may include an operation of identifying a first memory pool (230, 250) for processing the user request among the plurality of memory pools (210, 230, 250). The method may include an operation of allocating first memory blocks of the first memory pool (230, 250) to process the user request based on the processing of all first system tasks waiting in the first system task queue (231, 261) for the first memory pool (230, 250). The size of each of the first memory blocks may correspond to the size of each of the n data blocks and k parity blocks. Each of the data blocks may have the same size as each of the parity blocks. The method may include an operation of processing the data based on the allocation of the first memory blocks to process the user request.

The method may include an operation of generating the k parity blocks for the n data blocks by encoding the data based on an erasure coding technique, based on obtaining the user request for storing the data.

The method may include an operation of generating the data by decoding the n data blocks and the k parity blocks based on an erasure coding technique, based on obtaining the user request for reading the data.

Each of the plurality of memory pools (210, 230, 250) may be a memory pool for one of the scan task, the recovery task, or the heal task. The memory pool for the recovery task and the memory pool for the heal task may be memory pools for processing the user request. The method may include an operation of identifying a memory pool with the shortest waiting time, determined based on waiting tasks among the memory pools for processing the user request, as the first memory pool (230, 250).

The method may include an operation of deallocating the first memory blocks based on the completion of processing of the data. The method may include an operation of allocating the deallocated first memory blocks to process another task. The size of the memory blocks allocated to process the other task may be an integer multiple of the specified size.

As described above, a non-transitory computer readable storage medium can store a program including instructions. The instructions, when executed by at least one processor (120) of an electronic device (103) including a memory (110), wherein a plurality of memory pools (210, 230, 250) are set for processing a plurality of system tasks, respectively, and each of the plurality of memory pools (210, 230, 250) is divided into memory blocks of a specified size, can cause the electronic device (103) to obtain a user request for processing data of a size of n data blocks from the electronic device (103) through a communication circuit (130). The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to identify a first memory pool (230, 250) among the plurality of memory pools (210, 230, 250) for processing the user request. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to allocate first memory blocks of the first memory pool (230, 250) to process the user request based on all first system tasks waiting in a first system task queue (231, 261) for the first memory pool (230, 250) being processed. The size of each of the first memory blocks may correspond to the size of each of the n data blocks and k parity blocks. Each of the data blocks may have the same size as each of the parity blocks. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to process the data based on which the first memory blocks are allocated to process the user request.

As described above, the server (101) may include: a communication circuit (130); at least one processor (120) including a processing circuit; and at least one memory (110) including circuitry and located external to the at least one processor (120) and the communication circuit (130) and temporarily storing instructions while being used by the at least one processor (120). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to receive user data from an electronic device (103) via the communication circuit (130). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate a plurality of memory blocks of the at least one memory for encoding the user data. The plurality of memory blocks may have a predefined and identical fixed size prior to receiving the user data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to: divide the user data into data blocks, wherein each of the data blocks may have the fixed size, in accordance with encoding the user data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to generate parity blocks for repairing at least one error block among the data blocks. Each of the parity blocks may have the fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to store the data blocks and the parity blocks in the plurality of memory blocks allocated for encoding the user data. The above instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to transmit the data blocks and the parity blocks to the storage devices via the communication circuit (130) so as to be distributed among the storage devices.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to deallocate the plurality of memory blocks allocated for encoding the user data based on the data blocks and the parity blocks being transmitted to the storage devices. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a request to process at least another block stored in the storage devices. The at least another block may have the fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to, in response to identifying the request, allocate at least one memory block of the deallocated plurality of memory blocks to process the at least another block.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a request related to the user data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to enqueue the request in a user task queue for the at least one memory. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify whether a system task queue for the at least one memory is empty based on the request being enqueued. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate the plurality of memory blocks to encode the user data based on the system task queue being empty.

The above instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a user task queue among the plurality of user task queues based on waiting times when the request is enqueued in the plurality of user task queues.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify an order of the requests enqueued in the user task queue based on a round-robin technique among the plurality of user task queues. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate the plurality of memory blocks for encoding the user data in response to identifying the order of the requests.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify the user task queue corresponding to the system task queue among the plurality of system task queues based on waiting times of the plurality of system tasks enqueued in the plurality of system queues. The plurality of system task queues may be predetermined for different system tasks, respectively. The system tasks of the plurality of system task queues may be allocated to different memory areas, each of which includes different memory blocks having the fixed size.

At least one memory pool for the plurality of system task queues may include memory blocks having the same fixed size. A first memory pool for a first system task queue for recovering blocks stored in at least one failed storage device among the storage devices may have a fixed capacity among the capacities of the at least one memory. A second memory pool for a second system task queue for recovering error blocks stored in at least one of the storage devices may have a variable capacity among the capacities of the at least one memory.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to receive, from the electronic device (103) via the communication circuit (130), another request related to the data blocks and the parity blocks distributed across the storage devices. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate a plurality of other memory blocks of the at least one memory for decoding the data blocks and the parity blocks. The plurality of other memory blocks may be distinct from the plurality of memory blocks. The plurality of other memory blocks may have the same fixed size, which is predefined prior to receiving the user data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to generate the user data by decoding the data blocks and the parity blocks. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to store the generated user data in the plurality of other memory blocks. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to transmit the generated user data stored in the plurality of other memory blocks to the electronic device (103) via the communication circuit (130).

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify other requests related to the data blocks and the parity blocks distributed across the storage devices. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate at least one other memory block of the at least one memory to repair the at least one error block. The at least one error block may be a block in which at least one bit of the data blocks and the parity blocks is corrupted. At least one of the at least one other memory block may be distinct from the plurality of memory blocks. The at least one other memory block may have the fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to recover the at least one error block by error correction of the at least one error block using the data blocks and the parity blocks. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to transmit, via the communication circuit (130), to at least one of the storage devices, at least one block recovered from the at least one error block.

The fixed size of each of the plurality of memory blocks may be 1 megabyte or more.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to receive other user data from the electronic device (103) via the communication circuit (130). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate a plurality of other memory blocks of the at least one memory for encoding the other user data. The plurality of other memory blocks may have the same fixed size, which is predefined prior to receiving the user data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to: divide the other user data into other data blocks, as the other user data is encoded. Each of the other data blocks may have the fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to generate other parity blocks for repairing at least one error block among the other data blocks. Each of the other parity blocks may have the fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to store the other data blocks and the other parity blocks in the plurality of other memory blocks allocated for encoding the other user data. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to transmit the other data blocks and the other parity blocks to the storage devices via the communication circuit (130) so as to be distributed among the storage devices.

The plurality of memory blocks may be predefined within a first memory area and a second memory area of the at least one memory. The second memory area may have a plurality of memory blocks of various sizes allocated for requests unrelated to a user task for the user data and a system task for recovering the at least one error block.

As described above, the server (101) may include: a communication circuit (130); at least one processor (120) including a processing circuit; and at least one memory (110) including circuitry and located external to the at least one processor (120) and the communication circuit (130) and temporarily storing instructions while being used by the at least one processor (120). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to receive a request related to user data from an electronic device (103) via the communication circuit (130). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify the user data encoded into data blocks and parity blocks. The data blocks may be separated from the user data by the server. The parity blocks may be generated by the server to repair at least one error block of the data block. The data blocks and the parity blocks may have the same fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate a plurality of memory blocks of the at least one memory for decoding the data blocks and the parity blocks. The plurality of memory blocks may have the fixed size predefined before receiving the request. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to generate the user data by decoding the data blocks and the parity blocks. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to store the generated user data in the plurality of memory blocks. The above instructions, when executed individually or collectively by the at least one processor (120), may cause the server (101) to transmit the generated user data stored in the plurality of memory blocks to the electronic device (103) via the communication circuit (130).

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to deallocate the plurality of memory blocks allocated for decoding the data blocks and the parity blocks based on the user data being transmitted to the electronic device (103). The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a request to process at least another block stored in the storage devices. The at least another block may have the fixed size. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to, in response to identifying the request, allocate at least one memory block of the deallocated plurality of memory blocks to process the at least another block.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to enqueue the request in a user task queue for the at least one memory. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify whether a system task queue for the at least one memory is empty based on the request being enqueued. The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to allocate the plurality of memory blocks for decoding the data blocks and the parity blocks based on the system task queue being empty.

The above instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify a user task queue among the plurality of user task queues based on waiting times when the request is enqueued in the plurality of user task queues.

The instructions, when individually or collectively executed by the at least one processor (120), may cause the server (101) to identify the user task queue corresponding to the system task queue among the plurality of system task queues based on waiting times of the plurality of system tasks enqueued in the plurality of system queues. The plurality of system task queues may be predetermined for different system tasks, respectively. The system tasks of the plurality of system task queues may be allocated to different memory areas, each of which includes different memory blocks having the fixed size.

At least one memory pool for the plurality of system task queues may include memory blocks having the same fixed size. A first memory pool for a first system task queue for recovering blocks stored in at least one failed storage device among the storage devices may have a fixed capacity among the capacities of the at least one memory. A second memory pool for a second system task queue for recovering error blocks stored in at least one of the storage devices may have a variable capacity among the capacities of the at least one memory.

The fixed size of each of the plurality of memory blocks may be 1 megabyte or more.

The plurality of memory blocks may be predefined within a first memory area and a second memory area of the at least one memory. The second memory area may have a plurality of memory blocks of various sizes allocated for requests unrelated to a user task for the user data and a system task for recovering the at least one error block.

Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present document may be implemented as software (e.g., a program (1240)) including one or more instructions stored in a storage medium (e.g., an internal memory (1236) or an external memory (1238)) readable by a machine (e.g., an electronic device (1201)). For example, a processor (e.g., a processor (1220)) of the machine (e.g., an electronic device (1201)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

According to one embodiment, the method according to various embodiments disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read only memory (CD-ROM)), or may be distributed online (e.g., by download or upload) through an application store (e.g., Play Store ^™ ) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and arranged in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims (15)

In server (101), Communication circuit (130); At least one processor (120) comprising a processing circuit; and A circuit comprising at least one memory (110) located outside the at least one processor (120) and the communication circuit (130), and temporarily storing instructions while being used by the at least one processor (120), The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Through the above communication circuit (130), user data is received from the electronic device (103), For encoding the user data, a plurality of memory blocks of the at least one memory are allocated, and the plurality of memory blocks have the same fixed size predefined before receiving the user data, As we encode the above user data: Divide the above user data into data blocks, each of the data blocks having the fixed size, Generating parity blocks for recovering at least one error block among the data blocks, each of the parity blocks having the fixed size, storing the data blocks and the parity blocks in the plurality of memory blocks allocated to encode the user data, and Causing the storage devices to transmit the data blocks and the parity blocks to the storage devices through the communication circuit (130), so as to be distributed among the storage devices. Server. In claim 1, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Based on the data blocks and parity blocks being transmitted to the storage devices, the plurality of memory blocks allocated for encoding the user data are deallocated, Identify a request to process at least another block stored in said storage devices, said at least another block having said fixed size, In response to identifying the request, causing at least one memory block among the plurality of memory blocks that have been deallocated to process the at least another block, Server. In either claim 1 or 2, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Identify requests related to the above user data, Enqueue the above request into a user task queue for at least one memory, Based on the enqueuing of the above request, identifying whether the system task queue for the at least one memory is empty, Based on the above system task queue being empty, causing the allocation of the plurality of memory blocks to encode the user data, Server. In claim 3, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Causing to identify a user task queue among the plurality of user task queues based on the waiting times when the request is enqueued in the plurality of user task queues; Server. In claim 4, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Identifying the order of the requests enqueued in the user task queue based on a round robin technique among the plurality of user task queues, In response to identifying the order of the above requests, causing the allocation of the plurality of memory blocks to encode the user data, Server. In claim 3, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Based on the waiting times of a plurality of system tasks enqueued in a plurality of system queues, cause the user task queue corresponding to the system task queue among the plurality of system task queues to be identified, wherein the plurality of system task queues are each predetermined for different system tasks, and the system tasks of the plurality of system task queues are each allocated to different memory areas including different memory blocks having the fixed size. Server. In claim 6, At least one memory pool for the plurality of system task queues comprises memory blocks having the same fixed size, A first memory pool for a first system task queue for recovering blocks stored in at least one failed storage device among the above storage devices has a fixed capacity among the capacities of the at least one memory, A second memory pool for a second system task queue for recovering error blocks stored in at least one of the above storage devices has a variable capacity among the capacities of the at least one memory. Server. In any one of claims 2 to 7, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Through the communication circuit (130), receiving another request related to the data blocks and the parity blocks distributed to the storage devices from the electronic device (103), For decoding the data blocks and the parity blocks, a plurality of different memory blocks of the at least one memory are allocated, the plurality of different memory blocks are distinguished from the plurality of memory blocks, and the plurality of different memory blocks have the same fixed size predefined before receiving the user data. By decoding the above data blocks and the above parity blocks, the user data is generated, Store the generated user data in the plurality of different memory blocks, and Causing the electronic device (103) to transmit the generated user data stored in the plurality of different memory blocks through the communication circuit (130). Server. In any one of claims 2 to 7, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Identify other requests related to the data blocks and parity blocks distributed across the storage devices, In order to recover the at least one error block, at least one other memory block of the at least one memory is allocated, the at least one error block is a block in which at least one bit of the data blocks and the parity blocks is corrupted, at least one of the at least one other memory block is distinct from the plurality of memory blocks, and the at least one other memory block has the fixed size, Using the data blocks and the parity blocks, recovering the at least one error block by error correction of the at least one error block, Causing, through the communication circuit (130), to transmit at least one block recovered from the at least one error block to at least one of the storage devices. Server. In any one of claims 1 to 9, The fixed size of each of the above plurality of memory blocks is 1 megabyte or more. Server. In any one of claims 1 to 10, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Through the above communication circuit (130), other user data is received from the electronic device (103), For encoding the other user data, a plurality of other memory blocks of the at least one memory are allocated, and the plurality of other memory blocks have the same fixed size predefined before receiving the user data, As we encode the other user data above: Divide the above different user data into different data blocks, each of the different data blocks having the fixed size, Generating other parity blocks for recovering at least one error block among the other data blocks, each of the other parity blocks having the fixed size, storing said other data blocks and said other parity blocks in said plurality of other memory blocks allocated to encode said other user data, and Causing the storage devices to transmit the other data blocks and the other parity blocks to be distributed among the storage devices through the communication circuit (130). Server. In any one of claims 1 to 11, The plurality of memory blocks are predefined within the first memory area among the first memory area and the second memory area of the at least one memory, The second memory area has a plurality of memory blocks of various sizes allocated for requests unrelated to a user task for the user data and a system task for recovering the at least one error block. Server. In server (101), Communication circuit (130); At least one processor (120) comprising a processing circuit; and A circuit comprising at least one memory (110) located outside the at least one processor (120) and the communication circuit (130), and temporarily storing instructions while being used by the at least one processor (120), The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Through the above communication circuit (130), a request related to user data is received from the electronic device (103), Identifying the user data encoded with data blocks and parity blocks, wherein the data blocks are divided from the user data by the server, and the parity blocks are generated by the server to recover at least one error block of the data block, and wherein the data blocks and the parity blocks have the same fixed size, For decoding the data blocks and the parity blocks, allocate a plurality of memory blocks of the at least one memory, wherein the plurality of memory blocks have a fixed size predefined before receiving the request, By decoding the above data blocks and the above parity blocks, the user data is generated, Store the generated user data in the plurality of memory blocks, and Causing the electronic device (103) to transmit the generated user data stored in the plurality of memory blocks through the communication circuit (130). Server. In claim 13, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Based on the user data being transmitted to the electronic device (103), the plurality of memory blocks allocated for decoding the data blocks and the parity blocks are deallocated, Identify a request to process at least another block stored in said storage devices, said at least another block having said fixed size, In response to identifying the request, causing at least one memory block among the plurality of memory blocks that have been deallocated to process the at least another block, Server. In any one of claims 13 or 14, The above instructions, when individually or collectively executed by the at least one processor (120), cause the server (101) to: Enqueue the above request into a user task queue for at least one memory, Based on the enqueuing of the above request, identifying whether the system task queue for the at least one memory is empty, Based on the system task queue being empty, causing the allocation of the plurality of memory blocks to decode the data blocks and the parity blocks. Server.