From: "Tony Battersby" <tonyb@cybernetics.com>
To: "'Matthew Wilcox'" <matthew@wil.cx>
Cc: <linux-fsdevel@vger.kernel.org>
Subject: RE: [PATCH] [RFC] LBD fixes for Linux 2.6.10 [2/2]
Date: Thu, 13 Jan 2005 15:46:04 -0500 [thread overview]
Message-ID: <05Jan13.154605est.333580@cyborg.cybernetics.com> (raw)
In-Reply-To: <20050113184302.GC30982@parcelfarce.linux.theplanet.co.uk>
> > 1) Use sector_t rather than long or unsigned long for block numbers.
> > For auditing, just search for all occurrences of "long" in
> the filesystem
> > code and make sure it is not referring to a block number.
>
> That's actually not wise. For ext3, the block numbers _on disc_
> are 32-bit in size, so making them sector_t in memory is just a waste.
> reiserfs seems to be the same. OTOH, XFS does use 64-bit
> blocks on disc,
> so should use an explicitly 64-bit size in memory too.
Thanks, that's why I was looking for feedback before going further. Is
there anywhere in the fs-specific code that deals with real sector
numbers rather than fs block numbers? Any variable that deals with real
sector numbers should be sector_t, even if the filesystem uses only
32-bit block numbers. For example, an ext3 filesystem might be created
in the 3-4 TB range of a 4 TB disk, in which case the fs block numbers
fit into a 32-bit quantity but the real sector numbers need to be 64-bit
because of the large starting offset. If the fs-specific code doesn't
deal with real sector numbers, then there is probably nothing that needs
to be done for ext3 or reiserfs.
Anthony J. Battersby
Cybernetics
prev parent reply other threads:[~2005-01-13 20:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-11 18:47 [PATCH] [RFC] LBD fixes for Linux 2.6.10 [2/2] Tony Battersby
2005-01-13 18:43 ` Matthew Wilcox
2005-01-13 18:54 ` Christoph Hellwig
2005-01-13 20:46 ` Tony Battersby [this message]
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=05Jan13.154605est.333580@cyborg.cybernetics.com \
--to=tonyb@cybernetics.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=matthew@wil.cx \
/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;
as well as URLs for NNTP newsgroup(s).