public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: "Jörn Engel" <joern@lazybastard.org>
Cc: akpm@osdl.org, Albert Cahalan <acahalan@gmail.com>,
	Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, Ingo Oeser <ioe-lkml@rameria.de>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	linux-mtd@lists.infradead.org,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	linux-fsdevel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Review status (Re: [PATCH] LogFS take three)
Date: Thu, 17 May 2007 20:03:11 +0400	[thread overview]
Message-ID: <20070517160308.GA26643@2ka.mipt.ru> (raw)
In-Reply-To: <20070515152149.GB32059@lazybastard.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

  reply	other threads:[~2007-05-17 16:04 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-15 15:19 [PATCH] LogFS take three Jörn Engel
2007-05-15 15:21 ` Review status (Re: [PATCH] LogFS take three) Jörn Engel
2007-05-17 16:03   ` Evgeniy Polyakov [this message]
2007-05-17 17:10     ` Jörn Engel
2007-05-20 17:30       ` Evgeniy Polyakov
2007-05-23 12:58         ` Jörn Engel
2007-05-23 15:07           ` Evgeniy Polyakov
2007-05-23 15:14             ` Jörn Engel
2007-05-23 15:53               ` Evgeniy Polyakov
2007-05-15 18:37 ` [PATCH] LogFS take three Sam Ravnborg
2007-05-15 19:10   ` Jörn Engel
2007-05-15 19:07 ` John Stoffel
2007-05-15 19:19   ` Jörn Engel
2007-05-16  4:54     ` David Woodhouse
2007-05-16 11:09       ` Jörn Engel
2007-05-16 11:34         ` Jamie Lokier
2007-05-16 11:38           ` Artem Bityutskiy
2007-05-16 12:25             ` Jamie Lokier
2007-05-16 12:49               ` Jörn Engel
2007-05-16 11:50           ` Jörn Engel
2007-05-16 12:06             ` CaT
2007-05-17 17:07               ` Jan Engelhardt
2007-05-16 12:29             ` Evgeniy Polyakov
2007-05-16 12:55               ` Jörn Engel
2007-05-17 17:08                 ` Jan Engelhardt
2007-05-16 13:41             ` John Stoffel
2007-05-16 13:53               ` Jörn Engel
2007-05-16 14:04                 ` David Woodhouse
2007-05-16 14:13                   ` Artem Bityutskiy
2007-05-16 14:17                   ` Kevin Bowling
2007-05-17  9:12                     ` Pavel Machek
2007-05-17  9:52                       ` David Woodhouse
2007-05-19 15:00                     ` Bill Davidsen
2007-05-16 14:29                 ` CaT
2007-05-17 17:14                 ` Jan Engelhardt
2007-05-19 14:45                 ` David Weinehall
2007-05-19 16:17                   ` Jamie Lokier
2007-05-19 16:27                     ` Evgeniy Polyakov
2007-05-17 16:59         ` Jan Engelhardt
2007-05-17 11:39     ` Arnd Bergmann
2007-05-15 20:37 ` Andrew Morton
2007-05-16  0:06   ` Jörn Engel
2007-05-16  2:11     ` Jörn Engel
2007-05-16  5:22     ` Willy Tarreau
2007-05-16 11:23       ` Jörn Engel
2007-05-17 17:26     ` Jan Engelhardt
2007-05-17 17:45       ` Evgeniy Polyakov
2007-05-18  1:00         ` Kyle Moffett
2007-05-18  6:16           ` Jan Engelhardt
2007-05-16 12:07   ` David Woodhouse
2007-05-16 15:34     ` Andrew Morton
2007-05-16 15:49       ` David Woodhouse
2007-05-16 16:41         ` Jörn Engel
     [not found]           ` <7fe698080705162312t4e7ed90byd10ef8e664027b17@mail.gmail.com>
2007-05-17  6:25             ` David Woodhouse
2007-05-17  8:20               ` Dongjun Shin
2007-05-17  8:43                 ` David Woodhouse
2007-05-17 12:05                   ` Jörn Engel
2007-05-17 20:18                 ` Pavel Machek
2007-05-18  0:01                   ` Dongjun Shin
2007-05-18  6:17                     ` Jan Engelhardt
2007-05-18  6:47                       ` David Woodhouse
2007-05-19 15:18                 ` Bill Davidsen
2007-05-19  6:15   ` Rob Landley
2007-05-19  9:24     ` Jan Engelhardt
2007-05-19 17:26       ` Rob Landley
2007-05-15 23:26 ` Albert Cahalan
2007-05-16  0:09   ` Jörn Engel
2007-05-16 11:18   ` Jamie Lokier
2007-05-16 12:08     ` Pekka Enberg
2007-05-16 12:58       ` Jörn Engel
2007-05-16  2:37 ` Roland Dreier
2007-05-16 11:35   ` Jörn Engel
2007-05-16 10:21 ` Pekka J Enberg
2007-05-16 12:26   ` Jörn Engel
2007-05-16 12:36     ` Pekka Enberg
2007-05-16 12:38       ` Pekka Enberg
2007-05-16 13:20       ` Jörn Engel
2007-05-17 20:58         ` Pekka Enberg
2007-05-17 21:36           ` Arnd Bergmann
2007-05-17 21:50             ` Jörn Engel
2007-05-16 19:17 ` Pavel Machek
2007-05-16 19:23   ` Jörn Engel
2007-05-17 15:08 ` Arnd Bergmann
2007-05-17 20:21   ` Jörn Engel
2007-05-17 21:00     ` Arnd Bergmann
2007-05-17 21:30       ` Jörn Engel
2007-05-17 22:01     ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070517160308.GA26643@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=acahalan@gmail.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=ioe-lkml@rameria.de \
    --cc=jengelh@linux01.gwdg.de \
    --cc=joern@lazybastard.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox