This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Nov 28 13:46:35 2023 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HKNki21215 for ; Tue, 17 Sep 2002 22:23:51 +0200 Received: (qmail 22219 invoked from network); 17 Sep 2002 20:06:44 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by 3ffe:8280:10:360:2e0:4cff:fe39:26ca with SMTP; 17 Sep 2002 20:06:44 -0000 Received: (qmail 18692 invoked by uid 1000); 17 Sep 2002 19:44:25 -0000 MBOX-Line: From linux-kernel-owner@vger.kernel.org Mon Oct 02 17:37:18 2000 Received: (maildatabase); juh Received: (qmail 6851 invoked by alias); 2 Oct 2000 17:37:14 -0000 Received: (qmail 6807 invoked from network); 2 Oct 2000 17:12:42 -0000 Received: from vger.kernel.org (199.183.24.194) by spaans.ds9a.nl with SMTP; 2 Oct 2000 17:12:42 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 2 Oct 2000 13:28:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 2 Oct 2000 13:28:00 -0400 Received: from hermes.mixx.net ([212.84.196.2]:45834 "HELO hermes.mixx.net") by vger.kernel.org with SMTP id ; Mon, 2 Oct 2000 13:27:50 -0400 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A423DF81B for ; Mon, 2 Oct 2000 19:11:52 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 466D82CA6D; Mon, 2 Oct 2000 19:11:52 +0200 (CEST) From: Daniel Phillips Reply-To: Daniel Phillips X-Newsgroups: innominate.list.linux.kernel Subject: Re: Meaning of blk_size Date: Mon, 02 Oct 2000 19:11:52 +0200 Organization: innominate Lines: 53 Distribution: local Message-Id: References: <00100201582602.00767@gimli> <20001002022728.A17106@veritas.com> <00100202491203.00767@gimli> <20001002032923.B17146@veritas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mate.bln.innominate.de 970506712 3862 10.0.0.90 (2 Oct 2000 17:11:52 GMT) X-Complaints-To: news@innominate.de To: Andries Brouwer X-Mailer: Mozilla 4.72 [de] (X11; U; Linux 2.4.0-test8 i586) X-Accept-Language: en To: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org 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/