colinux-devel

[coLinux-devel] Invalid argument zeroing block?

[Richard G. <ric...@ri...>]

On one of my systems I'm having some problems adding a new cobd device. I
tried using Sean's 4gb image, mounted via the xml, used fdisk to put a
partition on it, but then mke2fs (or ext3) bombs out with "Invalid argument
zeroing block 536846320 at end of filesystem". fdisk, cfdisk, and sfdisk all
report that the partitions I create are screwy, like -19349 blocks or
something.

I tried creating a 3gb image by copy /b the Debian 1gb image, but the same
problem happens (different block sizes of course). sfdisk -g (get geometry)
says the kernel can't determine the geometry.

I've done this fine on my work system but doesn't appear to be working on
the home system. I actually already have a cobd0, cobd1, and cobd2, so this
makes cobd3. Has anyone else run into this?


Thanks!
Richard

[PATCH] Re: [coLinux-devel] Invalid argument zeroing block?

[Dan A. <da...@gm...>]

On Sat, Feb 14, 2004 at 08:07:32PM -0600, Richard Goodwin wrote:
> On one of my systems I'm having some problems adding a new cobd device. I
> tried using Sean's 4gb image, mounted via the xml, used fdisk to put a
> partition on it, but then mke2fs (or ext3) bombs out with "Invalid argument
> zeroing block 536846320 at end of filesystem". fdisk, cfdisk, and sfdisk all
> report that the partitions I create are screwy, like -19349 blocks or
> something.
> 
> I tried creating a 3gb image by copy /b the Debian 1gb image, but the same
> problem happens (different block sizes of course). sfdisk -g (get geometry)
> says the kernel can't determine the geometry.
> 
> I've done this fine on my work system but doesn't appear to be working on
> the home system. I actually already have a cobd0, cobd1, and cobd2, so this
> makes cobd3. Has anyone else run into this?

This patch on top of the 0.5.3/linux/patch should address the problem. 

It turns out that cobd was passing wrong information about the device's
size to userspace. Userspace gets the size of the disk in hardsects and
that can only fit into an unsigned long. The previous calculation was
overflowing.

Tested this with a newly created 3gb image, and it seems to be okay.

diff -u linux/drivers/block/cobd.c linux/drivers/block/cobd.c
--- linux/drivers/block/cobd.c	2004-02-14 01:54:01.000000000 +0200
+++ linux/drivers/block/cobd.c	2004-02-16 00:04:44.000000000 +0200
@@ -39,7 +39,7 @@
 		     unsigned int cmd, unsigned long arg)
 {
 	int err;
-	long size;
+	unsigned long size;
 	int dev;
 
 	dev = MINOR(inode->i_rdev);
@@ -55,8 +55,8 @@
 		if (err) 
 			return -EFAULT;
 
-		size = (cobd_sizes[dev] * 1024) / cobd_hardsects[dev];
-		if (copy_to_user((long *) arg, &size, sizeof (long)))
+		size = (cobd_sizes[dev]) * (1024 / cobd_hardsects[dev]);
+		if (copy_to_user((unsigned long *) arg, &size, sizeof (unsigned long)))
 			return -EFAULT;
 
 		return 0;
@@ -139,7 +139,7 @@
 		co_request->type = CO_BLOCK_READ;
 	else
 		co_request->type = CO_BLOCK_WRITE;
-	co_request->offset = req->sector * PBD_BLOCK_SIZE;
+	co_request->offset = ((unsigned long long)req->sector) * PBD_BLOCK_SIZE;
 	co_request->size = req->current_nr_sectors * PBD_BLOCK_SIZE;
 	co_request->address = req->buffer;
 	co_request->rc = 0;
@@ -211,6 +211,7 @@
 		co_block_request_t *request;
 		unsigned long flags;
 		unsigned long long size = 0;
+		long rc = 0;
 	
 		local_irq_save(flags);
 		co_passage_page->operation = CO_OPERATION_DEVICE;
@@ -219,10 +220,17 @@
 		request = (co_block_request_t *)&co_passage_page->params[2];
 		request->type = CO_BLOCK_STAT;
 		co_switch();
+		rc = request->rc;
 		size = request->disk_size;
 		local_irq_restore(flags);
 
-		cobd_sizes[i] = size / 1024;
+		if (!rc) {
+			/* Request successed */
+			cobd_sizes[i] = size / 1024;
+		} else {
+			cobd_sizes[i] = 0;
+		}
+
 		cobd_blksizes[i] = PAGE_SIZE;
 		cobd_hardsects[i] = PBD_BLOCK_SIZE;
 	}



-- 
Dan Aloni
da...@gm...

Re: [PATCH] Re: [coLinux-devel] Invalid argument zeroing block?

[Sean B. <sea...@so...>]

On Sunday 15 February 2004 22:17, Dan Aloni wrote:
> On Sat, Feb 14, 2004 at 08:07:32PM -0600, Richard Goodwin wrote:
> > On one of my systems I'm having some problems adding a new cobd device. I
> > tried using Sean's 4gb image, mounted via the xml, used fdisk to put a
> > partition on it, but then mke2fs (or ext3) bombs out with "Invalid
> > argument zeroing block 536846320 at end of filesystem". fdisk, cfdisk,
> > and sfdisk all report that the partitions I create are screwy, like
> > -19349 blocks or something.
> >
> > I tried creating a 3gb image by copy /b the Debian 1gb image, but the
> > same problem happens (different block sizes of course). sfdisk -g (get
> > geometry) says the kernel can't determine the geometry.
> >
> > I've done this fine on my work system but doesn't appear to be working on
> > the home system. I actually already have a cobd0, cobd1, and cobd2, so
> > this makes cobd3. Has anyone else run into this?
>
> This patch on top of the 0.5.3/linux/patch should address the problem.
>
> It turns out that cobd was passing wrong information about the device's
> size to userspace. Userspace gets the size of the disk in hardsects and
> that can only fit into an unsigned long. The previous calculation was
> overflowing.

Will this patch allow me to boot my real Linux root fs which is 20gb?
- I did try about a week ago but got messages reporting attempts to access 
data beyond the end of the disk.

Cheers.

Disk /dev/hda: 80.0 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/hda2   *         264        2839    20691720   83  Linux

# tune2fs -l /dev/hda2

tune2fs 1.34 (25-Jul-2003)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          390f1859-0a75-4802-a373-5b530026038f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index needs_recovery large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              5131840
Block count:              5172930
Reserved block count:     206917
Free blocks:              909993
Free inodes:              4624578
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32480
Inode blocks per group:   1015
Last mount time:          Sun Feb 15 23:14:11 2004
Last write time:          Mon Feb 16 02:33:32 2004
Mount count:              1
Maximum mount count:      2
Last checked:             Sun Feb 15 23:13:37 2004
Check interval:           15552000 (6 months)
Next check after:         Sat Aug 14 00:13:37 2004
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       3868049
Default directory hash:   tea
Directory Hash Seed:      d6487111-58fe-49d0-9ff5-cb965bec03da