linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).