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
Hello,
Let me invite you to the monthly status meeting taking place last thursday
of this month, 24th of November, 19:00 UTC.
The meeting will be atirc://fezile.reactos.org (Port 6667, no SSL) in the
channel #meeting. Note that the IRC service will only be started shortly
before the meeting. Everyone is invited to listen, and active community
members have their passwords so that they can participate in the
discussion.
If someone still is not getting passwords sent before a meeting - please
email
Colin or Pierre before the meeting started to get one.
Proposed agenda for the meeting:
1. Release status
2. Website revamp status
3. CMake adoption status
More suggestions are welcome as usual.
With the best regards,
Aleksey Bragin.
Is the new geometry backward-compatible? If i recreate the partitions, will they be visible when i regress test revisions before 54511?
--
With best regards
Caemyr
Hi,
due to connectivity issues with our servers in Sweden, I've taken our
rbuild debug buildslave & our KVM testbot offline.
This doesn't affect ISOs storage for the moment.
Regards,
Pierre
I see this and I LMFAO!
co_IntSendMessageNoWait(Window->head.h, WM_WINDOWPOSCHANGING, 0,
(LPARAM) WinPos);
co_IntSendMessageNoWait(WinPos.hwnd, WM_WINDOWPOSCHANGED, 0, (LPARAM) &WinPos);
There is more too! Amazing!
Please tell me this is not wrong!!!!
James
Hi People,
I'm back after my ordeal in Europe and finally got an inet line..
But now I've over 300 mails from the list to wade through.. Ugh.
It's gonna take some time to get up to speed.
Hi Eric,
That's all fine, it's just an educated choice of disk parameters as I see
it.
But anyway, all disk handling software (drivers etc) should honor whatever
disk parameters you write in the boot record when you format the partition,
and whatever geometry you write in the MBR when the disk gets partitioned,
whether it's this or that.
Just in case someone forgot ;)
Best Regards
Love
> From: Eric Kohl <eric.kohl(a)t-online.de>
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Date: Mon, 21 Nov 2011 23:17:40 +0100
> Subject: [ros-dev] Announcement: New harddisk geometry next weekend
> Hi!
>
> I plan to change the standard harddisk geometry from the old 32 sectors
and 64 heads geometry to the > new 63 sectors and 255 heads geometry next
weekend. The old disk geometry was used up to
> Windows NT4 and the new geometry is used since Windows 2000. So I guess
it is time for ReactOS to > make this change too. ;-)
>
> This should improve the compatiibility with other OSs because every
modern OS uses the new disk
> geometry.
>
> Please note that you must delete and re-create all partitions on your
virtual harddisk in order to get
> a clean partition table when the new disk geomerty is in use.
>
> Regards,
> Eric
Am 24.11.2011 01:07, schrieb cgutman(a)svn.reactos.org:
> Author: cgutman
> Date: Thu Nov 24 00:07:15 2011
> New Revision: 54484
>
> URL: http://svn.reactos.org/svn/reactos?rev=54484&view=rev
> Log:
> [SCSIPORT]
> - Implement ScsiPortGetLogicalUnit
>
> Modified:
> trunk/reactos/drivers/storage/scsiport/scsiport.c
>
> ...
> +
> + /* Return the logical unit miniport extension */
> + return (LunExtension + 1);
> }
This looks broken to me. The old code was
"&LunExtension->MiniportLunExtension", which seems to make more sense.
Hi!
I plan to change the standard harddisk geometry from the old 32 sectors
and 64 heads geometry to the new 63 sectors and 255 heads geometry next
weekend. The old disk geometry was used up to Windows NT4 and the new
geometry is used since Windows 2000. So I guess it is time for ReactOS
to make this change too. ;-)
This should improve the compatiibility with other OSs because every
modern OS uses the new disk geometry.
Please note that you must delete and re-create all partitions on your
virtual harddisk in order to get a clean partition table when the new
disk geomerty is in use.
Regards,
Eric