From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: [PATCH] LogFS take three Date: Thu, 17 May 2007 23:50:58 +0200 Message-ID: <20070517215057.GH15676@lazybastard.org> References: <20070515151919.GA32510@lazybastard.org> <20070516132035.GJ5472@lazybastard.org> <464CC209.4060500@cs.helsinki.fi> <200705172336.14552.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Pekka Enberg , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, akpm@osdl.org, Albert Cahalan , Thomas Gleixner , Jan Engelhardt , Evgeniy Polyakov , Greg KH , Ingo Oeser To: Arnd Bergmann Return-path: Received: from lazybastard.de ([212.112.238.170]:52969 "EHLO longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755961AbXEQVzT (ORCPT ); Thu, 17 May 2007 17:55:19 -0400 Content-Disposition: inline In-Reply-To: <200705172336.14552.arnd@arndb.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 17 May 2007 23:36:13 +0200, Arnd Bergmann wrote: > On Thursday 17 May 2007, Pekka Enberg wrote: > >=20 > > So any sane way to enable compression is on per-inode basis which m= akes=20 > > me still wonder why you need per-object compression. >=20 > 1. it doesn't require user interaction, the file system will do the r= ight > thing most of the time. >=20 > 2. enlarging data is a very bad thing because it makes the behaviour > of the fs unpredictable. With uncompressed objects, you have a guaran= teed > upper bound on the size. Correct. The compression decision is always per-object. Per-inode is = a hint from userspace that a compression attempt would be futile. A compression algorithm that compresses any data is provably impossible= =2E Some data will always cause expansion instead of compression. Some algorithms have a well-known upper bound on the expansion, others don't= =2E So LogFS instead creates its own upper bound by reserving one byte in the header for the compression type. And while one bit would suffice as a compressed/uncompressed flag, having a byte allows to support more than one compression algorithm. LZO looks promising and is on its way into the kernel. Others may come in the future. J=C3=B6rn --=20 My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. -- Edsger W. Dijkstra - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html