From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.2ka.mipt.ru ([194.85.82.65] helo=2ka.mipt.ru) by canuck.infradead.org with esmtp (Exim 4.63 #1 (Red Hat Linux)) id 1HoiSs-0003Qa-BL for linux-mtd@lists.infradead.org; Thu, 17 May 2007 12:04:31 -0400 Date: Thu, 17 May 2007 20:03:11 +0400 From: Evgeniy Polyakov To: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: Review status (Re: [PATCH] LogFS take three) Message-ID: <20070517160308.GA26643@2ka.mipt.ru> References: <20070515151919.GA32510@lazybastard.org> <20070515152149.GB32059@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070515152149.GB32059@lazybastard.org> Cc: akpm@osdl.org, Albert Cahalan , Greg KH , linux-kernel@vger.kernel.org, Ingo Oeser , Pekka Enberg , 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: , Hi Jörn. Is logfs 32bit fs or 674bit, since although you use 64bit values for offsets, area management and strange converstions like described below from offset into segment number are performed in 32bit? Is it enough for SSD for example to be 32bit only? Or if it is 64bit, could you please explain logic behind area management? I've found that you store segment numbers as 32bit values (for example in prepare_write()), and convert requested 64bit offset into segment number via superblock's s_segshift. This conversation seems confusing to me in case of real 64bit offsets. For example this one obtained via prepare_write: 7 1 logfs_prepare_write 78 fs/logfs/file.c 8 2 logfs_readpage_nolock 20 fs/logfs/file.c 9 1 logfs_read_block 351 fs/logfs/readwrite.c 10 1 logfs_read_loop 139 fs/logfs/readwrite.c 11 2 logfs_segment_read 108 fs/logfs/readwrite.c 12 1 wbuf_read 289 u32 segno = ofs >> super->s_segshift; ofs is originally obtained from inode's li_data array, which is filled with raw segment numbers which can be 64bit (here is another issue, since logfs_segment_write() returns signed, so essentially logfs is 63bit filesystem). But here I've came to area management in logfs, and found that it is 32bit only, for example __logfs_segment_write()/__logfs_get_free_bytes() returns signed 32 bit value (so it is reduced to 31 bit), which is then placed into li_data as 64bit value. The latter (__logfs_get_free_bytes()) truncates 64bit data value obtained via dev_ofs() into signed 32 bit value. -- Evgeniy Polyakov From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756642AbXEQQFa (ORCPT ); Thu, 17 May 2007 12:05:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755339AbXEQQFV (ORCPT ); Thu, 17 May 2007 12:05:21 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:53593 "EHLO 2ka.mipt.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755263AbXEQQFU (ORCPT ); Thu, 17 May 2007 12:05:20 -0400 Date: Thu, 17 May 2007 20:03:11 +0400 From: Evgeniy Polyakov To: =?utf-8?B?SsO2cm4=?= Engel 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 , Pekka Enberg , Greg KH , Ingo Oeser Subject: Re: Review status (Re: [PATCH] LogFS take three) Message-ID: <20070517160308.GA26643@2ka.mipt.ru> References: <20070515151919.GA32510@lazybastard.org> <20070515152149.GB32059@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070515152149.GB32059@lazybastard.org> User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (2ka.mipt.ru [0.0.0.0]); Thu, 17 May 2007 20:03:25 +0400 (MSD) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Jörn. Is logfs 32bit fs or 674bit, since although you use 64bit values for offsets, area management and strange converstions like described below from offset into segment number are performed in 32bit? Is it enough for SSD for example to be 32bit only? Or if it is 64bit, could you please explain logic behind area management? I've found that you store segment numbers as 32bit values (for example in prepare_write()), and convert requested 64bit offset into segment number via superblock's s_segshift. This conversation seems confusing to me in case of real 64bit offsets. For example this one obtained via prepare_write: 7 1 logfs_prepare_write 78 fs/logfs/file.c 8 2 logfs_readpage_nolock 20 fs/logfs/file.c 9 1 logfs_read_block 351 fs/logfs/readwrite.c 10 1 logfs_read_loop 139 fs/logfs/readwrite.c 11 2 logfs_segment_read 108 fs/logfs/readwrite.c 12 1 wbuf_read 289 u32 segno = ofs >> super->s_segshift; ofs is originally obtained from inode's li_data array, which is filled with raw segment numbers which can be 64bit (here is another issue, since logfs_segment_write() returns signed, so essentially logfs is 63bit filesystem). But here I've came to area management in logfs, and found that it is 32bit only, for example __logfs_segment_write()/__logfs_get_free_bytes() returns signed 32 bit value (so it is reduced to 31 bit), which is then placed into li_data as 64bit value. The latter (__logfs_get_free_bytes()) truncates 64bit data value obtained via dev_ofs() into signed 32 bit value. -- Evgeniy Polyakov From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy Polyakov Subject: Re: Review status (Re: [PATCH] LogFS take three) Date: Thu, 17 May 2007 20:03:11 +0400 Message-ID: <20070517160308.GA26643@2ka.mipt.ru> References: <20070515151919.GA32510@lazybastard.org> <20070515152149.GB32059@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: akpm@osdl.org, Albert Cahalan , Greg KH , linux-kernel@vger.kernel.org, Ingo Oeser , Pekka Enberg , linux-mtd@lists.infradead.org, Jan Engelhardt , linux-fsdevel@vger.kernel.org, Thomas Gleixner To: =?utf-8?B?SsO2cm4=?= Engel Return-path: Content-Disposition: inline In-Reply-To: <20070515152149.GB32059@lazybastard.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org+gldm-linux-mtd-36=gmane.org@lists.infradead.org List-Id: linux-fsdevel.vger.kernel.org CkhpIErDtnJuLgoKSXMgbG9nZnMgMzJiaXQgZnMgb3IgNjc0Yml0LCBzaW5jZSBhbHRob3VnaCB5 b3UgdXNlIDY0Yml0IHZhbHVlcyBmb3IKb2Zmc2V0cywgYXJlYSBtYW5hZ2VtZW50IGFuZCBzdHJh bmdlIGNvbnZlcnN0aW9ucyBsaWtlIGRlc2NyaWJlZCBiZWxvdyAKZnJvbSBvZmZzZXQgaW50byBz ZWdtZW50IG51bWJlciBhcmUgcGVyZm9ybWVkIGluIDMyYml0PwpJcyBpdCBlbm91Z2ggZm9yIFNT RCBmb3IgZXhhbXBsZSB0byBiZSAzMmJpdCBvbmx5PyBPciBpZiBpdCBpcyA2NGJpdCwKY291bGQg eW91IHBsZWFzZSBleHBsYWluIGxvZ2ljIGJlaGluZCBhcmVhIG1hbmFnZW1lbnQ/CgpJJ3ZlIGZv dW5kIHRoYXQgeW91IHN0b3JlIHNlZ21lbnQgbnVtYmVycyBhcyAzMmJpdCB2YWx1ZXMgKGZvciBl eGFtcGxlCmluIHByZXBhcmVfd3JpdGUoKSksIGFuZCBjb252ZXJ0IHJlcXVlc3RlZCA2NGJpdCBv ZmZzZXQgaW50byBzZWdtZW50Cm51bWJlciB2aWEgc3VwZXJibG9jaydzIHNfc2Vnc2hpZnQuClRo aXMgY29udmVyc2F0aW9uIHNlZW1zIGNvbmZ1c2luZyB0byBtZSBpbiBjYXNlIG9mIHJlYWwgNjRi aXQgb2Zmc2V0cy4KRm9yIGV4YW1wbGUgdGhpcyBvbmUgb2J0YWluZWQgdmlhIHByZXBhcmVfd3Jp dGU6Cgo3ICAxIGxvZ2ZzX3ByZXBhcmVfd3JpdGUgICAgNzggIGZzL2xvZ2ZzL2ZpbGUuYwo4ICAy IGxvZ2ZzX3JlYWRwYWdlX25vbG9jayAgICAyMCAgZnMvbG9nZnMvZmlsZS5jCjkgIDEgbG9nZnNf cmVhZF9ibG9jayAgIDM1MSAgZnMvbG9nZnMvcmVhZHdyaXRlLmMKMTAgIDEgbG9nZnNfcmVhZF9s b29wICAgMTM5ICBmcy9sb2dmcy9yZWFkd3JpdGUuYwoxMSAgMiBsb2dmc19zZWdtZW50X3JlYWQg ICAxMDggIGZzL2xvZ2ZzL3JlYWR3cml0ZS5jCjEyICAxIHdidWZfcmVhZCAgICAgICAgIDI4OSAK CnUzMiBzZWdubyA9IG9mcyA+PiBzdXBlci0+c19zZWdzaGlmdDsKCm9mcyBpcyBvcmlnaW5hbGx5 IG9idGFpbmVkIGZyb20gaW5vZGUncyBsaV9kYXRhIGFycmF5LCB3aGljaCBpcyBmaWxsZWQKd2l0 aCByYXcgc2VnbWVudCBudW1iZXJzIHdoaWNoIGNhbiBiZSA2NGJpdCAoaGVyZSBpcyBhbm90aGVy IGlzc3VlLApzaW5jZSBsb2dmc19zZWdtZW50X3dyaXRlKCkgcmV0dXJucyBzaWduZWQsIHNvIGVz c2VudGlhbGx5IGxvZ2ZzIGlzCjYzYml0IGZpbGVzeXN0ZW0pLgoKQnV0IGhlcmUgSSd2ZSBjYW1l IHRvIGFyZWEgbWFuYWdlbWVudCBpbiBsb2dmcywgYW5kIGZvdW5kIHRoYXQgaXQgaXMKMzJiaXQg b25seSwgZm9yIGV4YW1wbGUgX19sb2dmc19zZWdtZW50X3dyaXRlKCkvX19sb2dmc19nZXRfZnJl ZV9ieXRlcygpIApyZXR1cm5zIHNpZ25lZCAzMiBiaXQgdmFsdWUgKHNvIGl0IGlzIHJlZHVjZWQg dG8gMzEgYml0KSwgd2hpY2ggaXMgdGhlbiAKcGxhY2VkIGludG8gbGlfZGF0YSBhcyA2NGJpdCB2 YWx1ZS4gVGhlIGxhdHRlcgooX19sb2dmc19nZXRfZnJlZV9ieXRlcygpKSB0cnVuY2F0ZXMgNjRi aXQgZGF0YSB2YWx1ZSBvYnRhaW5lZCB2aWEKZGV2X29mcygpIGludG8gc2lnbmVkIDMyIGJpdCB2 YWx1ZS4KCi0tIAoJRXZnZW5peSBQb2x5YWtvdgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcg bGlzdApodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10 ZC8K