From 616fa4476f93e1782e68dc713e9e8cb77a426c7d Mon Sep 17 00:00:00 2001 From: Florian Klink Date: Thu, 11 May 2023 15:49:01 +0300 Subject: refactor(tvix/store): remove ChunkService Whether chunking is involved or not, is an implementation detail of each Blobstore. Consumers of a whole blob shouldn't need to worry about that. It currently is not visible in the gRPC interface either. It shouldn't bleed into everything. Let the BlobService trait provide `open_read` and `open_write` methods, which return handles providing io::Read or io::Write, and leave the details up to the implementation. This means, our custom BlobReader module can go away, and all the chunking bits in there, too. In the future, we might still want to add more chunking-aware syncing, but as a syncing strategy some stores can expose, not as a fundamental protocol component. This currently needs "SyncReadIntoAsyncRead", taken and vendored in from https://github.com/tokio-rs/tokio/pull/5669. It provides a AsyncRead for a sync Read, which is necessary to connect our (sync) BlobReader interface to a GRPC server implementation. As an alternative, we could also make the BlobReader itself async, and let consumers of the trait (EvalIO) deal with the async-ness, but this is less of a change for now. In terms of vendoring, I initially tried to move our tokio crate to these commits, but ended up in version incompatibilities, so let's vendor it in for now. Change-Id: I5969ebbc4c0e1ceece47981be3b9e7cfb3f59ad0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/8551 Tested-by: BuildkiteCI Reviewed-by: tazjin --- tvix/store/protos/rpc_blobstore.proto | 9 --------- 1 file changed, 9 deletions(-) (limited to 'tvix/store/protos/rpc_blobstore.proto') diff --git a/tvix/store/protos/rpc_blobstore.proto b/tvix/store/protos/rpc_blobstore.proto index c0665e821ae5..a7d48cf7709c 100644 --- a/tvix/store/protos/rpc_blobstore.proto +++ b/tvix/store/protos/rpc_blobstore.proto @@ -21,15 +21,6 @@ service BlobService { // The server may decide on whatever chunking it may seem fit as a size for // the individual BlobChunk sent in the response stream. // - // It specifically is NOT necessarily using chunk sizes communicated in a - // previous Stat request. - // - // It's up to the specific store to decide on whether it allows Read on a - // Blob at all, or only on smaller chunks communicated in a Stat() call - // first. - // - // Clients are enouraged to Stat() first, and then only read the individual - // chunks they don't have yet. rpc Read(ReadBlobRequest) returns (stream BlobChunk); // Put uploads a Blob, by reading a stream of bytes. -- cgit 1.4.1