From: Theodore Tso <tytso@mit.edu>
To: Alexandre Ratchov <alexandre.ratchov@bull.net>
Cc: linux-ext4@vger.kernel.org, Jean-Pierre Dion <jean-pierre.dion@bull.net>
Subject: Re: [patch 07/12] rfc: 2fsprogs update
Date: Tue, 26 Sep 2006 13:37:00 -0400 [thread overview]
Message-ID: <20060926173700.GD4219@thunk.org> (raw)
In-Reply-To: <20060926144832.GG25755@openx1.frec.bull.fr>
On Tue, Sep 26, 2006 at 04:48:32PM +0200, Alexandre Ratchov wrote:
> convert all 32bit on-disk block number definitions (currently __u32,
> blk_t, unsigned long, unsigned int...) to pblk_t that is defined as
> __u32. In this way we are sure that blk_t is used only in memory.
> Later, this would allow to make blk_t 64bit without disturbing any
> programs (this would just eat more momory and use 64bit arithmetic).
I *really* dislike this approach, because it makes it very hard to
prove that we got all of the conversions right --- any mistakes about
which instances of blk_t need to become pblk_t, and which are supposed
to stay blk_t, and we end up breaking our ABI compatibility. And
let's just say I have higher standards than Greg KH has shown with
udev. :-)
I also don't like pblk_t, because it's not at all obvious what it
means. And what if we want to support 64-bit logicial blocks someday?
Then it's another painful exercise to figure out which blk_t get
separated to lblk_t, etc.
So my plan is to introduce a new type, blk64_t, and create new
interfaces, such as ext2fs_extent_iterate(), which will use the new
type --- and which will work with old-style indirect block inodes as
well (it will translate indirect blocks into extents).
- Ted
next prev parent reply other threads:[~2006-09-26 17:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 14:33 rfc: 2fsprogs update Alexandre Ratchov
2006-09-26 14:45 ` [patch 02/12] " Alexandre Ratchov
2006-09-26 14:46 ` [patch 03/12] " Alexandre Ratchov
2006-09-26 14:47 ` [patch 04/12] " Alexandre Ratchov
2006-09-26 17:32 ` Theodore Tso
2006-09-26 19:54 ` Andreas Dilger
2006-09-26 21:16 ` Theodore Tso
2006-09-27 12:59 ` Alexandre Ratchov
2006-09-27 14:10 ` Theodore Tso
2006-09-26 14:47 ` [patch 05/12] " Alexandre Ratchov
2006-09-26 14:48 ` [patch 06/12] " Alexandre Ratchov
2006-09-26 14:48 ` [patch 07/12] " Alexandre Ratchov
2006-09-26 17:37 ` Theodore Tso [this message]
2006-09-27 13:36 ` Alexandre Ratchov
2006-09-27 14:38 ` Theodore Tso
2006-09-26 14:49 ` [patch 08/12] " Alexandre Ratchov
2006-09-26 14:50 ` [patch 10/12] " Alexandre Ratchov
2006-09-26 14:50 ` [patch 11/12] " Alexandre Ratchov
2006-09-26 14:50 ` [patch 12/12] " Alexandre Ratchov
2006-09-26 16:47 ` Alexandre Ratchov
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=20060926173700.GD4219@thunk.org \
--to=tytso@mit.edu \
--cc=alexandre.ratchov@bull.net \
--cc=jean-pierre.dion@bull.net \
--cc=linux-ext4@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.