From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by canuck.infradead.org with esmtps (Exim 4.63 #1 (Red Hat Linux)) id 1Hon3d-0008R8-3Q for linux-mtd@lists.infradead.org; Thu, 17 May 2007 16:58:46 -0400 Message-ID: <464CC209.4060500@cs.helsinki.fi> Date: Thu, 17 May 2007 23:58:49 +0300 From: Pekka Enberg MIME-Version: 1.0 To: "=?UTF-8?B?SsO2cm4gRW5nZWw=?=" Subject: Re: [PATCH] LogFS take three References: <20070515151919.GA32510@lazybastard.org> <20070516122603.GE5472@lazybastard.org> <84144f020705160536i189f6206sffc964a145177da7@mail.gmail.com> <20070516132035.GJ5472@lazybastard.org> In-Reply-To: <20070516132035.GJ5472@lazybastard.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: akpm@osdl.org, Evgeniy Polyakov , Albert Cahalan , Greg KH , linux-kernel@vger.kernel.org, Ingo Oeser , linux-mtd@lists.infradead.org, Jan Engelhardt , linux-fsdevel@vger.kernel.org, Thomas Gleixner List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Jörn Engel wrote: > Compressing random data will actually enlarge it. If that happens I > simply store the verbatim uncompressed data instead and mark it as such. > > There is also demand for a user-controlled bit in the inode to disable > compression completely. All those .jpg, .mpg, .mp3, etc. just waste > time by trying and failing to compress them. So any sane way to enable compression is on per-inode basis which makes me still wonder why you need per-object compression. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757458AbXEQU6s (ORCPT ); Thu, 17 May 2007 16:58:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754417AbXEQU6j (ORCPT ); Thu, 17 May 2007 16:58:39 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1]:40682 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754136AbXEQU6i (ORCPT ); Thu, 17 May 2007 16:58:38 -0400 Message-ID: <464CC209.4060500@cs.helsinki.fi> Date: Thu, 17 May 2007 23:58:49 +0300 From: Pekka Enberg User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "=?UTF-8?B?SsO2cm4gRW5nZWw=?=" CC: 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 Subject: Re: [PATCH] LogFS take three References: <20070515151919.GA32510@lazybastard.org> <20070516122603.GE5472@lazybastard.org> <84144f020705160536i189f6206sffc964a145177da7@mail.gmail.com> <20070516132035.GJ5472@lazybastard.org> In-Reply-To: <20070516132035.GJ5472@lazybastard.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jörn Engel wrote: > Compressing random data will actually enlarge it. If that happens I > simply store the verbatim uncompressed data instead and mark it as such. > > There is also demand for a user-controlled bit in the inode to disable > compression completely. All those .jpg, .mpg, .mp3, etc. just waste > time by trying and failing to compress them. So any sane way to enable compression is on per-inode basis which makes me still wonder why you need per-object compression. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: [PATCH] LogFS take three Date: Thu, 17 May 2007 23:58:49 +0300 Message-ID: <464CC209.4060500@cs.helsinki.fi> References: <20070515151919.GA32510@lazybastard.org> <20070516122603.GE5472@lazybastard.org> <84144f020705160536i189f6206sffc964a145177da7@mail.gmail.com> <20070516132035.GJ5472@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: 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: "=?UTF-8?B?SsO2cm4gRW5nZWw=?=" Return-path: Received: from courier.cs.helsinki.fi ([128.214.9.1]:40682 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754136AbXEQU6i (ORCPT ); Thu, 17 May 2007 16:58:38 -0400 In-Reply-To: <20070516132035.GJ5472@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org J=C3=B6rn Engel wrote: > Compressing random data will actually enlarge it. If that happens I > simply store the verbatim uncompressed data instead and mark it as su= ch. >=20 > There is also demand for a user-controlled bit in the inode to disabl= e > compression completely. All those .jpg, .mpg, .mp3, etc. just waste > time by trying and failing to compress them. So any sane way to enable compression is on per-inode basis which makes= =20 me still wonder why you need per-object compression. - 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