Logical volume manager-based disk allocation method, device, equipment and medium

Abstract

Embodiments of the present disclosure disclose a logical volume manager-based disk allocation method, device, equipment and medium. A specific implementation of the method comprises: in response to receiving a disk allocation request sent by a client corresponding to a target user, performing loading processing on metadata of a volume group corresponding to the disk allocation request to obtain loaded metadata; performing analysis processing on the loaded metadata to generate a physical volume region object linked list and a physical volume label set; performing storage format conversion processing on the physical volume region object linked list to generate a physical volume region object array; performing mirror grouping processing on the physical volume region object array using the physical volume label set to generate a physical volume mirror sub-group array; and performing strip allocation processing on the physical volume mirror sub-group array to complete a disk allocation operation task. The implementation can improve the utilization of disk resources and the performance of a storage system while ensuring data redundancy and reliability.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer storage system technology, and more specifically to disk allocation methods, apparatus, devices, and media based on logical volume managers. Background Technology

[0002] LVM (Logical Volume Manager) is widely used in Linux systems to provide management capabilities for block storage devices. LVM allows multiple physical volumes (PVs) to be combined into volume groups (VGs), and logical volumes (LVs) to be created on top of them, thus enabling dynamic management and flexible allocation of the underlying block devices. LVM uses the Device Mapper and Multiple Device kernel modules to implement RAID (Redundant Array of Independent Disks) functionality at the LV level to improve performance and data redundancy. In particular, RAID 10 arrays, as a commonly used array for disk management, combine RAID 0 and RAID 1 array technologies, achieving high performance and high reliability through data striping between mirrored devices. Currently, when performing disk allocation operations on RAID10 based on LVM, the common approach is as follows: First, the information of each physical volume (PV) in the volume group is read into memory. Then, the available space segments of each physical volume are parsed out (each physical volume can correspond to multiple available space segments), and each available space segment is mapped to an available physical volume area (pv_area, where all pv_areas corresponding to the same PV have the same label). Finally, the disk is allocated according to the label corresponding to the pv_area (each PV label can only be used once, and other duplicate labels are discarded, meaning that only one pv_area with the same label can participate in disk allocation).

[0003] However, when using the above method, the following technical problems often arise:

[0004] Because each pv_tag (disk label) can only be used once during the disk allocation phase, the number of allocatable pv_areas may be less than the number of specified disk devices (for example, assuming there are two physical hosts, HostA and HostB, each with two disks, both disks of HostA are tagged with TagA, and both disks of HostB are tagged with TagB, and only one disk of each HostA and HostB is selected). This can lead to RAID 10 disk allocation failure (since RAID 10 requires at least 4 disks) and also reduce the utilization of disk resources (other pv_areas with the same tag are not fully utilized). Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure provide disk allocation methods, apparatuses, electronic devices, and computer-readable media based on logical volume managers to address the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a disk allocation method based on a logical volume manager. The method includes: in response to receiving a disk allocation request sent by a client corresponding to a target user; loading metadata of a volume group corresponding to the disk allocation request to obtain loaded metadata, wherein the volume group represents a storage pool storing various physical volumes; parsing the loaded metadata to generate a linked list of physical volume region objects and a set of physical volume tags; performing storage format conversion on the linked list of physical volume region objects to generate an array of physical volume region objects; using the set of physical volume tags to perform mirror grouping on the array of physical volume region objects to generate a physical volume mirror sub-group array; and performing stripe allocation on the physical volume mirror sub-group array to complete the disk allocation operation.

[0008] Secondly, some embodiments of this disclosure provide a disk allocation apparatus based on a logical volume manager. The apparatus includes: a loading processing unit configured to, in response to receiving a disk allocation request sent by a client corresponding to a target user, load metadata of a volume group corresponding to the disk allocation request to obtain loaded metadata, wherein the volume group represents a storage pool storing various physical volumes; a parsing processing unit configured to parse the loaded metadata to generate a physical volume region object linked list and a physical volume tag set; a storage format conversion processing unit configured to perform storage format conversion processing on the physical volume region object linked list to generate a physical volume region object array; a mirror grouping processing unit configured to perform mirror grouping processing on the physical volume region object array using the physical volume tag set to generate a physical volume mirror sub-group array; and a stripe allocation processing unit configured to perform stripe allocation processing on the physical volume mirror sub-group array to complete the disk allocation operation task.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] The above embodiments of this disclosure have the following beneficial effects: The disk allocation method based on a logical volume manager, as described in some embodiments of this disclosure, can improve disk resource utilization and storage system performance while ensuring data redundancy and reliability. Specifically, the reasons for RAID 10 disk allocation failure and low disk resource utilization are as follows: Since each pv_tag (disk label) can only be used once during the disk allocation phase, the number of allocatable pv_areas is less than the specified disk devices (for example, assuming there are two physical hosts, HostA and HostB, each with two disks; both disks of HostA are labeled TagA, and both disks of HostB are labeled TagB; only one disk is selected for each of HostA and HostB). This leads to RAID 10 disk allocation failure (since RAID 10 requires at least four disks) and also reduces disk resource utilization (other pv_area disk spaces with the same tag are not fully utilized). Based on this, some embodiments of the disk allocation method based on a logical volume manager disclosed herein firstly, in response to receiving a disk allocation request sent by a client corresponding to a target user, load the metadata of the volume group corresponding to the disk allocation request to obtain loaded metadata, wherein the volume group represents a storage pool storing each physical volume. This allows the metadata to be loaded into memory, thereby improving the allocation efficiency of the disk allocation. Then, the loaded metadata is parsed to generate a physical volume region object linked list and a physical volume tag set. This yields a physical volume region object linked list representing each free interval and a set of disk tags corresponding to each free interval. Next, the physical volume region object linked list is converted to a storage format to generate a physical volume region object array. This provides a physical volume region object array, facilitating random access and allowing for position swapping based on the index of the physical volume region object. Finally, using the physical volume tag set, the physical volume region object array is mirrored and grouped to generate a physical volume mirror sub-group array. This yields a physical volume mirror subgroup array, enabling the creation of mirror groups within each subgroup, with each subgroup containing a unique physical volume label. Finally, striping is applied to this physical volume mirror subgroup array to complete the disk allocation operation. This striping process allows for parallel reading and writing of multiple disks while improving disk utilization. Furthermore, by constructing mirror subgroups from the physical volume region objects in the physical volume region object array according to the principle of distinct labels within each subgroup, the construction of mirror subgroups and the ensuring of distinct labels within each group can be achieved. This allows for full utilization of disk resources while maintaining data redundancy (within the mirror subgroups).Furthermore, by performing striping allocation on the physical volume mirror sub-group array, the performance of the storage system can be improved. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the disk allocation method based on a logical volume manager according to the present disclosure;

[0014] Figure 2 This is a schematic diagram of the structure of some embodiments of a disk allocation apparatus based on a logical volume manager according to the present disclosure;

[0015] Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0016] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0017] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0018] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0019] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0020] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0021] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] Figure 1 A flow 100 is shown illustrating some embodiments of a disk allocation method based on a logical volume manager according to this disclosure. This disk allocation method based on a logical volume manager includes the following steps:

[0023] Step 101: In response to receiving a disk allocation request sent by the client corresponding to the target user, load the metadata of the volume group corresponding to the disk allocation request to obtain the loaded metadata.

[0024] In some embodiments, the execution entity (e.g., a computing device) of the disk allocation method based on a logical volume manager can, in response to receiving a disk allocation request sent by a client corresponding to a target user, load the metadata of the volume group corresponding to the disk allocation request to obtain the loaded metadata. Here, the volume group represents a storage pool storing various physical volumes. A physical volume can be understood as a disk. The client corresponding to the target user can be any client capable of sending disk allocation requests. There are no specific limitations on the client corresponding to the target user. For example, the client corresponding to the target user can be the client where the execution entity resides, or it can be a client accessed via remote control. The target user can be any user capable of operating a client to send disk allocation requests. The disk allocation request can be an instruction to create a logical volume. For example, the disk allocation request can be the `lvcreate --type raid10` command. Here, the metadata is loaded into the memory where the execution entity resides. The loaded metadata includes a physical volume information set, which may include: a physical volume segment information set and physical volume tag information. The physical volume information set can be a collection of information corresponding to each physical volume (PV) stored in the volume group. For example, the aforementioned physical volume information set could be a collection of disk information for the two disks (disk A1 and disk A2) corresponding to physical host HostA and the two disks (disk B1 and disk B2) corresponding to physical host HostB. The aforementioned physical volume segment information set could be a collection of information for each segment (including unoccupied free blocks and occupied blocks) within the physical volume corresponding to the physical volume information. The physical volume segment information in the aforementioned physical volume segment information set could include, but is not limited to: starting offset (PE - Physical Extent number), length (number of PEs occupied), and occupancy identification information (unoccupied or occupied). The aforementioned physical volume tag information could be the tag corresponding to the physical volume. For example, the aforementioned physical volume could be disk A1. The aforementioned physical volume tag information could be the tag tagA corresponding to disk A1.

[0025] Step 102: Parse the loaded metadata to generate a physical volume region object linked list and a physical volume tag set.

[0026] In some embodiments, the execution entity may parse the metadata after loading to generate a physical volume region object linked list and a physical volume tag set. The physical volume segment information in the physical volume segment information set may include: occupancy identification information. This occupancy identification information indicates whether the physical segment corresponding to the physical segment information is occupied (allocated or unallocated). The physical volume tag set may include: a first physical volume tag and a second physical volume tag. For example, the first physical volume tag may be tagA corresponding to physical host HostA. The second physical volume tag may be tagB corresponding to physical host HostB.

[0027] In some optional implementations of certain embodiments, the execution entity may perform parsing processing on the loaded metadata through the following steps to generate a physical volume region object linked list and a physical volume tag set:

[0028] The first step is to perform the following processing steps for each physical volume information in the above physical volume information set:

[0029] The first processing step is to generate a physical volume region information set based on the physical volume segment information set included in the above physical volume information.

[0030] In practice, the aforementioned executing entity can generate a physical volume region information set based on the physical volume segment information set included in the aforementioned physical volume information through the following steps:

[0031] The first step is to determine, for each physical volume segment in the above physical volume segment information set, as available physical volume segment information in response to determining that the occupancy identifier information corresponding to the above physical volume segment information indicates that the physical volume area is not occupied.

[0032] The second step is to define the identified available physical volume segment information into a set of available physical volume segment information.

[0033] The third step involves generating a physical volume region information set based on the aforementioned set of available physical volume segment information. In practice, the executing entity can first merge at least two physically contiguous physical volume segments from the available physical volume segment information set to generate updated available physical volume segment information as physical volume region information, and then use physically discontinuous available physical volume segments as physical volume region information. Finally, the resulting set of physical volume region information is determined.

[0034] The second processing step involves constructing a set of physical volume region objects based on the aforementioned physical volume region information set and the physical volume tag information included in the aforementioned physical volume information.

[0035] In practice, the aforementioned executing entity can construct a set of physical volume region objects based on the aforementioned set of physical volume region information and the physical volume tag information included in the aforementioned physical volume information through the following steps:

[0036] The first step is to perform the following construction steps for each physical volume region information in the above physical volume region information set:

[0037] The first construction step involves using a preset memory allocation function to allocate memory for the structure corresponding to the aforementioned physical volume region information, thereby obtaining a memory allocation pointer. In practice, the execution entity can call a preset memory allocation function (such as malloc() or kmalloc()) to allocate memory for the structure corresponding to the aforementioned physical volume region information, thus obtaining a memory allocation pointer. Here, the memory allocation pointer is used to point to the memory allocated to the structure.

[0038] The second construction step involves filling the aforementioned structure with data using the memory allocation pointer to construct a physical volume region object. In practice, the execution entity can access memory using the memory allocation pointer and fill the structure with the physical volume region information as a field to construct the physical volume region object. Here, the physical volume region object can be represented as a structure constructed from the aforementioned physical volume region information.

[0039] The second step is to define the constructed physical volume region objects as a set of physical volume region objects.

[0040] The second step is to construct a linked list of physical volume region objects based on the constructed sets of physical volume region objects. In practice, the execution entity can first create an empty linked list. Then, using any physical volume region object from each physical volume region object set as the head node, and setting the tail pointer of the head node to the physical volume region object corresponding to the next node. Here, the execution entity can construct the linked list of physical volume region objects by sequentially traversing each physical volume region object set, adding each physical volume region object (excluding the head node) to the linked list.

[0041] The third step is to determine the physical volume tag information included in each physical volume information set in the above physical volume information set as the physical volume tag set.

[0042] Step 103: Perform storage format conversion on the physical volume region object linked list to generate a physical volume region object array.

[0043] In some embodiments, the execution entity may perform storage format conversion processing on the physical volume region object linked list to generate a physical volume region object array.

[0044] In some optional implementations of certain embodiments, the execution entity may perform storage format conversion processing on the physical volume region object linked list through the following steps to generate a physical volume region object array:

[0045] The first step is to sort the physical volume region objects included in the aforementioned physical volume region object linked list to obtain a sorted physical volume region object linked list. In practice, the execution entity can sort the physical volume region objects in the aforementioned physical volume region object linked list from largest to smallest according to their available space size, and use a merge sort algorithm to obtain a sorted physical volume region object linked list.

[0046] The second step involves converting the sorted physical volume region object linked list into an array format to generate a physical volume region object array. In practice, the execution entity first traverses the sorted physical volume region object linked list to obtain its length (n). Then, an array of size n is allocated in memory. Finally, the sorted physical volume region object linked list is traversed again, and the address of each node (physical volume region object) is stored sequentially into the array to generate the physical volume region object array.

[0047] Step 104: Using the physical volume tag set, perform mirror grouping on the physical volume region object array to generate a physical volume mirror subgroup array.

[0048] In some embodiments, the execution entity may use the physical volume tag set to perform mirror grouping processing on the physical volume region object array to generate a physical volume mirror subgroup array.

[0049] In some optional implementations of certain embodiments, the execution entity may perform mirror grouping of the physical volume region object array using the physical volume tag set to generate a physical volume mirror sub-group array:

[0050] The first step is to perform the following mirror subgrouping generation steps for each physical volume region object in the above array of physical volume region objects:

[0051] In the first generation step, in response to the fact that the label corresponding to the above physical volume region object is the same as the label of the above first physical volume, the above physical volume region object is determined as the first mirror sub-element of the mirror sub-group.

[0052] The second generation step, in response to the fact that the label corresponding to the aforementioned physical volume region object is the same as the label of the aforementioned second physical volume, determines the physical volume region object in the aforementioned physical volume region object array that satisfies the first preset label condition as the first target physical volume region object, and performs a position swapping process on the aforementioned first target physical volume region object and the aforementioned physical volume region object, and determines the first target physical volume region object after the position swapping process as the first mirror sub-element of the mirror sub-group. Here, the position swapping process is performed by index. The aforementioned first preset label condition can be that in the physical volume region object array, the index value is the smallest, following the aforementioned physical volume region object, and is the same as the aforementioned first physical volume label.

[0053] The third generation step is to determine the physical volume region object that is adjacent to the physical volume region object and located to the right of the physical volume region object as the second target physical volume region object.

[0054] In the fourth generation step, in response to the fact that the label corresponding to the second target physical volume region object is the same as the label of the second physical volume, the second target physical volume region object is determined as the second mirror sub-element of the mirror sub-group.

[0055] In the fifth generation step, in response to the fact that the label corresponding to the second target physical volume region object is the same as the label of the first physical volume, the physical volume region object in the physical volume region object array that satisfies the second preset label condition is determined as the third target physical volume region object. Furthermore, the positions of the third target physical volume region object and the second target physical volume region object are swapped, and the third target physical volume region object after the position swap is determined as the second mirror sub-element of the mirror sub-group. Here, the second preset label condition can be the smallest index value in the physical volume region object array that is after the second target physical volume region object, has the same label as the second physical volume, and corresponds to the smallest index value.

[0056] The sixth generation step is to determine the mirror subgroup consisting of the first mirror sub-element and the second mirror sub-element as the mirror subgroup element.

[0057] The second step is to determine the array composed of the obtained image subgroup elements as the physical volume image subgroup array.

[0058] Step 105: Perform stripe allocation processing on the physical volume image subgroup array to complete the disk allocation operation task.

[0059] In some embodiments, the execution entity may perform stripe allocation processing on the physical volume image subgroup array to complete the disk allocation operation task.

[0060] In practice, the aforementioned execution entity can treat each physical volume mirror subgroup included in the physical volume mirror subgroup array as a different stripe unit, and allocate them to the logical volume according to their order in the physical volume mirror subgroup array. This achieves data striping distribution across the various physical volume mirror subgroups, completing the disk allocation operation task. Here, a stripe unit can be understood as the size of a data block written to a single disk block each time. One physical volume mirror subgroup is one stripe unit.

[0061] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a disk allocation device based on a logical volume manager. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, this disk allocation device based on a logical volume manager can be specifically applied to various electronic devices.

[0062] like Figure 2 As shown, some embodiments of the disk allocation device 200 based on a logical volume manager include: a loading processing unit 201, a parsing processing unit 202, a storage format conversion processing unit 203, a mirror grouping processing unit 204, and a stripe allocation processing unit 205. The loading processing unit 201 is configured to, in response to receiving a disk allocation request sent by a client corresponding to a target user, load the metadata of the volume group corresponding to the disk allocation request to obtain loaded metadata, wherein the volume group represents a storage pool storing each physical volume; the parsing processing unit 202 is configured to parse the loaded metadata to generate a physical volume region object linked list and a physical volume tag set; the storage format conversion processing unit 203 is configured to perform storage format conversion processing on the physical volume region object linked list to generate a physical volume region object array; the mirror grouping processing unit 204 is configured to use the physical volume tag set to perform mirror grouping processing on the physical volume region object array to generate a physical volume mirror sub-group array; and the stripe allocation processing unit 205 is configured to perform stripe allocation processing on the physical volume mirror sub-group array to complete the disk allocation operation task.

[0063] It is understandable that the units described in the logical volume manager-based disk allocation device 200 are related to the reference... Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the disk allocation device 200 based on the logical volume manager and the units contained therein, and will not be repeated here.

[0064] The following is for reference. Figure 3It shows a schematic diagram of the structure of an electronic device 300 (e.g., a computing device) suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0065] like Figure 3 As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0066] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0067] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0068] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0069] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0070] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: respond to receiving a disk allocation request sent by a client corresponding to a target user; load the metadata of the volume group corresponding to the disk allocation request to obtain loaded metadata, wherein the volume group represents a storage pool storing various physical volumes; parse the loaded metadata to generate a linked list of physical volume region objects and a set of physical volume tags; perform storage format conversion on the linked list of physical volume region objects to generate an array of physical volume region objects; use the set of physical volume tags to perform mirror grouping on the array of physical volume region objects to generate a physical volume mirror sub-group array; and perform stripe allocation on the physical volume mirror sub-group array to complete the disk allocation operation task.

[0071] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0072] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0073] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0074] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A disk allocation method based on a logical volume manager, characterized in that, include: In response to receiving a disk allocation request sent by the client corresponding to the target user, the metadata of the volume group corresponding to the disk allocation request is loaded to obtain the loaded metadata. The volume group represents the storage pool storing each physical volume. The loaded metadata includes a physical volume information set, and the physical volume information in the physical volume information set includes: a physical volume segment information set and physical volume tag information. The loaded metadata is parsed to generate a physical volume region object linked list and a physical volume tag set; The physical volume region object linked list is converted to a storage format to generate a physical volume region object array; Using the physical volume tag set, the physical volume region object array is mirrored and grouped to generate a physical volume mirror subgroup array; The physical volume image subgroup array is striped for allocation to complete the disk allocation operation. The step of parsing the loaded metadata to generate a physical volume region object linked list and a physical volume tag set includes: For each piece of physical volume information in the physical volume information set, perform the following processing steps: Based on the set of physical volume segment information included in the physical volume information, a set of physical volume region information is generated; Based on the physical volume region information set and the physical volume tag information included in the physical volume information, construct a physical volume region object set; Based on the collection of physical volume region objects constructed, construct a linked list of physical volume region objects; The physical volume tag information included in each physical volume information set is determined as the physical volume tag set.

2. The method according to claim 1, characterized in that, The step of constructing a physical volume region object set based on the physical volume region information set and the physical volume tag information included in the physical volume information includes: For each physical volume region in the physical volume region information set, perform the following construction steps: Using a preset memory allocation function, memory allocation is performed on the structure corresponding to the physical volume region information to obtain a memory allocation pointer; The memory allocation pointer is used to populate the structure with data to construct a physical volume region object; Each constructed physical volume region object is defined as a set of physical volume region objects.

3. The method according to claim 1, characterized in that, The physical volume segment information in the physical volume segment information set includes: occupancy identification information; The step of generating a physical volume region information set based on the physical volume segment information set included in the physical volume information includes: For each physical volume segment in the physical volume segment information set, in response to determining that the occupancy identifier information corresponding to the physical volume segment information indicates that the physical volume area is not occupied, the physical volume segment information is determined as available physical volume segment information; The identified available physical volume segment information is used to form a set of available physical volume segment information. Based on the set of available physical volume segment information, a set of physical volume region information is generated.

4. The method according to claim 1, characterized in that, The step of performing storage format conversion on the linked list of physical volume region objects to generate an array of physical volume region objects includes: The physical volume region objects included in the physical volume region object linked list are sorted to obtain a sorted physical volume region object linked list. The sorted physical volume region object linked list is converted to an array format to generate a physical volume region object array.

5. The method according to claim 1, characterized in that, The physical volume label set includes: a first physical volume label and a second physical volume label; The process of using the physical volume tag set to mirror and group the physical volume region object array to generate a physical volume mirror sub-group array includes: For each physical volume region object in the array of physical volume region objects, perform the following mirror subgroup generation steps: In response to the fact that the label corresponding to the physical volume region object is the same as the label of the first physical volume, the physical volume region object is determined as the first mirror sub-element of the mirror subgroup; In response to the fact that the label corresponding to the physical volume region object is the same as the label of the second physical volume, the physical volume region object in the array of physical volume region objects that meets the first preset label condition is determined as the first target physical volume region object, and the first target physical volume region object and the physical volume region object are swapped, and the first target physical volume region object after the swap is determined as the first mirror sub-element of the mirror sub-group; The physical volume region object in the array of physical volume region objects that is adjacent to the physical volume region object and located to the right of the physical volume region object is determined as the second target physical volume region object; In response to the fact that the label corresponding to the second target physical volume region object is the same as the label of the second physical volume, the second target physical volume region object is determined as the second mirror sub-element of the mirror sub-group; In response to the fact that the tag corresponding to the second target physical volume region object is the same as the tag of the first physical volume, the physical volume region object in the array of physical volume region objects that meets the second preset tag condition is determined as the third target physical volume region object, and the third target physical volume region object and the second target physical volume region object are swapped, and the third target physical volume region object after the swap is determined as the second mirror sub-element of the mirror sub-group. The mirror subgroup formed by the first mirror sub-element and the second mirror sub-element is determined as the mirror subgroup element; The array composed of the obtained image subgroup elements is determined as the physical volume image subgroup array.

6. A disk allocation device based on a logical volume manager, characterized in that, include: The loading processing unit is configured to, in response to receiving a disk allocation request sent by a client corresponding to a target user, load the metadata of the volume group corresponding to the disk allocation request to obtain the loaded metadata. The volume group represents a storage pool storing various physical volumes, and the loaded metadata includes a physical volume information set, in which the physical volume information set includes: a physical volume segment information set and physical volume tag information. The parsing processing unit is configured to parse the loaded metadata to generate a physical volume region object linked list and a physical volume tag set; wherein, the parsing processing of the loaded metadata to generate the physical volume region object linked list and the physical volume tag set includes: For each piece of physical volume information in the physical volume information set, perform the following processing steps: Based on the set of physical volume segment information included in the physical volume information, a set of physical volume region information is generated; Based on the physical volume region information set and the physical volume tag information included in the physical volume information, construct a physical volume region object set; Based on the collection of physical volume region objects constructed, construct a linked list of physical volume region objects; The physical volume tag information included in each physical volume information in the physical volume information set is determined as the physical volume tag set; The storage format conversion processing unit is configured to perform storage format conversion processing on the physical volume region object linked list to generate a physical volume region object array; The mirror grouping processing unit is configured to use the physical volume tag set to perform mirror grouping processing on the physical volume region object array to generate a physical volume mirror subgroup array; The stripe allocation processing unit is configured to perform stripe allocation processing on the physical volume image subgroup array to complete the disk allocation operation task.

7. An electronic device, characterized in that, include: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 5.

8. A computer-readable medium, characterized in that, It stores a computer program thereon, wherein the computer program, when executed by a processor, implements the method as described in any one of claims 1 to 5.

Images