Re: Meaning of blk_size

From: Daniel Phillips (news-innominate.list.linux.kernel@innominate.de)
Date: Mon Oct 02 2000 - 12:11:52 EST


Andries Brouwer wrote:
> On Mon, Oct 02, 2000 at 02:33:20AM +0200, Daniel Phillips wrote:
> > On Mon, 02 Oct 2000, Andries Brouwer wrote:
>
> > > [you sounded as if you noticed a discrepancy somewhere - so I expected:
> > > foo.c uses this in line 123 but bar.c uses that in line 666.]
> >
> > No, I'm just trying to understand the meaning of the "+ 1" in ll_rw_block.c,
> > generic_make_request:
> >
> > unsigned long maxsector = (blk_size[major][MINOR(bh->b_rdev)] << 1) + 1;
>
> blk_size[][] gives a block count
> blk_size[][]<<1 gives a sector count
>
> but if the device had an odd number of sectors, the sector count
> is one larger than twice the block count.
>
> (thus, this is not the precisely correct test; the knowledge about
> the number of sectors lives in the dev->sizes array; here we only
> have a rough check)

OK, it's a discrepancy. This is the test used in generic_make_request.
Devices with 512 byte blocks will be able to access one sector past the
blk_size. I wasn't expecting that and that's why I was so confused by
it. The deep problem is the size should be expressed in units of
dev_block_size, not bogosectors.

*** pauses for a moment and wonders what a nice filesystem developer is
doing in a place like this

I have no doubt I'm beating on a horse that has been beaten on many
times in the past. I'll suggest the obvious: there should be a device
table, dev_block_bits[MAX_BLKDEV], initialized by default to 9's. Then
at our leisure we can change over the drivers one by one to use the real
device block size instead of bogosectors and finally kill that ugly
duck. The new improved code will be more efficient because it will get
rid of a lot of multiply/divides by 512. Some device size limitations
will go away. It will certainly be easier to read.

One more question that has probably been asked a lot: why are the
various fields of a device splatted across half a dozen tables instead
of being collected together in a struct and accessed through one table?

Now I'll get out of here and go back to my filesystem. I was checking
the wrong thing in my valid_block function anyway, I should have been
checking against the blocks count in the superblock:

#define valid_block(sb, i) \
  (i < sb->u.ext2_sb.s_blocks_per_group * sb->u.ext2_sb.s_groups_count)

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:10 EST