On Jo, 29 nov 12, 11:35:44, Ivan Shmakov wrote:
What are the estimates? And wouldn't it be better to use some
kind of a specialized search engine if searching is deemed
“crucial”? I guess that it may render the difference between
the formats somewhat irrelevant.
On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
But it also has disadvantages to the mbox formats which may be crucial
for some people:
- wasting a lot of storage, which can be significant even if you use
small file systems block sizes...
This is a problem with the file system,
On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote:
On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
But it also has disadvantages to the mbox formats which may be crucial
for some people:
- wasting a lot of storage, which can be significant even if you use
small file
On Thu, Nov 29, 2012 at 03:30:47PM +0100, Christoph Anton Mitterer wrote:
Do these tools (mairix, notmuch, etc.) also help with real full text
search? I just though they'd index some stuff.
I can't speak for mairix, etc., but notmuch can handle full text search.
To quote from
On 2012-11-29 15:30:47 +0100, Christoph Anton Mitterer wrote:
On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote:
Now, I would say that in general, the wasted space is small compared
to large attachments. And if you have only text and care about disk
space, you should consider a
On Thu, Nov 29, 2012 at 03:20:34PM +0100, Vincent Lefevre wrote:
On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
But it also has disadvantages to the mbox formats which may be crucial
for some people:
- wasting a lot of storage, which can be significant even if you use
small
On Thu, Nov 29, 2012 at 04:16:25PM +0100, Adam Borowski wrote:
*cough* btrfs -ocompress=lzo. Small files are packed inline in metadata
blocks, and you get compression you wanted.
It's nice to see more features from '93 Windows NT implemented for Linux
at last.
--
WBR, wRAR
signature.asc
On 2012-11-29 16:16:25 +0100, Adam Borowski wrote:
*cough* btrfs -ocompress=lzo. Small files are packed inline in metadata
blocks, and you get compression you wanted. Using lzo is faster than no
compression for most loads, adding negligible cost for incompressible data
(especially if not all
On Thu, Nov 29, 2012 at 04:32:33PM +0100, Vincent Lefevre wrote:
On 2012-11-29 16:16:25 +0100, Adam Borowski wrote:
*cough* btrfs -ocompress=lzo. Small files are packed inline in metadata
blocks, and you get compression you wanted. Using lzo is faster than no
compression for most loads,
On Thu, Nov 29, 2012 at 05:52:06PM +0100, Adam Borowski wrote:
Outside of dpkg, sqlite in non-WAL mode, other databases and virtualbox/
qemu, btrfs is pretty fast.
That may be true, but it glosses over how awful performance is on those
workloads on btrfs. A single Berkeley DB transaction can
On Wed, 2012-11-28 at 14:32 +0700, Ivan Shmakov wrote:
# With the advent and now widespread adoption of the superior Maildir
# format over the past several years, the entire mbox family of
# mailbox formats is gradually becoming irrelevant, and of only
# historical interest.
Just
Christoph Anton Mitterer cales...@scientia.net writes:
[…]
But it also has disadvantages to the mbox formats which may be
crucial for some people:
- wasting a lot of storage, which can be significant even if you use
small file systems block sizes...
Only as long as static mbox
I wouldn't put all my eggs in the same single file.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwy1djt5@jidanni.org
Adam Borowski kilob...@angband.pl writes:
[…]
Quoting from that page:
# With the advent and now widespread adoption of the superior Maildir
# format over the past several years, the entire mbox family of
# mailbox formats is gradually becoming irrelevant, and of only
# historical
14 matches
Mail list logo
