Re: [ros-dev] HDD Geometry switch

[Love Nystrom]

Olaf, please don't leave, the project needs you just
as much as it needs the developers.
Eric, Olaf's regression testing can not entail patching/rebuilding
the system to accomodate disk structure (as you surely realize).
That said, your reasons for change are sound, but perhaps you
can make provisions to temporarily revert this if it causes massive
problems. The timing _is_ not good if indeed a release is close
at hand.. Can it wait until after the release?
Alex, calling Olaf "not an OS tester" is a bit harsh, don't you think?
Not everyone can be as weather hardened and experienced as you are.
Regarding the reasons for change:
Max CHS capacity: 10 bit C, 6 bit S, 8 bit H
2^10 * 2^6 * 255 == 16711680 sect(512) == 8.5 GB
This is the geometry Eric wants to use, which makes sense
because it can utilize the full CHS addressing capacity,
and reflects the absolute limit of BIOS int 13h CHS calls.
Previous 32S 64H CHS limit:
2^10 * 32 * 64 == 2097152 sect(512) == 1 GB
This is an artificial and unnecessary limit, imposed by some
strange design decision in Redmond a long long time ago.
For non-devs: In CHS mode BIOS has an absolute disk limit of 8.5 GB,
due to the available address bits, a 10/6 bit Cylinder/Sector composite,
and an 8 bit head number. Any disk bigger than that can only be addressed
in LBA mode (logical sector nr), which has a limit of 2^32 sectors == 2 TB.
And, if anyone didn't know, the geometry parameters are stored
in the boot sector, not in the MBR.
There's more to it, but I stop at that.
So.. Eric's change _should_ not cause any problem on disks
larger than 8.5 GB, since they run in LBA mode by necessity.
Concordingly, there could be forseeable problems on virtual disks
which will often be smaller than 8 GB and may be running CHS mode.
That'll be my penny to the pot for now.
PS. A standard sector is 512 bytes. Bigger sectors, e.g 1kB, have been used
in the past to increase capacity, but are _very_ unusual since they require
proportionately higher bit frequencies on the media and are error-prone.
Best Regards
// Love

[chris]

RE: virtual disks, just place a note on the website and on the readme.txt found on the
bootcd and tell people that they need to create a virtual machine that is 8 gigabytes or
larger.its not rocket science.
  ----- Original Message -----
  From: Love Nystrom
  To: ros-dev(a)reactos.org
  Sent: Wednesday, November 30, 2011 2:25 PM
  Subject: Re: [ros-dev] HDD Geometry switch
  Olaf, please don't leave, the project needs you just
  as much as it needs the developers.
  Eric, Olaf's regression testing can not entail patching/rebuilding
  the system to accomodate disk structure (as you surely realize).
  That said, your reasons for change are sound, but perhaps you
  can make provisions to temporarily revert this if it causes massive
  problems. The timing _is_ not good if indeed a release is close
  at hand.. Can it wait until after the release?
  Alex, calling Olaf "not an OS tester" is a bit harsh, don't you think?
  Not everyone can be as weather hardened and experienced as you are.
  Regarding the reasons for change:
  Max CHS capacity: 10 bit C, 6 bit S, 8 bit H
  2^10 * 2^6 * 255 == 16711680 sect(512) == 8.5 GB
  This is the geometry Eric wants to use, which makes sense
  because it can utilize the full CHS addressing capacity,
  and reflects the absolute limit of BIOS int 13h CHS calls.
  Previous 32S 64H CHS limit:
  2^10 * 32 * 64 == 2097152 sect(512) == 1 GB
  This is an artificial and unnecessary limit, imposed by some
  strange design decision in Redmond a long long time ago.
  For non-devs: In CHS mode BIOS has an absolute disk limit of 8.5 GB,
  due to the available address bits, a 10/6 bit Cylinder/Sector composite,
  and an 8 bit head number. Any disk bigger than that can only be addressed
  in LBA mode (logical sector nr), which has a limit of 2^32 sectors == 2 TB.
  And, if anyone didn't know, the geometry parameters are stored
  in the boot sector, not in the MBR.
  There's more to it, but I stop at that.
  So.. Eric's change _should_ not cause any problem on disks
  larger than 8.5 GB, since they run in LBA mode by necessity.
  Concordingly, there could be forseeable problems on virtual disks
  which will often be smaller than 8 GB and may be running CHS mode.
  That'll be my penny to the pot for now.
  PS. A standard sector is 512 bytes. Bigger sectors, e.g 1kB, have been used
  in the past to increase capacity, but are _very_ unusual since they require
  proportionately higher bit frequencies on the media and are error-prone.
  Best Regards
  // Love
------------------------------------------------------------------------------
  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Adam]

I have been watching the stuff on this mailing list for some time now.
Please bear in mind this is a public mailing list and the public (such
as me) can view this.
It will not do well for the reputation of this project to continuously
flare up unnecessary drama. Also baseless assumptions and exaggerations
are no good. So lets forget about what happened, move on, learn from
mistakes, etc.
I do not see how it was even warranted and I am not going to post who
started it, but I do think Alex has a very good point. Especially given
the OS is *pre-alpha* one should expect data loss when testing. I see
nothing harsh about his statement at all. Also what's the new geometry
going to affect other than having to recreate the partitions again?
Right... now onto the real stuff...
I for one welcome Eric's change. Though I could suggest do as some
other OSes (eg. OpenBSD) store/look for the information on disk, on
the boot block or something *if possible* (I believe FAT boot sector
actually stores this information (sectors/head and sectors/track) in
0x18 and 0x1A)
http://www.ntfs.com/fat-partition-sector.htm) so maybe in future one
could consider utilizing this information.
Just a suggestion.
On Wed, 30 Nov 2011 11:25:21 +0700
Love Nystrom <love.nystrom(a)gmail.com> wrote:
>   Olaf, please don't leave, the project needs you
> just
>  as much as it needs the developers.
>  Eric, Olaf's regression testing can not entail patching/rebuilding
>  the system to accomodate disk structure (as you surely realize).
>  That said, your reasons for change are sound, but perhaps you
>  can make provisions to temporarily revert this if it causes massive
>  problems. The timing _is_ not good if indeed a release is close
>  at hand.. Can it wait until after the release?
>  Alex, calling Olaf "not an OS tester" is a bit harsh, don't you think?
>  Not everyone can be as weather hardened and experienced as you are.
>  Regarding the reasons for change:
>  Max CHS capacity: 10 bit C, 6 bit S, 8 bit H
>  2^10 * 2^6 * 255 == 16711680 sect(512) == 8.5 GB
>  This is the geometry Eric wants to use, which makes sense
>  because it can utilize the full CHS addressing capacity,
>  and reflects the absolute limit of BIOS int 13h CHS calls.
>  Previous 32S 64H CHS limit:
>  2^10 * 32 * 64 == 2097152 sect(512) == 1 GB
>  This is an artificial and unnecessary limit, imposed by some
>  strange design decision in Redmond a long long time ago.
>  For non-devs: In CHS mode BIOS has an absolute disk limit of 8.5 GB,
>  due to the available address bits, a 10/6 bit Cylinder/Sector
>  composite, and an 8 bit head number. Any disk bigger than that can
>  only be addressed in LBA mode (logical sector nr), which has a limit
>  of 2^32 sectors == 2 TB. And, if anyone didn't know, the geometry
>  parameters are stored in the boot sector, not in the MBR.
>  There's more to it, but I stop at that.
>  So.. Eric's change _should_ not cause any problem on disks
>  larger than 8.5 GB, since they run in LBA mode by necessity.
>  Concordingly, there could be forseeable problems on virtual disks
>  which will often be smaller than 8 GB and may be running CHS mode.
>  That'll be my penny to the pot for now.
>  PS. A standard sector is 512 bytes. Bigger sectors, e.g 1kB, have
>  been used in the past to increase capacity, but are _very_ unusual
>  since they require proportionately higher bit frequencies on the
>  media and are error-prone.
>  Best Regards
>  // Love

[James Tabor]

Hi!
Well good news! Testing with my good old hardware, I noticed the
Extended partition drive D came back!!!! The last time this happen,
was before Alexs kernel changes!!!
It's been a long time,
James