package protos.grpc
Get desktop application:
View/edit binary Protocol Buffers messages
This service running on the chunkserver is used by the master to send control information to it. Such as checking the chunkserver heartbeat.
Used to check if the chunkserver is alive. The chunkserver sends an ok, and a reply. A reply shows that the server is alive.
optional request = 1
The original request associated with this reply.
Handles a TriggerReportChunkServer request by master. Usually the chunkserver reports itself to the master, but there are instances where the master needs to trigger/ask for the report itself. e.g. if the master crashed and restarting.
optional request = 1
The original request associated with this reply.
Advance the |chunk_version| of the specified |chunk_handle| by one on the receiving chunk server. This request is only sent by the master to all the chunk servers that hold the most up-to-date replica for the |chunk_handle|, *before* it grants a *new* lease for a write operation.
optional request = 1
The original request associated with this reply.
AdvanceFileChunkVersionReply.AdvanceFileChunkVersionStatus status = 2
uint32 chunk_version = 3
The chunk version on the chunk server after the reply If reply status is OK, this should match the `new_chunk_version` sent by the request. If reply status is failure, no version has been advanced on the chunk server, and this is the existing version for the requested chunk handle on the chunk server. This helps master to become aware of either itself or chunk server is out of sync
The primary chunk server bundles the write mutations and gives a serialization order. After the primary applies the mutations locally, it forwards these ordered mutations to secondary replicas via this gRPC.
optional request = 1
The original request associated with this reply.
FileChunkMutationStatus status = 2
The status of applying all mutations
Create an empty file chunk with |chunk_handle| at the chunk server. The chunk server returns error if |chunk_handle| already exists; otherwise a new file chunk with version 1 is initialized. This request is only sent by the master to the chunk server
optional request = 1
The original request associated with this reply.
InitFileChunkReply.InitFileChunkStatus status = 2
Read |chunk_handle| of known version |chunk_version| at |offset_start| for |length| number of bytes. Return the data and the actual number of bytes read, if the operation is successful; otherwise, return any error. The actual number of bytes read may be smaller than the number of bytes requested, if EOF has reached: |offset_start| + |length| > chunk size. If |offset_start| is larger than the chunk size, no bytes will be read
optional request = 1
The original request associated with this reply.
ReadFileChunkReply.ReadFileChunkStatus status = 2
bytes data = 3
The read data, if operation is successful
uint32 bytes_read = 4
The number of bytes that was actually read
BEFORE a write, the client pushes the data, identifiable by |checksum|, to all the replicas. A client can do so in any order. Each chunk server will store the data in an internal cache until the data is used or aged out. The chunk server doesn't care where this data will be written to in future, and finds out only from "ApplyMutations" gRPC sent by the primary replica. This design from GFS also makes writing redundant data to different chunks easy, by sending the data only once. Alternatively, a client can push it the closest replica and let the network forward the data to other replicas; however, we wont implement this for now
optional request = 1
The original request associated with this reply.
SendChunkDataReply.SendChunkDataRequestStatus status = 2
Write |length| number of bytes to |chunk_handle| of known version |chunk_version| at |offset_start|, using data previously sent by client, which is identified by the |checksum|. Return the actual number of bytes written (to memory), if the operation is successful; otherwise, any errors. The chunk server will expect that the client has already sent the |data| to all the secondary replicas; otherwise, the write operation will fail. For concurrent writes, chunk server will determine the serialization order. It guarantees the consistency of data across all replica, but the data is undefined if concurrent writes happened successfully. For overlapping regions between concurrent writes, either one of the write, or a mixture of the write data is applied (GFS paper Table 1). If the client wants data consistency and defined behavior, it should use external lock services. The actual number of bytes written can be smaller than requested |length|, if either EOF has reached, or the given |data| buffer is shorter than specified |length|. If |length| is smaller than the whole |data| buffer length, only the first |length| bytes of the |data| buffer will be written. If |offset_start| is larger than the chunk size, no bytes will be written This RPC is sent by a client to the primary chunk server AFTER the client acknowledges the receipt of data from all replicas. Upon receipt of this write request, the primary chunk server assigns consecutive serial numbers to all the write mutations it receives, possibly from multiple clients, which provides the necessary serialization. It applies the mutation to its own local state in serial number order, and then forwards the write request to all secondary replicas using "ApplyMutations" gRPC. Each secondary replica applies mutations in the same serial number order assigned by the primary. The secondaries all reply to the primary indicating that they have completed the operation, before the primary replies to the client.
optional request = 1
The original request associated with this reply.
uint32 bytes_written = 2
The number of bytes that was actually written
FileChunkMutationStatus status = 3
The final status of the write
repeated replica_status = 4
Grant a lease that expires at given |lease_expiration_time| for the given |chunk_handle| and |chunk_version| to the receiving chunk server. The receiving chunk server should ignore a grant request if the lease expiration is in the past. A master only grants the lease to a chunk server if the latter is chosen to be the primary replica for write operations of given time frame. As long as |chunk_handle| is being mutated, the primary can let the master know through HeartBeat messages, and receive lease extensions from the master indefinitely.
optional request = 1
The original request associated with this reply.
GrantLeaseReply.GrantLeaseStatus status = 2
Revoke the lease that was previously granted to the receiving chunk server and was supposed to expire at the |original_lease_expiration_time| for the given |chunk_handle|. The receiving chunk server should ignore a revoke request if it currently holds a lease that expires after the |original_lease_expiration_time| -- this avoids issues with delayed out-of-order message deliveries. A master usually revokes a lease in order to disable write mutations on the chunk server, during crucial master operations such as snapshotting or file renaming, etc.
optional request = 1
The original request associated with this reply.
RevokeLeaseReply.RevokeLeaseStatus status = 2
This is a service that runs on the master server that handles master coordination with chunk servers. This is different from the heartbeat service which is used to send light messages to check the health of the chunkserver. We use this to keep the chunkserver manager in sync with the chunkservers.
Each chunkserver periodically reports the chunks it has, and the master replies with the identity of all chunks that are no longer present in the master’s metadata, as well as the reported chunks with stale version. Chunkserver can have stale version for a chunk if it crash and miss some mutations on the chunk. Once the chunkserver receives the reply, it is free to delete its replicas of such chunks. The master also uses this to update itself on the location of each chunk. Chunkserver has the final word over what chunks it does or does not have on its own disks. Because errors on a chunkserver may cause chunks to vanish spontaneously. This chunkserver report call will be less frequent compared to the heartbeat call (which is used to see if the chunkserver is still running), due to the potential size of the messages. Since there can be a very large number of chunks on each chunkserver. Also, after the initial report during chunkserver/master startup the info on the chunkservermgr and chunkserver ideally shouldn't differ much very often.
optional request = 1
The original request associated with this reply.
repeated string stale_chunk_handles = 2
The chunks reported by the chunkserver that the master considers to be stale. This allows the chunkserver to delete them.
Delete |filename|. This effectively deletes all associated file chunks. If |filename| doesn't exist yet, an error status is returned.
message
master_metadata_service.proto:64string filename = 1
Absolute file name or directory name
Return the chunk handle, version, and associated replica locations for a given |filename| at |chunk_index|. For |APPEND| mode, |chunk_index| is not required, ignored if specified, because the master will decide which chunk handle the client should write to for the append operation; if no concurrent append exists, this is guaranteed to be the chunk handle for the last chunk index. If either |filename| or |chunk_index| doesn't exist, an error status with empty reply is returned if |create_if_not_exists| is false; otherwise, the master will create the chunk, and initialize its creation on all chunk servers, before returning to client. If chunk creation fails, the open operation is considered to have failed. The master does not enforce or guarantee a |filename| will always have continuous |chunk_index|. Fragmentation and missing intermediate chunks may exist if client forgets, or fails, to create an intermediate |chunk_index|. In this case, it is up to the client to retry, when applicable.
message
master_metadata_service.proto:57optional request = 1
The original request associated with this reply.
optional metadata = 2
The metadata for the requested file chunk.
The status of file chunk version update operation
Used in:
UNKNOWN = 0
OK = 1
FAILED_NOT_FOUND = 2
FAILED_VERSION_OUT_OF_SYNC = 3
Used as request type in: ChunkServerFileService.AdvanceFileChunkVersion
Used as field type in:
string chunk_handle = 1
An immutable and globally unique UUID chunk identifier.
uint32 new_chunk_version = 2
The expected chunk version after version advance.
Used as request type in: ChunkServerFileService.ApplyMutations
Used as field type in:
repeated headers = 1
Serialized/ordered concurrent write mutations to apply
Empty request for now. We can use this to pass the deleted chunks list to the chunkserver.
Used as request type in: ChunkServerControlService.CheckHeartBeat
Used as field type in:
(message has no fields)
Used in: , ,
UNKNOWN = 0
OK = 1
FAILED_DATA_NOT_FOUND = 2
Data with given |data_checksum| either doesn't exist, or has expired, in the data cache; client needs to resend the data using SendDataRequest
FAILED_CHUNK_NOT_FOUND = 3
No given chunk handle is found.
FAILED_STALE_VERSION = 4
Failed to apply mutation because replica has a stale chunk
FAILED_NOT_LEASE_HOLDER = 5
This only applies if a client tries to send a WriteRequest to a secondary replica; it'll not error when ApplyMutationRequests are sent by the primary
FAILED_OUT_OF_RANGE = 6
Failed because the write start offset is outside the allowed range
The lease acceptance status by the chunk server
Used in:
UNKNOWN = 0
ACCEPTED = 1
The chunk server accepts the new lease
IGNORED_EXPIRED_LEASE = 2
Request is ignored because it's already expired when received
REJECTED_NOT_FOUND = 3
Request is rejected because chunk server doesn't have this chunk handle
REJECTED_STALE_VERSION = 4
Request is rejected because chunk server has a stale version of the chunk
Used as request type in: ChunkServerLeaseService.GrantLease
Used as field type in:
string chunk_handle = 1
An immutable and globally unique UUID chunk identifier.
uint32 chunk_version = 2
The chunk version number for the chunk handle associated with this lease. The master usually increases the chunk version number immediately *before* it grants a *new* lease on a chunk. For lease extensions, the master doesn't need to increase the chunk version. A chunk server should not accept the lease if it has a stale chunk version.
optional lease_expiration_time = 3
The time that this granted lease expires By default, the lease expires 60 seconds after the master issued the lease grant/extension, so this is the absolute UNIX time when the lease is no longer valid, at master's NOW() + 60 seconds upon grant. Use seconds field for UNIX seconds. nanos will be ignored
The status of file chunk creation operation
Used in:
UNKNOWN = 0
CREATED = 1
ALREADY_EXISTS = 2
Used as request type in: ChunkServerFileService.InitFileChunk
Used as field type in:
string chunk_handle = 1
An immutable and globally unique UUID chunk identifier.
message
master_metadata_service.proto:36Used as request type in: MasterMetadataService.OpenFile
Used as field type in:
string filename = 1
Absolute file name or directory name
uint32 chunk_index = 2
A chunk index is |byte_range / chunk block size|. By default, the block size of a chunk is 64MB. This is not required, and ignored, for |APPEND| mode.
OpenFileRequest.OpenMode mode = 3
bool create_if_not_exists = 4
Create the file chunk, if it doesn't exist. This is only valid for WRITE mode
Open modes
Used in:
UNKNOWN = 0
READ = 1
WRITE = 2
CREATE = 3
APPEND = 4
The status of file chunk read operation
Used in:
UNKNOWN = 0
OK = 1
FAILED_NOT_FOUND = 2
FAILED_VERSION_OUT_OF_SYNC = 3
FAILED_OUT_OF_RANGE = 4
Used as request type in: ChunkServerFileService.ReadFileChunk
Used as field type in:
string chunk_handle = 1
An immutable and globally unique UUID chunk identifier.
uint32 chunk_version = 2
The version of the file chunk that the requester is trying to read If the chunk server has a stale version compared to what was requested, chunk server will return an error, and ask the client to send the request to another chunk server that has the most up-to-date version.
uint32 offset_start = 3
The starting offset at which to start reading data from
uint32 length = 4
The number of bytes to read
TODO(bmokutub): Chunkserver type has list of handles, and we are using stored_chunks here again for handle to version mapping.
Used as request type in: MasterChunkServerManagerService.ReportChunkServer
Used as field type in:
optional chunk_server = 1
The chunkserver making this request.
repeated stored_chunks = 2
All the chunks stored on the chunkserver.
The lease revoke status by the chunk server
Used in:
UNKNOWN = 0
REVOKED = 1
The chunk server has revoked its holding lease
IGNORED_HAS_NEWER_LEASE = 2
Revoke is ignored because chunk server has a newer lease
REJECTED_NOT_FOUND = 3
Request is rejected because chunk server doesn't have this chunk handle
Used as request type in: ChunkServerLeaseService.RevokeLease
Used as field type in:
string chunk_handle = 1
An immutable and globally unique UUID chunk identifier.
optional original_lease_expiration_time = 2
The original time that the revoked lease was supposed to expire
Used in:
UNKNOWN = 0
OK = 1
RATE_LIMITED = 2
not used, but as an example of what we can have
DATA_TOO_BIG = 3
data is bigger than allowed GFS file chunk block size
BAD_DATA = 4
checksum for data sent doesn't match the calculated checksum
FAILED = 5
Used as request type in: ChunkServerFileService.SendChunkData
Used as field type in:
bytes data = 1
The data that the client wants the chunk server to store
bytes checksum = 2
The checksum for uniquely identifying this data across requests, so future requests don't need to resend the data, unless the data expired.
Empty request for now.
Used as request type in: ChunkServerControlService.TriggerReportChunkServer
Used as field type in:
(message has no fields)
The specific statuses returned from all replicas If the write fails at the primary before the write request is forwarded toe the clients, this field will be empty.
Used in:
optional chunk_server_location = 1
FileChunkMutationStatus status = 2
Used as request type in: ChunkServerFileService.WriteFileChunk
Used as field type in:
optional header = 1
The write header for this write request
repeated replica_locations = 2
The replicas that the client has already sent the data to, so the primary chunk server knows who to forward the serialized concurrent writes to.
Used in: ,
string chunk_handle = 1
An immutable and globally unique UUID chunk identifier.
uint32 chunk_version = 2
The version of the file chunk that the requester is trying to write
uint32 offset_start = 3
The starting offset at which to start writing data to
uint32 length = 4
The number of bytes to write
bytes data_checksum = 5
The checksum for uniquely identifying the data previously sent to all replicas already via SendChunkData gRPC.