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

[Anton Altaparmakov]

On Fri, 2 Jul 2004, Szakacsits Szabolcs wrote:
> On Fri, 2 Jul 2004, Andries Brouwer wrote:
> > On Fri, Jul 02, 2004 at 06:17:53PM +0200, Szakacsits Szabolcs wrote:
> > 
> > > Does anybody find the new HDIO_GETGEO semantic useful? Did it help
> > > _anything_? 
> > 
> > Yes. I do.
> > 
> > There was a steady stream of people reporting on geometry problems.
> > All these problems were caused by kernel guessing stuff.
> 
> True, I'm well aware that old kernels guessed wrong geometries sometimes,
> resulting totally trashed partitions. However far not as much as
> currently. Perhaps the steady stream started also when the HDIO_GETGEO
> semantic was changed and more people started to use 2.5 and 2.6 kernels.
> 
> 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). 
> 
>     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.
> 
> Instead the HDIO_GETGEO change was a non-sense semantic one, AFAIS. It
> doesn't fix anything apparently, only broke _even_ more by not even
> guessing just providing some values.
> 
> Please correct me if I'm wrong.
> 
> > If the kernel no longer volunteers a guess, then we no longer have
> > the situation that the guess can be wrong.
> 
> The problem is, the kernel still _guesses_ (even potential hard coded
> values are guesses). And now it's even more broken than before. 
> 
> This is why I asked _what_ it fixed, not from maintaince but from
> functionality point of view.
> 
> In short, 2.4 was slightly broken, 2.6 is badly broken. Less maintaince
> isn't a good argument because deleting the code would have been a much
> better solution: it wouldn't break so many things and even if it did,
> developers would have notice (function return error that must be always
> handled).
>  
> > The new world is getting much simpler. 
> 
> 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? Then why not error instead?
> 
> > The only case I see where absolutely something is needed is the
> > case of partitioning an empty disk.
> 
> Recovery, cloning, ... just unpack a major distro source and grep for
> HDIO_GETGEO and you'll see how many things use it for all kind of
> purposes.

mkfs (well mkntfs anyway), too...

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/