Sebastian Gottschall

from my understanding a physical sectorsize is much smaller than a block size. so i would solve this in the following way targetsize = inputsize - (inputsize % sectorsize). so...

but a uncompressed block will still ignore this rule of course. so the question is if it really makes any benefit if we align it, because if its uncompressed it...

regarding your formula. 128kb - 4K = 124K but 128K is sector aligned already. so no need to subtract anything

@thulle yes, but the 12.5% is a wild value. i mean after compression the ratio is detected, but the performance for doing the compression is already lost. so even if...

@GregorKopka yes. but a simply compressedsize < sourcesize match would be already enough. we dont need to subtract another sector size as ratio. in our example with 4K sector size...

@thulle i cannot answer this question. read the topic of this pull request. its not mine yes 127kb will still waste 1kb. but its the same waste if its stored...

i agree that one sector size at least would make sense for minimum compression threshold, since anything more would not greate any benefit for physical read/write efforts. but consider that...

> @BrainSlayer I've got your point and generally agree with it, but I think that one simple check in this exact case is still faster than decompression of block without...

sorry. i have to correct my sayings. i handled this case in my zstd PR code, but its not handled by the upstream code. so the zstd PR does handle...

@gmelikov i just think a compression threshold limiter parameter is a logic consequence in this development here. why do we decide what a user wants? give him the choice. black...