public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox