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/
next prev parent 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