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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Maybe Matching Threads
- sfdisk: No more Cylinder / Head / Sector support in util-linux 2.26 and later
- [PATCH] daemon: parted: use --part-type with recent sfdisk
- How to Backup and Restore MBR within Logical Volumes?
- Questions on qcow, qcow2 versus LVM
- Unclear documentation on 'numeric' and 'integer' (R-lang.pdf)