All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolabs.com>
To: "Peter T. Breuer" <ptb@it.uc3m.es>,
	linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: blocks or KB? (was: .. current meaning of blk_size array)
Date: Wed, 14 Nov 2001 22:55:24 -0700	[thread overview]
Message-ID: <20011114225524.Z5739@lynx.no> (raw)
In-Reply-To: <3BF23D01.F7E879E8@evision-ventures.com> <200111142041.fAEKfBN15594@oboe.it.uc3m.es> <20011115003434.A25883@node0.opengeometry.ca>
In-Reply-To: <20011115003434.A25883@node0.opengeometry.ca>; from opengeometry@yahoo.ca on Thu, Nov 15, 2001 at 12:34:34AM -0500

On Nov 15, 2001  00:34 -0500, William Park wrote:
> Judging by 'driver/block/nbd.c', it counts by BLOCK_SIZE=1204
> (BLOCK_SIZE_BITS=10), even though you can set the block size to
> [512,1024,...,PAGE_SIZE=4096].  Since NBD counts this 1KB block using
> 'u64' integer, the ultimate size of filesystem is determined by the
> kernel block device support.
> 
> Looking at 'fs/block_dev.c', you can set the block size to
> [512,1024,...,PAGE_SIZE=4096] also.  But, 'max_block()' returns block
> count in whatever block size of the device, not in BLOCK_SIZE:

Sadly, while you _might_ be able to change the BLOCK_SIZE to be something
other than 1kB, there are probably so many places that assume a 1kB size
that you will need a lot of fixing.  I'm not saying that fixing these
things is bad (it would actually be good for many reasons), but just a
heads-up that changing the BLOCK_SIZE define _probably_ won't get you 8TB
devices (maybe a broken system, or corrupt fs instead).  Use caution.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


  reply	other threads:[~2001-11-15  5:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-13 15:08 what is teh current meaning of blk_size? Peter T. Breuer
2001-11-13 18:51 ` blocks or KB? (was: .. current meaning of blk_size array) Peter T. Breuer
2001-11-14  9:44   ` Martin Dalecki
2001-11-14 20:41     ` Peter T. Breuer
2001-11-14 20:51       ` Martin Dalecki
2001-11-14 21:16       ` Andreas Dilger
2001-11-14 21:49         ` Benjamin LaHaise
2001-11-14 22:33           ` Scott Laird
2001-11-15  1:48         ` William Park
2001-11-15  4:58           ` Andreas Dilger
2001-11-15  5:34       ` William Park
2001-11-15  5:55         ` Andreas Dilger [this message]
2001-11-15 10:42         ` Anton Altaparmakov
2001-11-15 12:35         ` Peter T. Breuer
2001-11-15 18:31           ` William Park
2001-11-15 20:19             ` Andreas Dilger
2001-11-15 22:04               ` blocks or KB? William Park

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=20011114225524.Z5739@lynx.no \
    --to=adilger@turbolabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptb@it.uc3m.es \
    /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.