BIOS Reaching Its Limits

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Aug 4, 2010.

  1. I already knew the MBR partition table wasn’t going to handle multi-terabyte
    drives, but it turns out there’s a limitation in the BIOS APIs which will
    prevent bootstrapping code that lies more than 2TiB from the start of the
    drive <http://thread.gmane.org/gmane.linux.kernel/1013911>.

    Looks like the only way forward is to go EFI.
     
    Lawrence D'Oliveiro, Aug 4, 2010
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Enkidu Guest

    On 04/08/10 22:36, Lawrence D'Oliveiro wrote:
    >
    > I already knew the MBR partition table wasn’t going to handle
    > multi-terabyte drives, but it turns out there’s a limitation in the
    > BIOS APIs which will prevent bootstrapping code that lies more than
    > 2TiB from the start of the
    > drive<http://thread.gmane.org/gmane.linux.kernel/1013911>.
    >
    > Looks like the only way forward is to go EFI.
    >

    No, the way forward is to use a small boot partition with a simple boot
    program that loads everything else as the article says. It shouldn't be
    a big deal.

    Cheers,

    Cliff

    --

    The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

    The end excuses any evil - Sophocles
     
    Enkidu, Aug 4, 2010
    #2
    1. Advertising

  3. In article <>, Allistar <> wrote:
    >Enkidu wrote:
    >> On 04/08/10 22:36, Lawrence D'Oliveiro wrote:
    >>> I already knew the MBR partition table wasn’t going to handle
    >>> multi-terabyte drives, but it turns out there’s a limitation in the
    >>> BIOS APIs which will prevent bootstrapping code that lies more than
    >>> 2TiB from the start of the
    >>> drive<http://thread.gmane.org/gmane.linux.kernel/1013911>.
    >>>
    >>> Looks like the only way forward is to go EFI.
    >>>

    >> No, the way forward is to use a small boot partition with a simple boot
    >> program that loads everything else as the article says. It shouldn't be
    >> a big deal.

    >
    >Isn't it just a matter of ensuring that the bootstrapping code is written
    >close enough to the start of the disk? Why would it need to be put >1Tb from
    >the drive start?


    /cynic on/ ... to allow for future versions of windows ?
    /cynin off/

    :)

    I too see no reason why this 'limit' should even be mentioned, let alone be
    a problem. :)
     
    Bruce Sinclair, Aug 5, 2010
    #3
  4. Lawrence D'Oliveiro

    Gordon Guest

    On 2010-08-05, Bruce Sinclair <> wrote:
    > In article <>, Allistar <> wrote:
    >>Enkidu wrote:
    >>> On 04/08/10 22:36, Lawrence D'Oliveiro wrote:
    >>>> I already knew the MBR partition table wasn’t going to handle
    >>>> multi-terabyte drives, but it turns out there’s a limitation in the
    >>>> BIOS APIs which will prevent bootstrapping code that lies more than
    >>>> 2TiB from the start of the
    >>>> drive<http://thread.gmane.org/gmane.linux.kernel/1013911>.
    >>>>
    >>>> Looks like the only way forward is to go EFI.
    >>>>
    >>> No, the way forward is to use a small boot partition with a simple boot
    >>> program that loads everything else as the article says. It shouldn't be
    >>> a big deal.

    >>
    >>Isn't it just a matter of ensuring that the bootstrapping code is written
    >>close enough to the start of the disk? Why would it need to be put >1Tb from
    >>the drive start?

    >
    > /cynic on/ ... to allow for future versions of windows ?
    > /cynin off/
    >
    >:)
    >
    > I too see no reason why this 'limit' should even be mentioned, let alone be
    > a problem. :)
    >
    >

    Yep, who the hell needs more than 64K of memory? Or more than 500MB of HD
    space, or a date past 1999?

    A few barriers, all smashed. This one will be also before it affects Joe
    user
     
    Gordon, Aug 5, 2010
    #4
  5. In message <>, Allistar wrote:

    > Isn't it just a matter of ensuring that the bootstrapping code is written
    > close enough to the start of the disk?


    Yeah, it was “just a matter†of that with previous limits, too, like the
    528MB one.

    > Why would it need to be put >1Tb from the drive start?


    Because you’ve got something else in-between?
     
    Lawrence D'Oliveiro, Aug 5, 2010
    #5
  6. Lawrence D'Oliveiro

    Richard Guest

    Allistar wrote:
    >
    > Isn't it just a matter of ensuring that the bootstrapping code is written
    > close enough to the start of the disk? Why would it need to be put >1Tb from
    > the drive start?


    Recovery partitions are the reason that springs to mind, media direct
    also goes after the main windows partition I think too.
     
    Richard, Aug 5, 2010
    #6
  7. Lawrence D'Oliveiro

    Enkidu Guest

    On 05/08/10 15:57, Bruce Sinclair wrote:
    > In article<>, Allistar<> wrote:
    >> Enkidu wrote:
    >>> On 04/08/10 22:36, Lawrence D'Oliveiro wrote:
    >>>> I already knew the MBR partition table wasn’t going to handle
    >>>> multi-terabyte drives, but it turns out there’s a limitation in the
    >>>> BIOS APIs which will prevent bootstrapping code that lies more than
    >>>> 2TiB from the start of the
    >>>> drive<http://thread.gmane.org/gmane.linux.kernel/1013911>.
    >>>>
    >>>> Looks like the only way forward is to go EFI.
    >>>>
    >>> No, the way forward is to use a small boot partition with a simple boot
    >>> program that loads everything else as the article says. It shouldn't be
    >>> a big deal.

    >>
    >> Isn't it just a matter of ensuring that the bootstrapping code is written
    >> close enough to the start of the disk? Why would it need to be put>1Tb from
    >> the drive start?

    >
    > /cynic on/ ... to allow for future versions of windows ?
    > /cynin off/
    >
    > :)
    >
    > I too see no reason why this 'limit' should even be mentioned, let alone be
    > a problem. :)
    >

    In another branch of the thread the poster quoted by Lawrence concedes
    that EFI is not essential.

    Cheers,

    Cliff

    --

    The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

    The end excuses any evil - Sophocles
     
    Enkidu, Aug 5, 2010
    #7
  8. Lawrence D'Oliveiro

    Matty F Guest

    On Aug 5, 6:11 pm, Gordon <> wrote:
    > On 2010-08-05, Bruce Sinclair <> wrote:
    >
    > > In article <>, Allistar <> wrote:
    > >>Enkidu wrote:
    > >>> On 04/08/10 22:36, Lawrence D'Oliveiro wrote:
    > >>>> I already knew the MBR partition table wasn’t going to handle
    > >>>> multi-terabyte drives, but it turns out there’s a limitation in the
    > >>>> BIOS APIs which will prevent bootstrapping code that lies more than
    > >>>> 2TiB from the start of the
    > >>>> drive<http://thread.gmane.org/gmane.linux.kernel/1013911>.

    >
    > >>>> Looks like the only way forward is to go EFI.

    >
    > >>> No, the way forward is to use a small boot partition with a simple boot
    > >>> program that loads everything else as the article says. It shouldn't be
    > >>> a big deal.

    >
    > >>Isn't it just a matter of ensuring that the bootstrapping code is written
    > >>close enough to the start of the disk? Why would it need to be put >1Tb from
    > >>the drive start?

    >
    > > /cynic on/ ... to allow for future versions of windows ?
    > > /cynin off/

    >
    > >:)

    >
    > > I too see no reason why this 'limit' should even be mentioned, let alone be
    > > a problem. :)

    >
    > Yep, who the hell needs more than 64K of memory? Or more than 500MB of HD
    > space, or a date past 1999?
    >
    > A few barriers, all smashed. This one will be also before it affects Joe
    > user


    Back in 1982 my boss decided that 256 MB hard drives were big enough
    for most customers so in his database he catered for addressing only
    up to that amount. Then we got a customer who wanted a 700 MB drive so
    the boss added an extra byte to addresss up to 65 GB. We should have
    gone straight to addressing 16 TB in 1982 but who would know that?
    As a customer neared the next level of addressing it required a
    horrible conversion program to be run in order to add an extra byte to
    all the addresses in the database indexes.
    Is 4 PB enough? One day it won't be.
     
    Matty F, Aug 5, 2010
    #8
  9. Lawrence D'Oliveiro

    Enkidu Guest

    On 05/08/10 20:43, Matty F wrote:
    > On Aug 5, 6:11 pm, Gordon<> wrote:
    >> On 2010-08-05, Bruce Sinclair<> wrote:
    >>
    >>> In article<>, Allistar<> wrote:
    >>>> Enkidu wrote:
    >>>>> On 04/08/10 22:36, Lawrence D'Oliveiro wrote:
    >>>>>> I already knew the MBR partition table wasn’t going to handle
    >>>>>> multi-terabyte drives, but it turns out there’s a limitation in the
    >>>>>> BIOS APIs which will prevent bootstrapping code that lies more than
    >>>>>> 2TiB from the start of the
    >>>>>> drive<http://thread.gmane.org/gmane.linux.kernel/1013911>.

    >>
    >>>>>> Looks like the only way forward is to go EFI.

    >>
    >>>>> No, the way forward is to use a small boot partition with a simple boot
    >>>>> program that loads everything else as the article says. It shouldn't be
    >>>>> a big deal.

    >>
    >>>> Isn't it just a matter of ensuring that the bootstrapping code is written
    >>>> close enough to the start of the disk? Why would it need to be put>1Tb from
    >>>> the drive start?

    >>
    >>> /cynic on/ ... to allow for future versions of windows ?
    >>> /cynin off/

    >>
    >>> :)

    >>
    >>> I too see no reason why this 'limit' should even be mentioned, let alone be
    >>> a problem. :)

    >>
    >> Yep, who the hell needs more than 64K of memory? Or more than 500MB of HD
    >> space, or a date past 1999?
    >>
    >> A few barriers, all smashed. This one will be also before it affects Joe
    >> user

    >
    > Back in 1982 my boss decided that 256 MB hard drives were big enough
    > for most customers so in his database he catered for addressing only
    > up to that amount. Then we got a customer who wanted a 700 MB drive so
    > the boss added an extra byte to addresss up to 65 GB. We should have
    > gone straight to addressing 16 TB in 1982 but who would know that?
    > As a customer neared the next level of addressing it required a
    > horrible conversion program to be run in order to add an extra byte to
    > all the addresses in the database indexes.
    > Is 4 PB enough? One day it won't be.
    >

    Do you really think that all that data is useful data? With modern
    databases it is easier to store data rather than decide if you really
    need it. How much of the terabytes of data is *ever* read? And it is
    becoming harder and harder to search through those TBs to find what you
    need.

    Cheers,

    Cliff

    --

    The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

    The end excuses any evil - Sophocles
     
    Enkidu, Aug 5, 2010
    #9
  10. Lawrence D'Oliveiro

    Matty F Guest

    On Aug 6, 9:14 am, Enkidu <> wrote:

    > > Is 4 PB enough? One day it won't be.

    >
    > >

    > Do you really think that all that data is useful data? With modern
    > databases it is easier to store data rather than decide if you really
    > need it. How much of the terabytes of data is *ever* read? And it is
    > becoming harder and harder to search through those TBs to find what you
    > need.


    The data was all indexed so it could be found usually in a fraction of
    a second.
    The biggest of the systems were for large insurance companies. They
    had a requirement to display a client's data as at any time from the
    initial policy creation to the present day, no matter how many changes
    had been made. That meant that all changes to the policy had to be
    saved and applied or reversed out as necessary.Also the database held
    changes to be made in the future
    One day it is likely that photos and videos will need to be included
    in the insurance database.
    From a database design point of view it makes sense to allow large
    amounts of data, otherwise it's a nasty process to expand the pointers
    in all the indexes. Another byte or two per index entry is negligible
    these days.
     
    Matty F, Aug 6, 2010
    #10
  11. In article <>, Matty F <> wrote:
    (snip)
    >> Yep, who the hell needs more than 64K of memory? Or more than 500MB of HD
    >> space, or a date past 1999?
    >>
    >> A few barriers, all smashed. This one will be also before it affects Joe
    >> user

    >
    >Back in 1982 my boss decided that 256 MB hard drives were big enough
    >for most customers so in his database he catered for addressing only
    >up to that amount. Then we got a customer who wanted a 700 MB drive so
    >the boss added an extra byte to addresss up to 65 GB. We should have
    >gone straight to addressing 16 TB in 1982 but who would know that?
    >As a customer neared the next level of addressing it required a
    >horrible conversion program to be run in order to add an extra byte to
    >all the addresses in the database indexes.
    >Is 4 PB enough? One day it won't be.


    Quite. And yet, all those other transitions seemed to go smoothly enough.
    :)

    As an aside, I've yet to see anything useful done in 2 GB ram and 300 of
    disk that hasn't been done years ago in an apple II+. OK ... it's a bit
    faster now. :)
     
    Bruce Sinclair, Aug 8, 2010
    #11
  12. Lawrence D'Oliveiro

    Matty F Guest

    On Aug 9, 10:59 am,
    (Bruce Sinclair) wrote:
    > In article <>, Matty F <> wrote:
    > (snip)
    >
    > >> Yep, who the hell needs more than 64K of memory? Or more than 500MB of HD
    > >> space, or a date past 1999?

    >
    > >> A few barriers, all smashed. This one will be also before it affects Joe
    > >> user

    >
    > >Back in 1982 my boss decided that 256 MB hard drives were big enough
    > >for most customers so in his database he catered for addressing only
    > >up to that amount. Then we got a customer who wanted a 700 MB drive so
    > >the boss added an extra byte to addresss up to 65 GB. We should have
    > >gone straight to addressing 16 TB in 1982 but who would know that?
    > >As a customer neared the next level of addressing it required a
    > >horrible conversion program to be run in order to add an extra byte to
    > >all the addresses in the database indexes.
    > >Is 4 PB enough? One day it won't be.

    >
    > Quite. And yet, all those other transitions seemed to go smoothly enough.
    > :)
    >
    > As an aside, I've yet to see anything useful done in 2 GB ram and 300 of
    > disk that hasn't been done years ago in an apple II+. OK ... it's a bit
    > faster now. :)


    In the 1970s, Southern Cross medical insurance was the largest in NZ.
    They got more new clients in a year than all the other companies had
    in total. SC had some 20 or more terminals running in 30 K bytes of
    memory on an IBM mainframe. Response times were less than a fifth of a
    second. I doubt if their new system is as fast.
    Basically the same operating system is still running today, around the
    world. I discovered that it's running in New York at the moment.
     
    Matty F, Aug 9, 2010
    #12
  13. In article <>, Matty F <> wrote:
    >On Aug 9, 10:59 am,

    (snip)

    >> As an aside, I've yet to see anything useful done in 2 GB ram and 300 of
    >> disk that hasn't been done years ago in an apple II+. OK ... it's a bit
    >> faster now. :)

    >
    >In the 1970s, Southern Cross medical insurance was the largest in NZ.
    >They got more new clients in a year than all the other companies had
    >in total. SC had some 20 or more terminals running in 30 K bytes of
    >memory on an IBM mainframe. Response times were less than a fifth of a
    >second. I doubt if their new system is as fast.
    >Basically the same operating system is still running today, around the
    >world. I discovered that it's running in New York at the moment.


    Ah ... terminals. I remember them well. :)
     
    Bruce Sinclair, Aug 10, 2010
    #13
  14. Lawrence D'Oliveiro

    Matty F Guest

    On Aug 10, 11:02 am,
    (Bruce Sinclair) wrote:
    > In article <>, Matty F <> wrote:


    > SC had some 20 or more terminals running in 30 K bytes of
    > >memory on an IBM mainframe. Response times were less than a fifth of a
    > >second. I doubt if their new system is as fast.


    > Ah ... terminals. I remember them well. :)


    Well, they looked similar to the computer monitors that we use today.
    Except that they had green text on black and graphics were minimal.
    Quite adequate for use in many businesses.
    The IBM terminals/monitors weighed so much that two IBM engineers were
    needed to move one.Of course an IBM engineer was required to plug the
    monitor in.
     
    Matty F, Aug 10, 2010
    #14
  15. Lawrence D'Oliveiro

    Enkidu Guest

    On 10/08/10 18:23, Matty F wrote:
    >
    >> Ah ... terminals. I remember them well. :)

    >
    > Well, they looked similar to the computer monitors that we use today.
    > Except that they had green text on black and graphics were minimal.
    > Quite adequate for use in many businesses.
    > The IBM terminals/monitors weighed so much that two IBM engineers were
    > needed to move one.Of course an IBM engineer was required to plug the
    > monitor in.
    >

    IIRC (and I'm not sure that I do) they were powered by the cable that
    also carried the signal, that is they only had one cable.

    Cheers,

    Cliff

    --

    The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

    The end excuses any evil - Sophocles
     
    Enkidu, Aug 10, 2010
    #15
  16. Lawrence D'Oliveiro

    Matty F Guest

    On Aug 10, 10:25 pm, Enkidu <> wrote:
    > On 10/08/10 18:23, Matty F wrote:
    >
    > >> Ah ... terminals. I remember them well. :)

    >
    > > Well, they looked similar to the computer monitors that we use today.
    > > Except that they had green text on black and graphics were minimal.
    > > Quite adequate for use in many businesses.
    > > The IBM terminals/monitors weighed so much that two IBM engineers were
    > > needed to move one.Of course an IBM engineer was required to plug the
    > > monitor in.

    >
    > >

    > IIRC (and I'm not sure that I do) they were powered by the cable that
    > also carried the signal, that is they only had one cable.


    There appear to be the terminals that we used, IBM 3270:
    http://www.columbia.edu/acis/history/3270.html

    I don't remember the cable. I don't think the terminals could be
    unplugged while the controller was connected to the mainframe.
    The 3270 accumulated data until Enter was pressed. That saved
    interrupting the mainframe for each key press.

    However, shortly after that, the system was ported to minicomputers
    and PCs where an interrupt was caused for every keystroke, and they
    were very fast. One guy had 18 monitors running off a 286 PC, and
    response times were under a second.
     
    Matty F, Aug 11, 2010
    #16
  17. In message
    <>, Matty F
    wrote:

    > The 3270 accumulated data until Enter was pressed. That saved
    > interrupting the mainframe for each key press.


    Block-mode terminals. They were expensive, the mainframes were expensive,
    and the megabit-per-second synchronous lines connecting the two were
    expensive.

    DEC and the other vendors of “mini†and “supermini†computers led the charge
    away from this, with their much cheaper machines and terminals, connected by
    low-bandwidth RS-232C lines that interrupted the CPU on every input
    character.

    > However, shortly after that, the system was ported to minicomputers
    > and PCs where an interrupt was caused for every keystroke, and they
    > were very fast. One guy had 18 monitors running off a 286 PC, and
    > response times were under a second.


    It helped that the operating system was designed to cope with the interrupt
    load of interactive operation. I remember a CS lecturer saying that the CPU
    overhead of running a batch-mode operating system was about 15%, that of an
    interactive OS more like 30%. But CPU power was getting so cheap, this
    didn’t matter, and the extra responsiveness that the users got was worth it.
     
    Lawrence D'Oliveiro, Aug 11, 2010
    #17
  18. Lawrence D'Oliveiro

    Enkidu Guest

    On 11/08/10 11:01, Matty F wrote:
    > On Aug 10, 10:25 pm, Enkidu<> wrote:
    >> On 10/08/10 18:23, Matty F wrote:
    >>
    >>>> Ah ... terminals. I remember them well. :)

    >>
    >>> Well, they looked similar to the computer monitors that we use
    >>> today. Except that they had green text on black and graphics were
    >>> minimal. Quite adequate for use in many businesses. The IBM
    >>> terminals/monitors weighed so much that two IBM engineers were
    >>> needed to move one.Of course an IBM engineer was required to plug
    >>> the monitor in.

    >>
    >>>

    >> IIRC (and I'm not sure that I do) they were powered by the cable
    >> that also carried the signal, that is they only had one cable.

    >
    > There appear to be the terminals that we used, IBM 3270:
    > http://www.columbia.edu/acis/history/3270.html
    >
    > I don't remember the cable. I don't think the terminals could be
    > unplugged while the controller was connected to the mainframe. The
    > 3270 accumulated data until Enter was pressed. That saved
    > interrupting the mainframe for each key press.
    >

    Almost correct. The Enter key was only one of a small set of keys called
    AIDs (can't remember what it stood for) such as the PF keys, enter and a
    few others. Hitting one of these keys sent the buffer to the mainframe.

    Cheers,

    Cliff

    --

    The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

    The end excuses any evil - Sophocles
     
    Enkidu, Aug 11, 2010
    #18
  19. Lawrence D'Oliveiro

    Sweetpea Guest

    On Wed, 11 Aug 2010 14:50:28 +1200, Lawrence D'Oliveiro wrote:

    >> However, shortly after that, the system was ported to minicomputers and
    >> PCs where an interrupt was caused for every keystroke, and they were
    >> very fast. One guy had 18 monitors running off a 286 PC, and response
    >> times were under a second.

    >
    > It helped that the operating system was designed to cope with the
    > interrupt load of interactive operation. I remember a CS lecturer saying
    > that the CPU overhead of running a batch-mode operating system was about
    > 15%, that of an interactive OS more like 30%. But CPU power was getting
    > so cheap, this didn’t matter, and the extra responsiveness that the
    > users got was worth it.


    Now PCs using M$ Windows need to be very fast high-spec'd multi-core
    machines just so that a current M$ email client doesn't have noticeable
    lag between typing a key and seeing the corresponding character appear on
    the screen.


    --
    "Filtering the Internet is like trying to boil the ocean"
     
    Sweetpea, Aug 11, 2010
    #19
  20. In message <>, Crash McBash wrote:

    > Poll-select as a networking technology is hugely more efficient by
    > design than networks where terminal key depressions are seen by the
    > server CPU ...


    Interesting use of the term “networkâ€. Simple terminal connections were not
    what we called “networksâ€.
     
    Lawrence D'Oliveiro, Aug 11, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andre
    Replies:
    1
    Views:
    503
    Jack Taugher
    Feb 25, 2005
  2. Greenhorn
    Replies:
    0
    Views:
    422
    Greenhorn
    Apr 1, 2005
  3. Dennis Breithaupt

    EIGRP and its limits

    Dennis Breithaupt, Oct 6, 2005, in forum: Cisco
    Replies:
    2
    Views:
    10,983
    Dennis Breithaupt
    Oct 11, 2005
  4. John Seeliger

    Re: Possible to stop M. Updates from reaching Yahoo?

    John Seeliger, Sep 22, 2003, in forum: Computer Support
    Replies:
    43
    Views:
    1,237
    Blinky the Shark
    Sep 26, 2003
  5. Rick
    Replies:
    1
    Views:
    727
Loading...

Share This Page