handling of large sector drives?
- how will RPM deal with large sector drives?
they are sure to come out right after the current 2TB disk.
will you need to recode RPM?
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.
[Non-text portions of this message have been removed]
- 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
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
IIUC, it is the job of the controller to fake 512-byte sectors, and then
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
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.)
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...
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 used to hard-code 512-byte sectors into my applications,Hard-coding constants (so-called "magic numbers") never had been a good
> but I don't do that anymore. things like calculating the
> size of the disk is one example.
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.)