Re: [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff)

[Anton Altaparmakov]

On Fri, 2 Jul 2004, Patrick J. LoPresti wrote:

> Here we go again.
> 
> Szakacsits Szabolcs <address@hidden> writes:
> 
> > Two choices to "fix" this guess game:
> > 
> >     1) return error ("I don't know") but providing compatibility
> >        functionality for things that the kernel knows (e.g. where the
> >        partition starts). 
> 
> As you point out, this will require changes to several userspace
> programs.  It is the correct long term solution, but a deprecation
> period would be nice.
> 
> >     2) use EDD, it does a much better job -- maybe this suggestions
> >        doesn't make much sense overall, so only 1) left if you don't 
> >        want to keep guessing.
> 
> Using EDD to deduce the geometry is the "right" answer.  But this is
> sufficiently complex and special-purpose that it has no place in the
> kernel.
> 
> > Unfortunately it seems it's more messed up. You didn't write any
> > specific why the current situation would be better. What does
> > HDIO_GETGEO returns at present? Hard coded values? Random values?
> 
> Values used by the controller itself.  Also the values you will get
> from the "extended INT13" BIOS interface.  As good a geometry as any,
> unless you plan to dual-boot Windows.

That is not true AFAIK.  EDD reports what the bios reports.  The 
HDIO_GETGEO reports crap and certainly not what EDD reports or at least 
not on any(!) PCs I have tried it.  If HDIO_GETGEO did report what EDD 
reports this thread would probably not need to exist...

> > Then why not error instead?
> 
> Fine idea in the long term, but start by declaring the HDIO_GETGEO
> interface "obsolescent" and spit a warning to syslog when it is used.
> Finding and fixing all the userspace invocations will take some time.
> 
> Right now, HDIO_GETGEO is the only way some applications (e.g., mine)
> can convince Parted to use the right geometry.  So, fix Parted to
> allow the user (i.e., the higher-level partitioning machinery) to
> specify the geometry.  This is the first and last necessary task
> before eliminating Parted's use of HDIO_GETGEO.

What?  HDIO_GETGEO does not convince parted to use the right geometry!  In 
2.6 kernels it convinces parted to use the WRONG geometry and screw your 
data.  That is the whole point!

> > On Fri, 2 Jul 2004, Andries Brouwer wrote:
> >
> > > The only case I see where absolutely something is needed is the
> > > case of partitioning an empty disk.
> > 
> > Recovery, cloning, ...
> 
> ...moving a drive between machines...
> 
> Why does this stupid idea keep coming up?  Inferring the geometry from
> the existing partition table is just plain wrong.  It is even more
> wrong than the old 2.4 behavior, because it is still a guess, just a
> worse guess.

It is not only not wrong but completely correct.  The geometry is really 
something completely made up nowadays.  Nothing really needs it at the low 
level.  But a lot of software still use it.  The important thing is that 
all software on the same system agrees about the geometry of the disk 
otherwise they will conflict and in the worst case loose data (like the 
change in 2.6 kernels to HDIO_GETGEO has caused many a time because of 
parted and other aps taking the values to be the "right" ones but it 
reporting crap).

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/