A method and device for concurrent read and write of a distributed block device

Abstract

The present application discloses a method and apparatus for concurrent reading and writing of a distributed block device, including: pre-configuring several locks with different functions associated with a volume, any one of the locks being configured to describe the operation state of the volume; and pre-dividing the logical space of the volume into several sub-blocks according to a set size, and configuring multiple sub-block identifiers for each sub-block, the sub-block identifiers being used to describe the read-write state of the sub-block; a block location BCS service is arranged at a backend node of the distributed block device, and in the case where multiple clients need to read and write the same volume, the BCS service and multiple clients are used to perform interactions based on the sub-block identifiers to complete the reading and writing of the volume. The solution of the present application uses the designed smp_lock to achieve the consistency of metadata caches of different clients, thereby improving the concurrent request capability of the distributed block device.

Description

Technical Field

[0001] This application relates to the field of distributed storage technology, and in particular, to a method and device for concurrent reading and writing of a distributed block device. Background Art

[0002] In distributed block storage, generally multiple client nodes open and operate the same block device simultaneously. The block device consists of a front end (client) + a back end. Except for operations such as scaling, creating, deleting snapshots, or modifying other attributes of the block device, although they modify different metadata, these operations need to be sent to a certain owner client of the volume for execution. This not only fails to process different requests concurrently but also concentrates the pressure on a single node to a certain extent, including IO reading and writing.

[0003] Currently, mainstream distributed block devices require clients to ensure the mutual exclusion and synchronization of operations, resulting in the need for cross-network client nodes to perceive and synchronize with each other. This not only limits the usage scenarios, increases the difficulty of using the block device, but also restricts the IO concurrency of multiple clients. Summary of the Invention

[0004] Embodiments of this application provide a method and device for concurrent reading and writing of a distributed block device to improve the concurrent request ability of the distributed block device.

[0005] Embodiments of this application provide a method for concurrent reading and writing of a distributed block device, including:

[0006] Pre-configure several locks with different functions associated with the volume, and any lock is configured to describe the operation state of the volume; and

[0007] Pre-divide the logical space of the volume into several sub-blocks according to a set size, and configure multiple sub-block identifiers for each sub-block, where the sub-block identifiers are used to describe the read and write states of the sub-blocks;

[0008] A block location BCS service is arranged at a back-end node of the distributed block device. In the case where multiple clients need to read and write the same volume, the BCS service and multiple clients are used to perform interactions based on the sub-block identifiers to complete the reading and writing of the volume.

[0009] Optionally, the several locks with different functions pre-configured and associated with the volume include:

[0010] A specification lock size_lock, associated with the size of the volume, which is configured to read the size_lock when querying the volume and write the size_lock when scaling;

[0011] A volume name lock named name_lock, which is associated with the name of the volume and is configured to read the name_lock when querying the volume and write the name_lock when renaming;

[0012] A snapshot lock named snap_lock, which is associated with the snapshot of the volume;

[0013] A migration lock named migrate_lock, which is associated with the migration of the volume;

[0014] Each lock has three stable states: LOCK (locked), SYNC (synchronized), and EXCL (exclusive), and these states can be switched between each other;

[0015] The method further includes configuring the permissions of the client for the corresponding volume based on any one of the locks.

[0016] Optionally, it further includes configuring a block identifier IO_Map for any one of the distributed block devices;

[0017] The sub-block identifier IO_Map configured for each sub-block at least includes:

[0018] A sub-block status identifier Stat[id], which has a specified identifier value to indicate the read / write status of the sub-block;

[0019] A sub-block details identifier Slice_Info, which has the following structure:

[0020] A read / write sub-identifier Slice_Info.runing, which represents the client that is currently reading or writing the slice;

[0021] A waiting sub-identifier Slice_Info.wait, which represents the waiting client.

[0022] Optionally, in the case where multiple clients need to read and write the same volume, using the BCS service and multiple clients, based on the sub-block identifier, the interaction includes:

[0023] Using the BCS service to record the basic information of each client to complete the initialization;

[0024] Obtaining the read / write requests of the clients, and updating the block identifier IO_Map and the sub-block details identifier Slice_Info corresponding to the read / write requests of the clients to complete the read / write operations of each client.

[0025] Optionally, obtaining the read / write requests of the clients, and updating the block identifier IO_Map and the sub-block details identifier Slice_Info corresponding to the read / write requests of the clients to complete the read / write operations of each client includes:

[0026] In the case where a read / write request spans at least two sub-blocks, use the BCS service to update the corresponding IO_Map, Slice_Info, Slice_Info.runing, and Slice_Info.wait, so as to sequentially execute the read / write requests of multiple clients.

[0027] This application also proposes a distributed block device concurrent read / write device, including a processor, which is configured to:

[0028] Pre-configure several locks with different functions associated with the volume, and any lock is configured to describe the operation state of the volume; and

[0029] Pre-divide the logical space of the volume into several sub-blocks according to a set size, and configure multiple sub-block identifiers for each sub-block, where the sub-block identifiers are used to describe the read / write state of the sub-block;

[0030] A block location BCS service is arranged at at least one backend node of the distributed block device. In the case where multiple clients need to read / write the same volume, use the BCS service and multiple clients to perform interactions based on the sub-block identifiers to complete the read / write of the volume.

[0031] Optionally, the several locks with different functions pre-configured and associated with the volume include:

[0032] A specification lock size_lock, associated with the size of the volume, which is configured to read the size_lock when querying the volume and write the size_lock when scaling the volume;

[0033] A volume name lock name_lock, associated with the name of the volume, which is configured to read the name_lock when querying the volume and write the name_lock when renaming the volume;

[0034] A snapshot lock snap_lock, associated with the snapshot of the volume;

[0035] A migration lock migrate_lock, associated with the migration of the volume;

[0036] Each lock has three stable states: LOCK, SYNC, and EXCL, and the states can be switched between each other;

[0037] The processor is further configured to: configure the permissions of the client corresponding to the volume based on any lock.

[0038] Optionally, the processor is further configured to configure a block identifier IO_Map for any distributed block device;

[0039] The sub-block identifier IO_Map configured for each sub-block at least includes:

[0040] Sub-block status identifier Stat[id], having a specified identifier value to indicate the read / write status of the sub-block;

[0041] Sub-block details identifier Slice_Info, which has the following structure:

[0042] Read / write sub-identifier Slice_Info.runing, indicating the client that is reading / writing the slice;

[0043] Wait sub-identifier Slice_Info.wait, indicating the waiting client.

[0044] Optionally, in the case where multiple clients need to read / write the same volume, the processor is further configured to:

[0045] Use the BCS service to record the basic information of each client to complete initialization;

[0046] Obtain the read / write requests of the clients, and update the sub-block identifier IO_Map and the sub-block details identifier Slice_Info corresponding to the read / write requests of the clients to complete the read / write operations of each client.

[0047] Optionally, the processor is further configured to:

[0048] In the case where the read / write requests span at least two sub-blocks, use the BCS service to update the corresponding IO_Map, Slice_Info, Slice_Info.runing, and Slice_Info.wait to sequentially execute the read / write requests of multiple clients.

[0049] The embodiments of the present application target the different operations of the volume and the characteristics of the metadata, narrow the mutual exclusion interval, no longer use the entire volume as the lock granularity, and use the designed smp_lock to achieve the consistency of the metadata caches of different clients, thereby improving the concurrent request ability of the distributed block device.

[0050] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features, and advantages of the present application more obvious and understandable, the specific embodiments of the present application are specifically given below. Brief Description of the Drawings

[0051] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the following detailed description of the preferred embodiments. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present application. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0052] Figure 1 is the basic flowchart of the concurrent read and write method of the embodiment of the present application;

[0053] Figure 2 is an example of the lock switching process and the lock state of the embodiment of the present application;

[0054] Figure 3 is an example of a structure of the IO_Map of the embodiment of the present application;

[0055] Figure 4 is a schematic diagram of the concurrent read and write process of three block storage clients of the embodiment of the present application. Detailed Embodiments

[0056] Hereinafter, exemplary embodiments of the present disclosure will be described in more detail with reference to the drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be fully conveyed to those skilled in the art.

[0057] The embodiment of the present application provides a distributed block device concurrent read and write method, as Figure 1 shown, including:

[0058] In step S101, several locks with different functions associated with the volume are preconfigured, and any lock is configured to describe the operation state of the volume. In some embodiments, the several locks with different functions associated with the volume (smp_lock lock design) preconfigured include:

[0059] A specification lock size_lock, associated with the size of the volume, which is configured to read the size_lock when querying the volume and write the size_lock when scaling the volume;

[0060] A volume name lock name_lock, associated with the name of the volume, which is configured to read the name_lock when querying the volume and write the name_lock when renaming the volume;

[0061] A snapshot lock snap_lock, associated with the snapshot of the volume;

[0062] A migration lock migrate_lock, associated with the migration of the volume;

[0063] As Figure 2 shown, each lock has three stable states: LOCK, SYNC, and EXCL, and the states can be switched between each other. An intermediate state can be used to represent a lock during the switching process. The specific switching process and the states of the lock are shown in Table 1:

[0064] Table 1

[0065]

[0066]

[0067] Among them:

[0068] lock_stat: Represents the name of the lock state.

[0069] next_stat: Represents the next state. 0 indicates that the current state is a steady state.

[0070] rep_stat: Represents the state of the replica.

[0071] can_read: Represents which clients can read.

[0072] can_rdlock: Represents which clients can add a read lock. When a read lock is added to a certain resource, an exclusive lock and a write lock cannot be added anymore.

[0073] can_wrlock: Represents which clients can add a write lock.

[0074] can_xlock: Represents which clients can add an exclusive lock. Only the client that owns the lock is allowed to operate.

[0075] ANY: Represents any client that owns the resource.

[0076] AUTH: Represents an authorized client.

[0077] XCL: Represents a client for exclusive execution.

[0078] The method further includes configuring the permissions of the client for the corresponding volume based on any lock.

[0079] Specifically, for example: There are 3 block device clients C1, C2, and C3. They all cache the size (metadata) of a certain volume, and the states of C1: size_lock, C2: size_lock, and C3: size_lock are all LOCK_SYNC, and AUTH is C1. At a certain moment, C2 wants to read the size. From the above table, it can be seen that all replicas are LOCK_SYNC, and all clients can read and add a read lock.

[0080] The logical space of the volume is pre-divided into several sub-blocks according to a set size, and multiple sub-block identifiers are configured for each sub-block, and the sub-block identifiers are used to describe the read / write status of the sub-blocks.

[0081] In some embodiments, it further includes configuring a block identifier IO_Map for any distributed block device; the sub-block identifiers configured for each sub-block at least include:

[0082] A sub-block status identifier Stat[id], which has a specified identifier value to indicate the read / write status of the sub-block;

[0083] A sub-block details identifier Slice_Info, which has the following structure:

[0084] A read / write sub-identifier Slice_Info.runing, which represents the client that is reading / writing the slice;

[0085] A waiting sub-identifier Slice_Info.wait, which represents the waiting client.

[0086] In this example, the SGIO_Lock lock design is further introduced. In this example, the SGIO_Lock is granularity-based on different intervals, enabling different clients to concurrently issue IO requests. Upper-layer users no longer need to spend a lot of effort on synchronization when using different clients. Specifically, it includes:

[0087] Configuring a block identifier IO_Map for any distributed block device

[0088] The logical space of the volume is default-divided into 1 sub-block slice according to 1MB size. For example, the status of each slice is represented by 2 bits, 0: clean, can be read / written, 1: being read, 2: being written. That is, the status corresponding to the slice is Stat[id], and id is the logical order of the slice. For example, for the intervals [1M, 2M), [1.5M, 1.9M], the id is 1. One IO may span multiple slices. For example, the intervals [1.5M, 2.5M] correspond to Stat[1], Stat[2].

[0089] Such as Figure 3As shown in the figure, in order to record the operation details of the slice, the structure Slice_Info is defined. Among them, Slice_Info.runing represents the client that is currently reading and writing the slice. Normally, multiple clients can read, and 1 client can write. Slice_Info.wait represents the waiting clients. For example, for a slice that is being read, when a write request arrives, it will be placed in wait. Job.c represents which client. Job.t represents the IO type, read or write. In this example, an IO_Map is designed for a block device, and the IO_Map contains the Slice_Info of all sub-blocks. The Slice_Info of the operating slice can be queried through IO_Map[idx]. For example, the sub-block slice id of the data from 0 to 1M is 0, and its Slice_Info can be obtained through: IO_Map[0].

[0090] In step S102, a block location BCS service is arranged on at least one backend node of the distributed block device. When multiple clients need to read and write the same volume, the BCS service is used to interact with multiple clients based on the sub-block identifier to complete the reading and writing of the volume.

[0091] In the embodiment of the present application, aiming at the different operations of the volume and the characteristics of the metadata, the mutually exclusive interval is reduced. Instead of using the entire volume as the lock granularity, the smp_lock design is relied on to achieve the consistency of the metadata caches of different clients.

[0092] In some embodiments, when multiple clients need to read and write the same volume, using the BCS service to interact with multiple clients based on the sub-block identifier includes:

[0093] Using the BCS service to record the basic information of each client to complete the initialization;

[0094] Obtaining the read and write requests of the client, and updating the block identifier IO_Map and the sub-block detail identifier Slice_Info corresponding to the read and write requests of the client to complete the read and write operations of each client.

[0095] In some embodiments, obtaining the read and write requests of the client, and updating the block identifier IO_Map and the sub-block detail identifier Slice_Info corresponding to the read and write requests of the client to complete the read and write operations of each client includes:

[0096] When the read and write requests span at least two sub-blocks, using the BCS service to update the corresponding IO_Map, Slice_Info, Slice_Info.runing, and Slice_Info.wait to sequentially execute the read and write requests of multiple clients.

[0097] Specifically, as Figure 4 shown, in this example, there are three block storage clients (front-ends) (C1, C2, C3) that need to read and write to the same volume. There is one node in the cluster that deploys the BCS (Block Coordinate Service) service, which is responsible for coordinating the concurrent IO requests of the clients. The following steps can be used to achieve this:

[0098] a. When the clients (C1, C2, C3) connect to the storage cluster and initialize, they need to interact with the BCS service to let it record the basic information of the clients.

[0099] b. Client C1 expects to read [0, 2M). The BCS receives the request and finds that Stat[0] and Stat[1] are 0, indicating that it is readable and writable. It updates Stat[0] = 1, Stat[1] = 1, and IO_Map[1]. After C1 receives the BCS reply, it sends a read request to the storage backend.

[0100] c. Client C2 expects to read [1M, 3M). Since it spans two slices and their states are Stat[1] = 1 and Stat[2] = 0 respectively, it can be read. Then Stat[2] is updated to 1, and IO_Map[1] and IO_Map[2] are updated. In the running list of Slice_Info of the former, there are C1 and C2. After C2 receives the BCS reply, it sends a read request to the storage backend.

[0101] d. After operation b is completed, C1 finishes reading [0, 2M) and sends a task completion message to the BCS. It queries the corresponding Slice_Info. All the running clients have completed. Update IO_Map[1]: among the running clients, only C2 remains, Stat[1] is still 1, IO_Map[0]: the running clients are empty, and Stat[0] is 0

[0102] e. Client C3 expects to write [0, 2M). The BCS receives the request and queries the status of the corresponding slice. Stat[0] is 0, which meets the requirement. Update Stat[0] to 2 and update IO_Map[0]. Since Stat[1] is 1 and client C2 is still reading [1M, 2M), C3 cannot write this slice temporarily. Update IO_Map[1]: add C3 to the waiting list, with client_id as C3 and type as write. The BCS replies to C3.

[0103] Operation c is completed, and the reading of [1M, 3M) by C2 is completed. The running client in the updated IO_Map[1] is empty, but there is C3 in the waiting list with the type of write. Then, C3 is removed from the waiting list, added to the running client, and Stat[1] is updated to 2. C3 is notified that it can issue a write request for [1M, 2M).

[0104] The solution of the present application refines the granularity of the lock, enables the modification of metadata to be executed on different nodes through lock switching, and coordinates the IO requests of different volume intervals of different clients through the BCS service, thereby effectively improving the concurrent request ability of the distributed block device.

[0105] The present application also proposes a distributed block device concurrent read and write device, including a processor, which is configured to:

[0106] Pre-configure several locks with different functions associated with the volume, and any lock is configured to describe the operation state of the volume; and

[0107] Pre-divide the logical space of the volume into several sub-blocks according to a set size, and configure multiple sub-block identifiers for each sub-block, and the sub-block identifiers are used to describe the read and write states of the sub-blocks;

[0108] A block location BCS service is arranged at at least one backend node of the distributed block device. In the case where multiple clients need to read and write the same volume, the BCS service is used to interact with multiple clients based on the sub-block identifiers to complete the reading and writing of the volume.

[0109] In some embodiments, the several locks with different functions pre-configured and associated with the volume include:

[0110] A specification lock size_lock, associated with the size of the volume, which is configured to read the size_lock when querying the volume and write the size_lock when scaling;

[0111] A volume name lock name_lock, associated with the name of the volume, which is configured to read the name_lock when querying the volume and write the name_lock when renaming;

[0112] A snapshot lock snap_lock, associated with the snapshot of the volume;

[0113] A migration lock migrate_lock, associated with the migration of the volume;

[0114] Each lock has three stable states: LOCK, SYNC, and EXCL, and the states can be switched between each other;

[0115] The processor is further configured to: configure the permissions corresponding to the volume for the client based on any lock.

[0116] In some embodiments, the processor is further configured to configure a block identification IO_Map for any distributed block device;

[0117] The sub-block identification IO_Map configured for each sub-block at least includes:

[0118] Sub-block status identification Stat[id], having a specified identification value to indicate the read / write status of the sub-block;

[0119] Sub-block details identification Slice_Info, which has the following structure:

[0120] Read / write sub-identification Slice_Info.runing, indicating the client that is reading / writing the slice;

[0121] Wait sub-identification Slice_Info.wait, indicating the waiting client.

[0122] In some embodiments, when multiple clients need to read and write the same volume, the processor is further configured to:

[0123] Use the BCS service to record the basic information of each client to complete initialization;

[0124] Obtain the read / write requests of the clients, and update the sub-block identification IO_Map and the sub-block details identification Slice_Info corresponding to the read / write requests of the clients to complete the read / write operations of each client.

[0125] In some embodiments, the processor is further configured to:

[0126] When the read / write request spans at least two sub-blocks, use the BCS service to update the corresponding IO_Map, Slice_Info, Slice_Info.runing, and Slice_Info.wait to sequentially execute the read / write requests of multiple clients.

[0127] In the embodiments of the present application, according to the characteristics of different operations on the volume and metadata, the mutual exclusion interval is reduced, and the entire volume is no longer used as the lock granularity. The consistency of the metadata caches of different clients is realized by relying on the designed simple_lock, thereby improving the concurrent request ability of the distributed block device.

[0128] It should be noted that in this text, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article or device. Without further limitations, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including such element.

[0129] The serial numbers of the embodiments of the present application above are only for description and do not represent the superiority or inferiority of the embodiments.

[0130] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions for causing a terminal (which can be a mobile phone, computer, server or network device, etc.) to execute the methods described in the various embodiments of the present application.

[0131] The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Those of ordinary skill in the art, under the inspiration of the present application and without departing from the purpose of the present application and the scope protected by the claims, can also make many forms, and all of these fall within the protection scope of the present application.

Claims

1. A method for concurrent read and write of a distributed block device, characterized in that, it includes: Pre-configure several locks with different functions associated with the volume, and any lock is configured to describe the operation state of the volume; And Pre-divide the logical space of the volume into several sub-blocks according to a set size, and configure multiple sub-block identifiers for each sub-block, and the sub-block identifiers are used to describe the read and write states of the sub-blocks; A block location BCS service is arranged at a backend node of the distributed block device. When multiple clients need to read and write the same volume, use the BCS service and multiple clients to perform interactions based on the sub-block identifiers to complete the read and write of the volume; The several pre-configured locks associated with the volume include: A specification lock size_lock, associated with the size of the volume, which is configured to read the size_lock when querying the volume and write the size_lock when scaling; A volume name lock name_lock, associated with the name of the volume, which is configured to read the name_lock when querying the volume and write the name_lock when renaming; A snapshot lock snap_lock, associated with the snapshot of the volume; A migration lock migrate_lock, associated with the migration of the volume; Each lock has three stable states: LOCK, SYNC, and EXCL, and the states can be switched between each other; The method further includes configuring the permissions of the client for the corresponding volume based on any lock.

2. The method for concurrent read and write of a distributed block device according to claim 1, characterized in that, it further includes configuring a block identifier IO_Map for any distributed block device; The sub-block identifiers configured for each sub-block at least include: A sub-block status identifier Stat[id], having a specified identifier value to indicate the read and write state of the sub-block; A sub-block detail identifier Slice_Info, which has the following structure: A read and write sub-identifier Slice_Info.runing, indicating the client that is reading and writing the corresponding slice; A waiting sub-identifier Slice_Info.wait, indicating the waiting client.

3. The method for concurrent read and write of a distributed block device according to claim 2, characterized in that, When multiple clients need to read and write the same volume, using the BCS service and multiple clients to perform interactions based on the sub-block identifiers includes: Using the BCS service to record the basic information of each client to complete initialization; Obtain the read and write requests of the clients, and update the block identifier IO_Map and the sub-block detail identifier Slice_Info corresponding to the read and write requests of the clients to complete the read and write operations of each client.

4. The method for concurrent read and write of a distributed block device according to claim 3, characterized in that, Obtaining the read and write requests of the clients, and updating the block identifier IO_Map and the sub-block detail identifier Slice_Info corresponding to the read and write requests of the clients to complete the read and write operations of each client includes: In the case where a read / write request spans at least two sub-blocks, use the BCS service to update the corresponding IO_Map, Slice_Info, Slice_Info.runing, and Slice_Info.wait, so as to sequentially execute the read / write requests of multiple clients.

5. A distributed block device concurrent read / write device, characterized in that, it includes a processor, which is configured to: pre-configure several locks with different functions associated with a volume, and any lock is configured to describe the operation state of the volume; and pre-divide the logical space of the volume into several sub-blocks according to a set size, and configure multiple sub-block identifiers for each sub-block, and the sub-block identifiers are used to describe the read / write state of the sub-block; a block positioning BCS service is arranged at at least one backend node of the distributed block device. In the case where multiple clients need to read / write the same volume, use the BCS service and multiple clients to perform interactions based on the sub-block identifiers to complete the read / write of the volume; the several pre-configured locks associated with the volume include: a specification lock size_lock, associated with the size of the volume, which is configured to read the size_lock when querying the volume and write the size_lock when scaling the volume; a volume name lock name_lock, associated with the name of the volume, which is configured to read the name_lock when querying the volume and write the name_lock when renaming the volume; a snapshot lock snap_lock, associated with the snapshot of the volume; a migration lock migrate_lock, associated with the migration of the volume; each lock has three stable states: LOCK, SYNC, and EXCL, and the states can be switched between each other; the processor is further configured to: configure the permissions of the client for the corresponding volume based on any lock.

6. The distributed block device concurrent read / write device according to claim 5, characterized in that, the processor is further configured to configure a block identifier IO_Map for any distributed block device; the sub-block identifier IO_Map configured for each sub-block at least includes: a sub-block status identifier Stat[id], having a specified identifier value to indicate the read / write state of the sub-block; a sub-block details identifier Slice_Info, which has the following structure: a read / write sub-identifier Slice_Info.runing, indicating the client that is reading / writing the corresponding slice; a waiting sub-identifier Slice_Info.wait, indicating the waiting client.

7. The distributed block device concurrent read / write device according to claim 6, characterized in that, in the case where multiple clients need to read / write the same volume, the processor is further configured to: use the BCS service to record the basic information of each client to complete initialization; obtain the read / write requests of the clients, and update the sub-block identifier IO_Map and the sub-block details identifier Slice_Info of the sub-block corresponding to the read / write requests of the clients to complete the read / write operations of each client.

8. The concurrent read / write device for a distributed block device according to claim 7, wherein, the processor is further configured to: in the case where a read / write request spans at least two sub-blocks, use the BCS service to update the corresponding IO_Map, Slice_Info, Slice_Info.runing, and Slice_Info.wait, so as to sequentially execute the read / write requests of multiple clients.

Images