From: Andreas Dilger <adilger@clusterfs.com>
To: sho@tnes.nec.co.jp
Cc: Ext2-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [Ext2-devel] [RFC][8/21]ext3 modify variables to exceed 2G
Date: Thu, 13 Apr 2006 11:14:45 -0600 [thread overview]
Message-ID: <20060413171445.GT17364@schatzie.adilger.int> (raw)
In-Reply-To: <20060413160657sho@rifu.tnes.nec.co.jp>
On Apr 13, 2006 16:06 +0900, sho@tnes.nec.co.jp wrote:
> Summary of this patch:
> [8/21] change the type of variables manipulating a block or an
> inode(ext3)
> - Change the type of 4byte variables manipulating a block or
> an inode from signed to unsigned.
Takashi-san, please, it would make the code much more maintainable if the
changes made here would use new types for filesystem-wide block offsets
and for file-relative block offsets, as was previously discussed, instead
of just changing some variables to be unsigned long. Like:
typedef unsigned long ext3_fsblk_t; # block offset in the filesystem
typedef unsigned long ext3_fscnt_t; # block count in the filesystem
typedef unsigned long ext3_fileblk_t; # block offset in a file
I believe we should already be using le32 for all on-disk blocks (e.g.
indirect blocks, inodes, etc), but this would be good to verify.
This way, when we get to the stage where we want to increase the blocks
to be 64-bit (as Laurent has wanted to do) we don't need to go through
and re-patch all of the same files to change "unsigned long" to
"unsigned long long". It also makes the code easier to read, since it
will be clear what kind of variable is being used.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
next prev parent reply other threads:[~2006-04-13 17:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 7:06 sho
2006-04-13 17:14 ` Andreas Dilger [this message]
2006-04-14 9:23 ` [Ext2-devel] " Takashi Sato
2006-04-14 14:59 ` Mingming Cao
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=20060413171445.GT17364@schatzie.adilger.int \
--to=adilger@clusterfs.com \
--cc=Ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sho@tnes.nec.co.jp \
/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
all inboxes | Powered by JetHome®