Thread (10 messages) 10 messages, 4 authors, 2021-08-27

Re: [PATCH] Revert "btrfs: compression: don't try to compress if we don't have enough pages"

From: David Sterba <hidden>
Date: 2021-08-25 13:07:37

On Wed, Aug 25, 2021 at 08:06:57PM +0800, Qu Wenruo wrote:
On 2021/8/25 下午7:55, David Sterba wrote:
quoted
On Wed, Aug 25, 2021 at 01:41:42PM +0800, Qu Wenruo wrote:
quoted
This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763.
At this point the revert is the simplest way to restore the inline
extent compression so that's what I'll probably do. However.
quoted
[BUG]
It's no longer possible to create compressed inline extent after commit
f2165627319f ("btrfs: compression: don't try to compress if we don't
have enough pages").

[CAUSE]
For compression code, there are several possible reasons we have a range
that needs to be compressed while it's no more than one page.

- Compressed inline write
   The data is always smaller than one sector.
The missing logic was for the true inline extent. The patch was supposed
to skip compression for single pages other than inline extents, due to
efficiency. So I wonder if we want to do that or just don't bother as
it's probably a negligible amount of wasted time.
Yeah, I guess that's the case.

We may be able to do such check in the future, but at that time, we need 
to take inline extents into consideration.

Thus it won't be just a simple @nr_pages check, but with extra 
@start/@len check.
Yeah that's why revert is better than enhancing the test with the mising
bits.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help