Re: Block device/ext2fs filesystem size problems in 2.0.36/2.0.38

From: Guest section DW (dwguest@win.tue.nl)
Date: Sat Jan 15 2000 - 21:18:43 EST


On Sat, Jan 15, 2000 at 07:12:10PM +0000, Kieran wrote:

> # hdparm -g /dev/hdc
>
> /dev/hdc:
> geometry = 1048/255/63, sectors = 16841664, start = 0
>
> I am trying to create a second Linux installation on the second disk.
> Unfortunately, when I get to the step involving mke2fs, the partition
> size is reported wrongly. Let me show you my partition table (normal
> format and expert format)
>
> Command (m for help): p
>
> Disk /dev/hdc: 255 heads, 63 sectors, 1048 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/hdc1 * 1 9 72261 83 Linux
> /dev/hdc2 10 73 514080 83 Linux
> /dev/hdc3 74 583 4096575 5 Extended
> /dev/hdc4 584 1048 3735112+ 83 Linux
> /dev/hdc5 74 456 3076416 83 Linux
> /dev/hdc6 457 482 208813+ 83 Linux
> /dev/hdc7 483 508 208813+ 83 Linux
> /dev/hdc8 509 525 136521 82 Linux swap
> /dev/hdc9 526 583 465853+ 83 Linux
>
> My problem occurs when I try to make a filesystem on a logical partition
> on the second disk. Basically, mke2fs tries to make at least one
> filesystem of size 700m-800m. It can be the case that the partition is
> either much bigger (~3gb) or much smaller (~200mb).

I hate error reports where people tell me "basically, ...".
Please show the verbatim output. (In the case of mke2fs omit
this list of block numbers.)
What commands do you give? Why do you think anything is wrong?
In the data you show here, all is perfect.
(Although I agree that 200 millibits is very little for a 700 meter filesystem.)

> Initially, I had a large logical partition exhibiting this behaviour.
> When I made this a primary partition instead, the small partition's size
> was "inflated".
>
> I have used the following program versions (among others)
>
> # fdisk -v
> fdisk v2.10b
> # mke2fs
> mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09

> [[ Addendum: (from Nix <nix@esperi.demon.co.uk>)
>
> This was checked with lib/ext2fs/tst_getsize.c from e2fsprogs-1.18
> and a tiny program doing a similar job of our own devising, both of
> which agree that the problem is due to the BLKGETSIZE ioctl()
> returning the wrong value. It occurs to me that this may be an
> LBA-related screwup in drivers/block/ide.c:current_capacity().

But what does it mean "returning the wrong value"?
Please tell what value it returns, and what value you would have preferred.

> # hdparm -I /dev/hdc
>
> /dev/hdc:
>
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16841664
>
> # hdparm -i /dev/hdc
>
> /dev/hdc:
>
> Model=ST38420A, FwRev=3.07, SerialNo=7AZ0G8JB
> RawCHS=16708/16/63, TrkSize=0, SectSize=0, ECCbytes=0
> CurCHS=1048/255/63, CurSects=16841664, LBA=yes, LBAsects=16841664
>
> I note that curCHS is being remapped, but I can't see how this could
> cause any problems. Is this drive known to be screwy with LBA? If so,
> is it possible to turn it off?

Since this letter does not show a single thing that is wrong,
it is difficult to guess what would repair the hypothetical problem.

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



This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:13 EST