sfdisk -g support in DomU

sfdisk -g support in DomU

[Nick Logan]

Back in January there was a mail thread on this subject ( 
http://lists.xensource.com/archives/html/xen-devel/2005-01/msg00659.html 
), however I see that blkfront still does not include ioctl support for 
disk geometry. So, any application that uses "sfdisk -g" to get the 
geometry of a partition, or disk, will fail when run in DomU.

Is this a deliberate omission?

Nick Logan

RE: sfdisk -g support in DomU

[Ian Pratt]

> Back in January there was a mail thread on this subject ( 
> http://lists.xensource.com/archives/html/xen-devel/2005-01/msg
> 00659.html
> ), however I see that blkfront still does not include ioctl 
> support for disk geometry. So, any application that uses 
> "sfdisk -g" to get the geometry of a partition, or disk, will 
> fail when run in DomU.
> 
> Is this a deliberate omission?

Most people tend to import block devices as partitions rather than whole
disks, so often there isn't a 'whole disk' device to interogate (though
I guess a partition table for it could be faked out if anyone really
cared). Importing partitions rather than whole disks makes resizing of
indidual partitions easier. 

When a whole disk is being imported, I guess it would make sense to
fabricate a geometry based on the size. Patches welcome...

Best,
Ian 

Re: sfdisk -g support in DomU

[Gerd Knorr]

>> support for disk geometry. So, any application that uses 
>> "sfdisk -g" to get the geometry of a partition, or disk, will 
>> fail when run in DomU.
>>
>> Is this a deliberate omission?

IMHO the applications should be fixed to not depend on the disk 
geometry.  There is LBA addressing for disks since ages, all the CHS 
addressing you still find are some more or less random, artificial 
values picked to satisfy prehistoric software ;)

> Most people tend to import block devices as partitions rather than whole
> disks, so often there isn't a 'whole disk' device to interogate (though
> I guess a partition table for it could be faked out if anyone really
> cared). Importing partitions rather than whole disks makes resizing of
> indidual partitions easier.

I prefeare whole disks, works fine for me, nobody seems to care much 
about the geometry these days:

localhost ~ # cat /proc/partitions
major minor  #blocks  name

  202     0    4194304 xvda
  202     1    3750000 xvda1
  202     2     250000 xvda2
localhost ~ # parted /dev/xvda print
Disk geometry for /dev/xvda: 0kB - 4295MB
Disk label type: msdos
Number  Start   End     Size    Type      File system  Flags
1       1kB     3840MB  3840MB  primary   ext2
2       3840MB  4096MB  256MB   primary   linux-swap
Information: Don't forget to update /etc/fstab, if necessary.

localhost ~ # sfdisk -l /dev/xvda
Disk /dev/xvda: cannot get geometry

Disk /dev/xvda: 0 cylinders, 0 heads, 0 sectors/track
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0

    Device Boot Start   End    MiB    #blocks   Id  System
/dev/xvda1         0+  3662-  3663-   3750000   83  Linux
/dev/xvda2      3662+  3906-   245-    250000   82  Linux swap / Solaris
/dev/xvda3         0      -      0          0    0  Empty
/dev/xvda4         0      -      0          0    0  Empty
localhost ~ #

The only issue I trapped into so far is that the yast2 installer 
appearently doesn't like disks which have neither some geometry nor an 
existing partition table ...

cheers,

   Gerd

RE: sfdisk -g support in DomU

[Ian Pratt]

> The only issue I trapped into so far is that the yast2 
> installer appearently doesn't like disks which have neither 
> some geometry nor an existing partition table ...

Yep, I've seen this, which probably suggests we should address it.

Ian 

RE: sfdisk -g support in DomU

[Adam Heath]

On Wed, 16 Nov 2005, Ian Pratt wrote:

> > Back in January there was a mail thread on this subject (
> > http://lists.xensource.com/archives/html/xen-devel/2005-01/msg
> > 00659.html
> > ), however I see that blkfront still does not include ioctl
> > support for disk geometry. So, any application that uses
> > "sfdisk -g" to get the geometry of a partition, or disk, will
> > fail when run in DomU.
> >
> > Is this a deliberate omission?
>
> Most people tend to import block devices as partitions rather than whole
> disks, so often there isn't a 'whole disk' device to interogate (though
> I guess a partition table for it could be faked out if anyone really
> cared). Importing partitions rather than whole disks makes resizing of
> indidual partitions easier.

We import whole disks; nfsroot for /(not really an import, but listed for
completeness here), hdb for swap, hdc for /tmp.

Re: sfdisk -g support in DomU

[Nick Logan]

Gerd Knorr wrote:

>
> IMHO the applications should be fixed to not depend on the disk 
> geometry.  There is LBA addressing for disks since ages, all the CHS 
> addressing you still find are some more or less random, artificial 
> values picked to satisfy prehistoric software ;)
>
Agreed, but it does mean that some prehistoric (mature) software will 
not run unchanged in DomU.