what is teh current meaning of blk_size?

what is teh current meaning of blk_size?

[Peter T. Breuer]

Is blk_size[][] supposed to contain the size in KB or blocks?

I'm confused because it looks to me as though it's still in KB,
but people say that devices can be up to 8 or 16TB, and there's
not enough room for that within a signed int containing KB
(2^31 * 2^10 = 2^41 = 2TB).

Either the rumour is true and it's in blocks, or the rumour
is false and it's in KB.

Clue, please!

Peter

Re: what is teh current meaning of blk_size?

[Martin Dalecki]

"Peter T. Breuer" wrote:
> 
> Is blk_size[][] supposed to contain the size in KB or blocks?
> 
> I'm confused because it looks to me as though it's still in KB,
> but people say that devices can be up to 8 or 16TB, and there's
> not enough room for that within a signed int containing KB
> (2^31 * 2^10 = 2^41 = 2TB).
> 
> Either the rumour is true and it's in blocks, or the rumour
> is false and it's in KB.
> 
> Clue, please!

There is no rumor it's in blocks.

There are three level of block size measurements in linux:

1. FS level one.	(page chunks most of time main exceptions are dos and
isofs)
2. Driver level one.	(nearly always 1024, main exception are ATAPI
cdrom)
3. Hardware device level one. (nearly always 512, only prehistoric SCSI
drives from the stone age are exceptional and providing 256 byte sized
block. We discovered them druing our archeological efforts recently
under 
a thick layer of mood...)

It's left as an exercies to the reader which one of the sparse
matrices in ll_rw_blk.c is declaring which ;-).
...

OK I was to fast to figure it out:


/*
 * blk_size contains the size of all block-devices in units of 1024 byte
 * sectors:
 *
 * blk_size[MAJOR][MINOR]
 *
 * if (!blk_size[MAJOR]) then no minor size checking is done.
 */
int * blk_size[MAX_BLKDEV];

/*
 * blksize_size contains the size of all block-devices:
 *
 * blksize_size[MAJOR][MINOR]
 *
 * if (!blksize_size[MAJOR]) then 1024 bytes is assumed.
 */
int * blksize_size[MAX_BLKDEV];

/*
 * hardsect_size contains the size of the hardware sector of a device.
 *
 * hardsect_size[MAJOR][MINOR]
 *
 * if (!hardsect_size[MAJOR])
 *		then 512 bytes is assumed.
 * else
 *		sector_size is hardsect_size[MAJOR][MINOR]
 * This is currently set by some scsi devices and read by the msdos fs
driver.
 * Other uses may appear later.
 */
int * hardsect_size[MAX_BLKDEV];


read_ahead there is a blunt - it's a "write only array anyway"....
Initialize
it to the system default and don't care.

Re: what is teh current meaning of blk_size?

[Peter T. Breuer]

"A month of sundays ago 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.
> 
> There are three level of block size measurements in linux:
> 
> 1. FS level one.	(page chunks most of time main exceptions are dos and
> isofs)
> 2. Driver level one.	(nearly always 1024, main exception are ATAPI
> cdrom)
> 3. Hardware device level one. (nearly always 512, only prehistoric SCSI
> drives from the stone age are exceptional and providing 256 byte sized
> block. We discovered them druing our archeological efforts recently
> under 
> a thick layer of mood...)
> 
> It's left as an exercies to the reader which one of the sparse
> matrices in ll_rw_blk.c is declaring which ;-).
> ...

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.


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

> int * blksize_size[MAX_BLKDEV];
> 
> /*
>  * hardsect_size contains the size of the hardware sector of a device.

Never used. Thanks for clearing that up!

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

Re: what is teh current meaning of blk_size?

[Peter T. Breuer]

"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