Supports for reading/writing in parallel. The logic is naive when blocks are sufficient.
Using file writing as an example, when blocks are not enough, the file client would first write the first block of that write, or to the last block if there isn't any space left. This write takes two extra parameters:
Number of blocks to add
The starting name of the blocks
Given these two, the partition would act as a transfer station between the client and auto-scaling server. After the auto-scaling server finish adding the blocks, it would notify the partition the new blocks are ready and the partition would notify the client to run the following writes in parallel.
As for reads, we suppose that the file could not read exceed the file size(determined by the write with the max offset), so it would be safe to read in parallel directly since the file has sufficient blocks already.
Two new logic has been added to seek. If the client first seek to an offset outside the file size, then it performs a read, the read will fail. On the other hand, if a write is performed, the client would first allocated enough blocks to both reach the new offset and to have enough space to perform that write. This part of code re-uses the code above.
Handle_redirect in file_client and next_target_str in each file partition is no longer needed
Important assumption that one client edit the file at a time.
Removing file writer/reader since the implementation relies on the total file size to calculate how many more blocks are needed. We could still separate file writer and reader, but I need to make some changes, like if you seek to a big offset and then write some data, then we have to update the previous partitions' tail_ so that read won't stop at that point.
Remove useless members in file_block, simplify the serializer and deserializer for file
Simply file partition logic, totally remove next_targetstr related code
Add new file partition function: register_block, happens in file partition's constructor, ask the first partition its capacity and whether it uses auto_scaling. In this way, the users doesn't need to pass these arguments in the client constructor.
Changes provided in this PR:
Given these two, the partition would act as a transfer station between the client and auto-scaling server. After the auto-scaling server finish adding the blocks, it would notify the partition the new blocks are ready and the partition would notify the client to run the following writes in parallel.
As for reads, we suppose that the file could not read exceed the file size(determined by the write with the max offset), so it would be safe to read in parallel directly since the file has sufficient blocks already.
Two new logic has been added to seek. If the client first seek to an offset outside the file size, then it performs a read, the read will fail. On the other hand, if a write is performed, the client would first allocated enough blocks to both reach the new offset and to have enough space to perform that write. This part of code re-uses the code above.
Handle_redirect in file_client and next_target_str in each file partition is no longer needed
Important assumption that one client edit the file at a time.
Removing file writer/reader since the implementation relies on the total file size to calculate how many more blocks are needed. We could still separate file writer and reader, but I need to make some changes, like if you seek to a big offset and then write some data, then we have to update the previous partitions' tail_ so that read won't stop at that point.
Code tested, Stable