From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79486 Path: news.gmane.org!not-for-mail From: lee Newsgroups: gmane.emacs.gnus.general Subject: Re: compressing articles not working correctly Date: Thu, 14 Jul 2011 22:02:46 +0200 Organization: my virtual residence Message-ID: <87liw0d40p.fsf@yun.yagibdah.de> References: <87ipr4eug2.fsf@yun.yagibdah.de> <871uxsesvn.fsf@topper.koldfront.dk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1310673824 13393 80.91.229.12 (14 Jul 2011 20:03:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2011 20:03:44 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M27782@lists.math.uh.edu Thu Jul 14 22:03:40 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QhS8J-0001OI-4E for ding-account@gmane.org; Thu, 14 Jul 2011 22:03:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1QhS7b-0007GU-DY; Thu, 14 Jul 2011 15:02:55 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QhS7Z-0007G9-9n for ding@lists.math.uh.edu; Thu, 14 Jul 2011 15:02:53 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QhS7U-0002yG-C4 for ding@lists.math.uh.edu; Thu, 14 Jul 2011 15:02:52 -0500 Original-Received: from static.103.179.46.78.clients.your-server.de ([78.46.179.103] helo=static.73.179.46.78.clients.your-server.de) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1QhS7S-0008QP-Oq for ding@gnus.org; Thu, 14 Jul 2011 22:02:46 +0200 Original-Received: from lee by yun.yagibdah.de with local (Exim 4.76) (envelope-from ) id 1QhS7S-0000Em-4b for ding@gnus.org; Thu, 14 Jul 2011 22:02:46 +0200 Mail-Followup-To: ding@gnus.org In-Reply-To: <871uxsesvn.fsf@topper.koldfront.dk> ("Adam =?utf-8?Q?Sj?= =?utf-8?Q?=C3=B8gren=22's?= message of "Thu, 14 Jul 2011 18:20:28 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Spam-Score: 0.1 (/) X-Spam-Report: SpamAssassin (3.3.1 2010-03-16) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-1866--6186h-0s--0d--H*u:Emacs, 0.000-1730--5736h-0s--0d--H*u:Gnus, 0.000-1654--5483h-0s--0d--H*u:linux, 0.000-1654--5483h-0s--0d--H*UA:linux, 0.000-1603--5315h-0s--0d--H*u:gnu Spam tokens: 0.987-1--0h-1s--0d--H*r:sk:clients, 0.957-4453--1457h-53790s--0d--H*r:quimby.gnus.org, 0.923-244--206h-4089s--0d--H*r:sk:static., 0.885-1691--4253h-54094s--0d--HX-Spam-Relays-External:quimby.gnus.org, 0.885-1691--4253h-54094s--0d--H*RU:quimby.gnus.org Autolearn status: no -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79486 Archived-At: asjo@koldfront.dk (Adam Sj=C3=B8gren) writes: > On Thu, 14 Jul 2011 17:46:37 +0200, lee wrote: > >> ,---- [ lee@yun:~/Mail/mail/lists/users-global-libreoffice$ ls -lat ] >> | -rw------- 1 lee lee 5012 14. Jul 17:26 1161 >> | -rw------- 1 lee lee 4896 14. Jul 17:26 1160 >> | -rw------- 1 lee lee 4909 14. Jul 17:26 1159.bz2 >> `---- > > ls -l doesn't report the size of the body of the email. The > documentation of nnml-compressed-files-size-threshold indicates that the > headers are not included when applying the threshold: > > ,----[ C-h v nnml-compressed-files-size-threshold RET ] > | Default size threshold for compressed message files. > | Message files with bodies larger than that many characters will > ^^^^^^ > | be automatically compressed if `nnml-use-compressed-files' is > | non-nil. > `---- > > Could that be it? Hm, looks like it. I checked above articles and found that the body is only about 1kB. The idea is to save disk space without losing more speed than necessary due to compression. Each article will occupy at least 4kB because that's the sector size. I could probably set the threshold to -1 and have all articles compressed, but for those articles that are smaller than 4kB, including headers, compression isn't needed. The same goes for articles >4kB<8kB uncompressed and still >4kB<8kB when compressed. Looks like I should write some program that scans the article storage and compresses all uncompressed articles depending on whether the compression does save disk space or not ... The speed gain might be not worth it because it doesn't take awfully long to (un-)compress small articles. Hmm.