Jim Michaels wrote on Thursday, October 15th, 2009 2:19 PM
> >Jim Michaels wrote on Thursday, October 1st, 2009 2:00 AM
> >> how will RPM deal with large sector drives?
> >IIUC, it is the job of the controller to fake 512-byte sectors, and
> >then
>
> you shouldn't hard-code sector sizes!!
> especially not if you have a spec and you know what you are doing.

I guess you did not understand clearly what is happening.
What *I* code and whether *I* know what I am doing are completely
irrelevant.

RPM 2.38/2.40 was coded by Mikhail Ranish in 1999-2000 and released
February 2001. Muthu did some changes in 2002, but since then there have
not been any live maintainers for the code (Doc Chiron was appointed for
a time, but he haven't been read here for a long time). There is no code
of mine in RPM (except some experiments of mine of some of my old
harddisks.)


> >I do not believe 1KB- or 4KB-sectors would be the solution
> >to the 2TB limit.
<snip>
> Microsoft doesn't care what you think. they are the driving
> force behind the kb article notice they posted on their web
> site warning peoplke and vendors about the coming of large
> sectored disks.

Do you mean about http://support.microsoft.com/kb/923332 ?

If yes, I have to raise two small points:
-- this articles is hardly new: it is mentionned in 2006, and as such
predates the T13 article I pointed out; I read about this article 36
month ago, and even mentionned it
http://tech.groups.yahoo.com/group/partman/message/4743; still, we do
not see many ATA harddrives with 4KB sectors (externally)...
-- this very article explains that at boot ("startup") time, only
512-byte sectors will be considered (and that it is BIOS' or HBA's job
to adapt themselves); the reason of it is probably the size allocated
for MBR code, combined with the requirements for
BitLocker/Palladium/TCPA. Since RPM intervenes before Windows starts up
(and use the same BIOS services), the same point applies. Also, unless
you are doing ugly hacks (like a NTFS partition which extends beyond the
size written in the MBR; or hybrid MBR/GPT setups), the 2TB limit is
still there...

If there is another article, please enlight me.


I also found (sorry for the brocken URL)
http://groups.google.com/group/microsoft.public.development.device.drive
rs/browse_thread/thread/d7e2e80694a28fcd/abdeb35f9fc1e4de to be of
interest.



> >It would be probably MUCH more urgent to address GPT format,
> >which is a vastly better solution to the 2TB barrier...
>
> That's not coming for a while, except maybe with the 64-bit
> machines, which use the EFI instead of BIOS.

Sorry but I disagree. There are many operating systems out there which
support GPT for booting. There is even a mainstream operating system
(MacOSX) which _requires_ GPT (on Intel hardware)...

I agree Microsoft chose to deny GPT booting except for EFI-based board
booting x64 (not 32-bit Windows); as you said, they do not care about my
ideas :^).
I do not know the present state of things with AMD, but I remember they
were opposing the move to EFI; but it was around 2005, and it might pure
politics, or fear of Intel patents, or similar...


> Microsoft was unclear if by 64-bit they mean the itanium
> IA64 servers, which is more likely the case.

Even if Microsoft's marketing might be blurry, it is quite easy to test;
and the testings are clear: x86-32 kernels won't start off GPT (don't
ask me why; this is under research since it appears there are no strong
reasons); IA-64 kernels won't start off MBR; x64 (x86-64) kernels can
start from MBR, and also from GPT since version 6.0.6001 (Vista SP1 or
2008 server).



> >Having said that, I do not see any maintainers for RPM, and
> >it has been this way for the past 5 years at least.
> >So do not hold your breath...
>
> I don't remember seeing it as open source.

Yep. That is the point, since at least 2003.


> AHH!
> I just thought of looking for it on sourceforge.net (what's
> pay software doing on sourceforge?) and I found it under
> http://sf.net/projects/ranish the feature requests and
> patches can be submitted via the nice tracker. except I
> don't know anything about patches,

Thanks to point out to this, I was not aware of it. However both this
project, and http://sf.net/projects/partman, and
http://sf.net/projects/xosl, have empty source repositories. :-(

You probably cannnot create patches unless you have access to the code.
Patching 2.37 (the one which is freely released to the public) is
probably useless since it does not support the BIOS INT13h extensions at
all.


> Nobody has ever submitted a bug report or a feature request
> using the bug tracker. everybody has used the forum to do it

Probably because this forum is referenced from the public website, while
the SF project is not linked in any way I can see (just that the
developper, http://sf.net/users/ranish, is named "Mikhail Ranish", but
I cannot even be sure Mikhail is behind.


> I will take a look at the source code.
> but I don't know how to do too much with assembler due to the
> tight use of registers, and oftentimes code is undocumented.

It is a loooong time since I read the 2.37 source, but I do not remember
the assembler to be too complex: basically it is the MBR and
bootstraping code, and also a helper to address directly IDE disks (this
one you can avoid it) and perhaps some video code. OTOH I am acustomed
to read MBR and x86 assembler code...

2.38 (and probably 2.4x) is another thing, there is the 32-bit extender
in the middle which is almost entirelly coded in assembler...


Antoine