From: David Disseldorp <ddiss@suse.de>
To: Enzo Matsumiya <ematsumiya@suse.de>
Cc: Jan Kara <jack@suse.cz>,
lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-cifs@vger.kernel.org
Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Over-the-wire data compression
Date: Mon, 25 Mar 2024 21:40:19 +1100 [thread overview]
Message-ID: <20240325214019.652d5531@echidna> (raw)
In-Reply-To: <vvwzjchwqlgmwrsaphak7zvwoecqjavq7zdwds2zvjuqj65dev@xbv77wuvvjyl>
Hi Enzo,
On Fri, 22 Mar 2024 18:23:54 -0300, Enzo Matsumiya wrote:
> Which brought me to the 'how to detect uncompressible data' subject;
> practical test at hand: when writing this 289MiB ISO file to an SMB
> share with compression enabled, only 7 out of 69 WRITE requests
> (~10%) are compressed.
>
> (this is not the problem since SMB2 compression is supposed to be
> done on a best-effort basis)
>
> So, best effort... for 90% of this particular ISO file, cifs.ko "compressed"
> those requests, reached an output with size >= to input size, discarded it
> all, and sent the original uncompressed request instead => lots of CPU
> cycles wasted. Would be nice to not try to compress such data right of
> the bat, or at least with minimal parsing, instead.
Sounds like storing some compressible vs non-compressible write metrics
alongside a compression-capable SMB2 FILEID would allow for a simple
attempt-compression-on-next-write prediction mechanism. However, you'd
be forced to re-learn compressibility with each reconnect or store it.
FILE_ATTRIBUTE_COMPRESSED might also be available as a (user-provided)
hint.
prev parent reply other threads:[~2024-03-25 10:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <rnx34bfst5gyomkwooq2pvkxsjw5mrx5vxszhz7m4hy54yuma5@huwvwzgvrrru>
2024-03-15 12:22 ` [Lsf-pc] [LSF/MM ATTEND] Over-the-wire data compression Jan Kara
2024-03-18 10:59 ` David Disseldorp
2024-03-22 21:23 ` Enzo Matsumiya
2024-03-25 10:40 ` David Disseldorp [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240325214019.652d5531@echidna \
--to=ddiss@suse.de \
--cc=ematsumiya@suse.de \
--cc=jack@suse.cz \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).