bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC/PATCH 0/2] support for CMS-formatted disks on the s/390 archite


From: Jim Meyering
Subject: Re: [RFC/PATCH 0/2] support for CMS-formatted disks on the s/390 architecture
Date: Tue, 20 Apr 2010 20:42:07 +0200

Stephen Powell wrote:
...
> debian3:~# parted /dev/dasde print
> Error: can't have overlapping partitions.  <--------------.
> Model: IBM S390 DASD drive (dasd)                         |
> Disk /dev/dasde: 645kB                                    |
> Sector size (logical/physical): 512B/2048B                |
> Partition Table: dasd                                     |
>                                                           |
> Number  Start  End    Size   File system  Flags           |
>  1      6144B  645kB  639kB  ext2                         |
>                                                           |
> debian3:~#                                                |
>                                                           |
> ----------                                                |
>                                                           |
> Notice the first line of output.  ------------------------'
> This example is for an ldl format disk with a block size of 2048.
> The problem seems to be that the pseudo-vtoc overlaps with
> the implicit partition.  In libparted/labels/dasd.c,
> in subroutine dasd_alloc_metadata, we have the statement
>
>    if (disk_specific->format_type == 1)
>            vtoc_end = 23;
>
> Originally, the "start" variable was hard coded as 24; so

Thanks for working on this and outlining the problem.
I've run out of time for today, but will look at this in about 12 hours.

> setting vtoc_end equal to 23 is another place where the
> implicit assumption is being made that start is equal to 24.
> (This works for a block size of 4096 for LDL disks or non-
> reserved CMS disks because 4096/512*3 = 24.)
> vtoc_end should be set to start - 1.  However, this routine
> does not have access to the start variable due to scope of
> names rules.  I tried setting it to start - 1 and got a
> compile-time error.  I don't even know enough about C to tell
> for sure if the start variable has been calculated by then.
> I think it has been, since it is testing the value of
> disk_specific->format_type, which is set inside the dasd_read
> subroutine, which is where the start variable is also calculated.
> But I don't know enough about C to fix this.  Help!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]