On Jul 10 2020, Daniel Jagszent <dan...@jagszent.de> wrote:
>> Ah yes, compression and probably encryption will indeed preclude any
>> sort of partial block caching. An implementation will have to be
>> limited to plain uncompressed blocks, which is okay for my use-case
>> though (borg provides its own encryption and compression anyway).
>> [...]
> Compression and encryption are integral parts of S3QL and I would argue
> that disabling them is only an edge case.
If I were to write S3QL from scratch, I would probably not support this
at all, right. However, since the feature is present, I think we ought
to consider it fully supported ("edge case" makes it sound as if this
isn't the case).
> I might be wrong but I think Nikolaus (maintainer of S3QL) will not
> accept such a huge change into S3QL that is only beneficial for an edge
> case.
Never say never, but the bar is certainly high here. I think there are
more promising avenues to explore - eg. storing the
compressed/uncompressed offset mapping to make partial retrieval work
for all cases.
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to s3ql+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/87v9ivnqth.fsf%40thinkpad.rath.org.
