>Jim Michaels wrote on Thursday, October 1st, 2009 2:00 AM
>> how will RPM deal with large sector drives?
>
>RPM uses BIOS calls to interface the drive; more precisely, the INT13h,
>including the IBM/MS extensions, also known as (Phoenix) "Enhanced Disk
>Drive Specification" .
>Furthermore, I believe the code blindly assumes 512-byte sectors,
>particularly since the "normal", CHS-based, INT 13h (AH=8,
>http://www.delorie. com/djgpp/ doc/rbinter/ id/27/6.html) does not provide
>a way to describe the sector size; and recording that RPM 2.4x is
>contemporaneous of the transition from the CHS-based to the LBA-based
>model.

bolderdash - int 13h function 48h check out data offset 24 details describe
sector size in bytes

>
>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.
see bottom of this email for a spec in pdf format.

>the software should take care to issue write requests for several,
>aligned, sectors such as they match the physical size of the media; at
>least this is the model advocated by T13
>(http://www.t13. org/Documents/ UploadedDocument s/docs2007/ e05122r5- ACS_In
>formative_annex_ on_Long_Sectors. pdf), and it makes much sense.
>
>> they are sure to come out right after the current 2TB disk.
>
>I do not believe 1KB- or 4KB-sectors would be the solution to the 2TB
>limit. First and most important, because it is very short-sighted: 1KB
>is good for 18 months, and even 4KB (16 TB) only is good for 4-5 years,
>ie less than the lifetime of a typical box: not worthwhile an effort,
>knowing that the "correct" solution (64-bit sector number) is already
>known, as is the probable design (GPT.)

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. and since microsoft is driving it, the disk
manufacturers are sure to follow, since they drive motherboard manufacture and
use of BIOS or EFI as well. large sectors are coming. just a matter of when.
and I wouldn't be surprised if it's just aroung the corner.
so don't just sit around doing tech support - fix your code now.

>
>The real motivation for it (long-sector, big-sector) is not the 2TB
>barrier, but rather the quest to deal inside the drive with extended
>sector size to reduce the extra informations to be stored for error
>correction, thus improving density and hence lowering the end price (for
>a given capacity.) Any other thing this about (performance, etc.) is
>probably pure marketing speech.
>
>> will you need to recode RPM?
>
>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. Microsoft was unclear if by 64-bit they mean the
itanium IA64 servers, which is more likely the case. those machine I know are
already using the EFI. Windows 7 and Windows Vista can both utilize EFI+GPT I
think, but I don't think that makes any difference here.


>
>Anyway, in case of large sector drive, the main problem for RPM would be
>of dimensioning the buffers right: if you do not and goes on with a
>512-bytes buffer for the MBR, the very first thing RPM does after
>switching to protected mode is to read the MBR; and if the BIOS delivers
>4096 bytes (with only 512 being useful), I am sure awful things shall
>occur! Similarly when you move partitions, etc.
>
>Then there are cosmetics, because the size would be wrongly displayed
>(ie halved or divided by eight): the working of partionning use sector
>numbers all over the place, and the size of the sector does not change
>significantly the business; a notable exception to that is the part
>which deal with FAT volumes: reading FAT volumes build elsewhere with
>big sectors is likely to give false results, and the format option will
>create a strange volume, probably unusable. Still, I am sure there are
>plenty of tools and operating systems out there which do have the same
>defects, and that for this very reason the T13 commitee does NOT
>advocate for such a change.
>
>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.
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, I would have to look that up in the sf.net
documentation. It might require the patch utility to do that, if you happen to
have a local copy.


Nobody has ever submitted a bug report or a feature request using the bug
tracker.
everybody has used the forum to do it - possibly that is why nothing got done.
the proper method is probably to use the bug tracker under the Develop tab.
This of course requires a sourceforge login.

I formally put in a bug report and a feature request.
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.
The bug tracker was empty!
2 new bug reports, one for EFI+GPT, and one for 512-byte sectors.
https://sourceforge.net/tracker/?func=detail&atid=595239&aid=2879756&group_id=90\
901
https://sourceforge.net/tracker/?func=detail&atid=595239&aid=2879768&group_id=90\
901



>
>> I used to hard-code 512-byte sectors into my applications,
>> but I don't do that anymore. things like calculating the
>> size of the disk is one example.
>
>Hard-coding constants (so-called "magic numbers") never had been a good
>thing: that is one of the second most important reasons why manifest
>constants were invented in the first place (the topmost reason being
>configurability, of course.)
>
>Once said that, having replaced 512 by SECT_SIZE within your code does
>not buy you much if you are not able to know the actual value to put
>instead of 512 behind the SECT_SIZE label... (and yes, I did learn while
>writing this post that the EDS specs do provide the information. )
>
>Antoine









bolderdash.

Get drive parameters
Entry:
AH - 48h
DL - Drive number
DS:SI - address of result buffer.
Exit:
carry clear
AH - 0
DS:SI - address of result buffer
carry set
AH - error code
This function returns physical device parameters. It is mandatory regardless of
the interface subset which is
supported. Table 3 defines the result buffer. On entry the first word of the
result buffer must be the bufer length in
bytes.

...
4 Double word Number of physical cylinders. This is 1 greater than the maximum
cylinder number. Use Int 13h Fn 08h to find the logical number of cylinders.
8 Double word Number of physical heads. This is 1 greater than the maximum head
number. Use Int 13h Fn 08h to find the logical number of heads.
12 Double word Number of physical sectors per track. This number is the same as
the maximum sector number because sector addresses are 1 based. Use Int 13h Fn
08h to find the logical number of sectors per track.
16 Quad word Number of physical sectors. This is 1 greater then the maximum
sector number. If this
field is greater than 15,482,880 then word 2, bit 1 is cleared to 0.
*24 Word Number of bytes in a sector.
...


Phoenix Int13 enhanced spec. It seemed to work on the ASUS machines with old
AMI BIOS I had running DOS with the diskwipe software I wrote.
I found the URL for the int13h enhanced spec pdf.
http://www.phoenix.com/NR/rdonlyres/19FEBD17-DB40-413C-A0B1-1F3F560E222F/0/specs\
edd30.pdf
http://JesusnJim.com/pc-repair/large-sector-drives.html

Jim Michaels





[Non-text portions of this message have been removed]