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 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 lo
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
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 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
>
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: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 notmuch-search-te
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
> > smal
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 syste
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.
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
> Christoph Anton Mitterer 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 files are co
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.
13 matches
Mail list logo
