On Thu, Jan 24, 2019 at 6:24 PM Julius Werner wrote:
> > What does that practically look like? Every time we have to re-walk we
> have to reverify the integrity of the metadata.
>
> I mean, that is exactly what we're doing right now anyway (unless
> something significantly changed in CBFS code
> What does that practically look like? Every time we have to re-walk we have
> to reverify the integrity of the metadata.
I mean, that is exactly what we're doing right now anyway (unless
something significantly changed in CBFS code since the last time I
checked). For every single CBFS file
On Wed, Jan 23, 2019 at 11:17 PM Zeh, Werner wrote:
> Currently with the one CBFS containing all files it is easy and simple to
> access every file in every stage.
> Wouldn't this be harder if we chose to split the CBFS into several,
> stand-alone CBFSes?
> Or, on the other hand, wouldn't we end
On Wed, Jan 23, 2019 at 4:00 PM Julius Werner wrote:
> > For 1, this is attempting to protect physical attack. Obviously this
> particular problem can't be solved in isolation, but it's something to
> think about.
>
> But isn't this something that per-file hashing would probably make
> easier to
Igor Pavlov (7z/LZMA SDK author) told me a few months ago that
> Decompression speed for lzma:
> lzma sdk 18.03 C code - about +120% speed increase from 4.42.
> lzma sdk 18.03 asm-x64 code - about +180% speed increase from 4.42.
Although he didn't mention any compression ratio changes, maybe
5 matches
Mail list logo
