> On May 27, 2015, 4:10 p.m., Paul Brett wrote: > > src/slave/containerizer/provisioners/appc/store.cpp, line 267 > > <https://reviews.apache.org/r/34140/diff/1/?file=957277#file957277line267> > > > > Why not do the decompress, hash & untar as a pipeline to reduce disk > > usage? > > Ian Downes wrote: > Because we need to hash the (decrypted (uncompressed)) tarball, i.e., an > intermediate object, and because we don't know how it is compressed.
It may take more effort but I think it can be done so maybe this is what we should eventually do? 1) detecting the encryption and compression type up front. 2) `tee` the decompression output to do the hash and write it to a file. For bigger images I do think the saves both temporary disk space as well as reduce latency (less disk writes). Thoughts? - Jiang Yan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34140/#review85456 ----------------------------------------------------------- On July 7, 2015, 12:43 p.m., Ian Downes wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34140/ > ----------------------------------------------------------- > > (Updated July 7, 2015, 12:43 p.m.) > > > Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone. > > > Repository: mesos > > > Description > ------- > > Images are fetched into the store (after discovery). Stored images are > currently kept indefinitely. > > > Diffs > ----- > > src/Makefile.am e7de0f3d1a5efeaef47d5074defe3b40db94f573 > src/slave/containerizer/provisioners/appc/store.hpp PRE-CREATION > src/slave/containerizer/provisioners/appc/store.cpp PRE-CREATION > src/slave/flags.hpp 7634e368c72e83932dcd992d78eaca146326606b > src/slave/flags.cpp cbf431eb0627bdaf07241cc0fc4630df06fb20e2 > > Diff: https://reviews.apache.org/r/34140/diff/ > > > Testing > ------- > > > Thanks, > > Ian Downes > >
