Loading ...
Sorry, an error occurred while loading the content.
 

handling of large sector drives?

Expand Messages
  • Jim Michaels
    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
    Message 1 of 2 , Sep 30, 2009
      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.
      Jim Michaels




      [Non-text portions of this message have been removed]
    • Antoine Leca
      Jim Michaels wrote on Thursday, October 1st, 2009 2:00 AM ... RPM uses BIOS calls to interface the drive; more precisely, the INT13h, including the IBM/MS
      Message 2 of 2 , Oct 8, 2009
        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.

        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
        (http://www.t13.org/Documents/UploadedDocuments/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.)

        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,
        > 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
      Your message has been successfully submitted and would be delivered to recipients shortly.