From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: ptb@it.uc3m.es
Cc: dalecki@evision.ag, "linux kernel" <linux-kernel@vger.kernel.org>
Subject: Re: what is teh current meaning of blk_size?
Date: Tue, 13 Nov 2001 16:08:34 +0100 (MET) [thread overview]
Message-ID: <200111131508.fADF8Yi09728@oboe.it.uc3m.es> (raw)
In-Reply-To: From (env: ptb) at "Nov 12, 2001 11:10:44 pm"
"ptb wrote:"
> "Martin Dalecki wrote:"
> > "Peter T. Breuer" wrote:
> > > Is blk_size[][] supposed to contain the size in KB or blocks?
> > There is no rumor it's in blocks.
Nevertheless, experiments on 2.4.3 appear to show it is still in KB
there.
> Uh, thanks! I was looking at fs/block_dev.c.
>
> if (blk_size[MAJOR(dev)])
> size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)] << BLOCK_SIZE_BITS) >> blocksize_bits;
>
> which sets the size to the entered blk_size << 10 - blksize_bits.
>
> I missed that BLOCK_SIZE_BITS was constant but blksize_bits is variable.
> Amongst other things.
Thing is, in my driver I have now chenged from setting blk_size to be in KB
and put it in blocks instead (while keeping the blksize the same) and
the result is that using lseek, the device measures to be 1/4 the size
it really is. This is in kernel 2.4.3.
If in look in ll_rw_blk.c, I see, for example:
if (blk_size[major]) {
unsigned long maxsector = (blk_size[major][MINOR(bh->b_rdev)] << 1) + 1;
// (ptb) 1ST SECTOR BEYOND END OF DISK
which implies to me that blk_size is still in KB there.
BTW, I don't know why there should be a +1 at the end. The code goes on
to say:
unsigned long sector = bh->b_rsector; // (ptb) 1ST SECTOR ON DISK
unsigned int count = bh->b_size >> 9; // (ptb) SECTORS IN BUFFER
if (maxsector < count || maxsector - count < sector) {
bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
... good stuff ...
So we look for the nr sectors in the buffer to be _greater_than_
the number of sectors in the device _plus 1_. It should be
_greater_than_or_equal_to ... _plus_1_. But even so it's meaningless.
What we want is to check to see if the buffer contents will overflow
the disk.
I'm not too sure about the other half of the condition either. This
is surely what I mentioned above: sector + count > maxsector?
But again it should be >=. If we are on sector 0 of a 2 sector disk,
and we try and write 3 sectors, then sector=0, count=3, and maxsector=3,
and 0+3 /> 3, so the condition would not trigger, while we want it to.
So it should be >=, not >.
I believe the 1st check is merely a faster calculation and is backed up
by the second check. However, the second check must be right!
> > OK I was to fast to figure it out:
> >
> > /*
> > * blk_size contains the size of all block-devices in units of 1024 byte
> > * sectors:
>
> But this is not so .. it is the default, not the rule. And it is only
> the default if the block size is the default value.
>
> > int * blk_size[MAX_BLKDEV];
> >
> > /*
> > * blksize_size contains the size of all block-devices:
>
> Err .... they mean the BLOCK SIZE of all ...
> If you knew if the meaning of blk_size had ever changed, and when in
> terms of kernel version, that would also be very very helpful.
Peter
next reply other threads:[~2001-11-13 15:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-13 15:08 Peter T. Breuer [this message]
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
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
2001-11-15 10:42 ` blocks or KB? (was: .. current meaning of blk_size array) Anton Altaparmakov
-- strict thread matches above, loose matches on Subject: below --
2001-11-12 19:39 what is teh current meaning of blk_size? Peter T. Breuer
2001-11-12 20:51 ` Martin Dalecki
2001-11-12 22:10 ` Peter T. Breuer
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=200111131508.fADF8Yi09728@oboe.it.uc3m.es \
--to=ptb@it.uc3m.es \
--cc=dalecki@evision.ag \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®