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

RE: [partman] Re: Ranish yields incorrect cylinder count?

Expand Messages
  • Antoine Leca
    ... Yes... This is what the ATA-6 standard mandates... Useless for a disk bigger than 8GB (I mean, CHS addressing is useless nowadays: remember this label is
    Message 1 of 12 , Sep 4, 2006
    • 0 Attachment
      > The disk drive itself says on the label:
      >
      > 16383 cyl......16 Heads.........63Sec/T

      Yes... This is what the ATA-6 standard mandates... Useless for a disk
      bigger than 8GB (I mean, CHS addressing is useless nowadays: remember
      this label is intended for people which are inserting the disk in a PC
      without "auto-detect" and which need to enter the values into the
      CMOS... ah, was the g'd 'ld days ;-).)


      > Ranish 2.40 says:
      >
      > HD 1 (128) 38,146M [ 5,167 cyls x 240 heads x 63 sects = 78,125,040
      > sects ]
      >
      > with the problem partition as:
      >
      > 6 Pri 4 82 5,088 0 1 5,167 239 63 76,930,560 1,209,600
      > 78,140,159
      >
      > Ranish wants the ending cylinder number to be 5,166, not 5167, because
      > it starts with 0. By Ranish count there are 1,240,080 cyls.
      >
      > Linux says that there are also 240 heads but 5,168 cyls.

      OK.
      As I said, since Ranish does not make tricks (AFAIK) with disk geometry,
      this all boils down to BIOS reporting 5,167 cylinders while the ATA
      interface says 5,168.

      And since you're indicating further down that the BIOS is branded IBM, I
      am not overall surprised :-). Seems that IBM engineers really want to
      "save" a cylinder for their own use (testing), was true back in 1982 for
      the XT, still true in 2006 :-))).

      Another way to check is to check with the disk maker. I do not believe
      it will give you the "cylinder" count however, just the "raw" count of
      sectors. But I am pretty sure you'll find 78,140,160...


      > > Also please indicates which BIOS is involved.
      >
      > The computer is a Thinkpad 600E notebook with latest IBM Bios for this
      > 2645 4BU model : Bios INET36WW. The drive is an Hitachi 40 gig
      > Travelstar (replacement for the original drive).

      You could have a look at the web to see if this difference is already
      known; I guess you could ask IBM too, if you have a way to get at "real"
      support (not just the marketing people...)


      > > > I also note that when I reduce the number of cylinders in
      > > > ranish, it still shows an area of free space after the last
      > > > partition, but of zero length. This also seems odd.
      > >
      > > Now yes, this seems very odd. :-( Assuming you're speaking about 0
      > > sectors (if it is just some sectors less than a full size
      > > cylinder, it is probably because of rounding, though.)

      This still puzzles me, on the other hand. I will try it (using
      "simulation" mode as soon as I got some time to investigate). This
      really looks a rounding problem with Ranish.


      <blah blah blah> part -p -r,
      >
      > will do this as soon as you can give me a way to get the data to you.
      > Can't do it in Yahoo so far :-(

      Don't worry with the formatting: since we know how the format should be,
      it should not be too much of a problem to perform the reformatting
      ourselves. In fact, it is just to understand precisely what is this
      "area of zero length" in Ranish that makes you wonder.


      Antoine
    • vtdiy
      Antoine it shows up on the screen view, not the printout view. Therefore I cannot give it to you unless this group somehow allows posting a screenshot. It
      Message 2 of 12 , Sep 4, 2006
      • 0 Attachment
        Antoine it shows up on the screen view, not the printout view.

        Therefore I cannot give it to you unless this group somehow allows
        posting a screenshot.

        It would seem that the photo area would be a reasonable place to do
        this. However this group is so locked down, it's nearly impossible to
        do anything. Messages take a week alone

        oh nevermind...


        > <blah blah blah> part -p -r,
        > >
        > > will do this as soon as you can give me a way to get the data to you.
        > > Can't do it in Yahoo so far :-(
        >
        > Don't worry with the formatting: since we know how the format should be,
        > it should not be too much of a problem to perform the reformatting
        > ourselves. In fact, it is just to understand precisely what is this
        > "area of zero length" in Ranish that makes you wonder.
        >
        >
        > Antoine
        >
      • doc_chiron
        Doc Chiron here: Start out by knowing the number of LBA sectors on the drive, either by reading it off of a label, or from the mfr s website. If they were
        Message 3 of 12 , Sep 6, 2006
        • 0 Attachment
          Doc Chiron here:
          Start out by knowing the number of LBA sectors on the drive, either by
          reading it off of a label, or from the mfr's website. If they were
          bought out, the info should still be available from the new owners.

          There are basically two ways a program can request drive capacity info;
          by asking the drive itself providing the OS permits access (DOS yes,
          NT+ no), or by requesting that info from the governing software (the OS
          NT+) or the BIOS (e.g. DOS).

          When a program gets the info itself from the drive, it has to decide
          what logical CHS parameters it wants to make available to software
          requests for disk I/O using CHS parameters. Depending on the sector
          translation scheme it chooses to adopt, specifically the number of
          heads per cylinder, will determine the total number of cylinders.
          Also, although most modern BIOS' use 255 heads per cylinder, there are
          still a fair number that use 240 instead.

          RPM (Ranish) gets its drive info from a BIOS call, an extended call if
          supported. That BIOS call tells RPM the CHS configuration that the BIOS
          has chosen (influenced by BIOS setup options for LBA, LARGE and NORMAL).
          It also tells RPM whether the drives PHYSICAL addressing is CHS or LBA.
          Although RPM may learn the cylinder count from that call, the fact that
          it has access to the total LBA count allows it to calculate the
          remaining tracks of any partial last cylinder, which it rounds down to
          the nearest whole track (only complete 63 sector tracks).

          It is the BIOS that determines whether it will reserve the last
          cylinder for use as either a landing zone or diagnostic cylinder. Any
          program that ignores the BIOS parameters may choose to make that
          cylinder available.

          Remember that high level OSes usually bypass the BIOS for hardware I/O
          to operate in 32bit (protected) mode, so they are not bound by BIOS
          settings or the Disk Parameter Table.

          This site (among many others), describes the above in detail:
          http://www.allensmith.net/Storage/HDDlimit/Address.htm
          HTH Doc
        • doc_chiron
          Doc Chiron here: I m using the YahooGroup supplied Rich Text Editer (beta), to see what happens when it reaches our group. It is the group owner that chooses
          Message 4 of 12 , Sep 6, 2006
          • 0 Attachment
            Doc Chiron here:

            I'm using the YahooGroup supplied Rich Text Editer (beta), to see what
            happens when it reaches our group. It is the group owner that chooses to
            restrict content to text-only .

            That MAY also be true for attachments as well, but I haven't looked it
            up lately.

            The loss of tabular formatting is a side affect of Yahoo!'s white space
            compressor that doesn't permit consecutive space characters. If you use
            any displayable character to hold that space (I use a period) you can
            get tabular data displayed. Although the RPM screen uses all of the 80
            columns of the 720x400 text-mode, Yahoo! only displays about 66-72
            char's per line, so you need to squeeze the text horizontally.

            Hope that helps, Doc



            [Non-text portions of this message have been removed]
          • vtdiy
            Yes, I could reformat tabular data with periods if I had tabular data. I have a screen shot, that is image pixel data, because the problem shows up on the
            Message 5 of 12 , Sep 10, 2006
            • 0 Attachment
              Yes, I could reformat tabular data with periods if I had tabular data.

              I have a screen shot, that is image pixel data, because the problem
              shows up on the screen, not in the part -p -r text file, as I mentioned.

              I don't really want to try to recreate the whole screen by hand with
              its upper and lower sections, LBA modes etc, particularly with the
              number of chars per line of these messages. I'm not into ASCII art.

              This is weird. We've got a group File section that is off-limits to
              group members. We have a Photos section that is off-limits to group
              members. We have a "rich text" editor that doesn't allow images, or
              tables, or attachments. We have email scripts that eliminates
              everything but text.

              Other Yahoo groups I belong to allow users to post pictures of
              themselves, their projects, pdf files of manuals and stories, plans,
              etc. What are we protecting so rigidly? That plus the long lead time
              between approval and posting of responses really hurts the usefulness
              of this group. Users can't post photos in the user photo section? That
              would solve the screenshjot problem.






              --- In partman@yahoogroups.com, "doc_chiron" <doc_chiron@...> wrote:
              >
              >
              > Doc Chiron here:
              >
              > I'm using the YahooGroup supplied Rich Text Editer (beta), to see what
              > happens when it reaches our group. It is the group owner that chooses to
              > restrict content to text-only .
              >
              > That MAY also be true for attachments as well, but I haven't looked it
              > up lately.
              >
              > The loss of tabular formatting is a side affect of Yahoo!'s white space
              > compressor that doesn't permit consecutive space characters. If you use
              > any displayable character to hold that space (I use a period) you can
              > get tabular data displayed. Although the RPM screen uses all of the 80
              > columns of the 720x400 text-mode, Yahoo! only displays about 66-72
              > char's per line, so you need to squeeze the text horizontally.
              >
              > Hope that helps, Doc
              >
              >
              >
              > [Non-text portions of this message have been removed]
              >
            • vtdiy
              We re specifically talking fdisk in Linux, and Ranish Partition Manager here. Both report the same number of heads so the 240/255 question doesn t apply. One
              Message 6 of 12 , Sep 10, 2006
              • 0 Attachment
                We're specifically talking fdisk in Linux, and Ranish Partition
                Manager here.

                Both report the same number of heads so the 240/255 question doesn't
                apply. One reports one more total number of tracks than the other.

                I have already indicated the HD label's contents.

                Do we absolutely positively know for sure that Ranish reads the BIOS
                to determine the number of tracks/cyls, and absolutely for sure know
                that it isn't off in this reading by one? Or are we conjecturing that
                *probably* this is the case?

                I want to know what is causing the discrepency, not what is possibly
                causing the discrepency.

                Why. Because it has a critical importance to my (and others) data and
                systems.

                If a BIOS needs to reserve a final track for some critical function, I
                don't want my Linux installation to overwrite that track. In that case
                Ranish is behaving correctly, and Linux users should be warned quite
                clearly about this possibility. Maybe Linux fdisk should be rewritten
                or written to produce a warning.

                If on the other hand Ranish is mistaken in the total number of (full)
                tracks available due to a numeric BIOS read error, it would have
                little practical effect (and have remained unnoticed as a bug) as long
                as you stayed within the Ranish partitioning system, except for a
                minor loss of storage space.

                But as soon as you try to install Linux, and partition, you will run
                into this discrepency, and receive false error messages from Ranish.
                And those error messages may cause you to try to correct your Linux
                system to one fewer cylinder -- which will unfortunaley cause it to
                error with a "size doesn't match signature" error. You can't just play
                it safe with one fewer cyinder after installation.

                So I want to know what is *actually* happening, not just a guess at
                what is probably happening, or advice to just make the disk one cyl
                smaller to make Ranish Partman happy.

                Because the screen display is weird with the extra 0 length partition,
                I want to be really clear that Partman isn't reacting incorrectly with
                regard to the end of the disk, and that there isn't some bug causing
                the disk cyl number discrepency. That's why I would have liked to post
                actual OUTPUT, rather than a typed up representation.





                --- In partman@yahoogroups.com, "doc_chiron" <doc_chiron@...> wrote:
                >
                > Doc Chiron here:
                > Start out by knowing the number of LBA sectors on the drive, either by
                > reading it off of a label, or from the mfr's website. If they were
                > bought out, the info should still be available from the new owners.
                >
                > There are basically two ways a program can request drive capacity info;
                > by asking the drive itself providing the OS permits access (DOS yes,
                > NT+ no), or by requesting that info from the governing software (the OS
                > NT+) or the BIOS (e.g. DOS).
                >
                > When a program gets the info itself from the drive, it has to decide
                > what logical CHS parameters it wants to make available to software
                > requests for disk I/O using CHS parameters. Depending on the sector
                > translation scheme it chooses to adopt, specifically the number of
                > heads per cylinder, will determine the total number of cylinders.
                > Also, although most modern BIOS' use 255 heads per cylinder, there are
                > still a fair number that use 240 instead.
                >
                > RPM (Ranish) gets its drive info from a BIOS call, an extended call if
                > supported. That BIOS call tells RPM the CHS configuration that the BIOS
                > has chosen (influenced by BIOS setup options for LBA, LARGE and NORMAL).
                > It also tells RPM whether the drives PHYSICAL addressing is CHS or LBA.
                > Although RPM may learn the cylinder count from that call, the fact that
                > it has access to the total LBA count allows it to calculate the
                > remaining tracks of any partial last cylinder, which it rounds down to
                > the nearest whole track (only complete 63 sector tracks).
                >
                > It is the BIOS that determines whether it will reserve the last
                > cylinder for use as either a landing zone or diagnostic cylinder. Any
                > program that ignores the BIOS parameters may choose to make that
                > cylinder available.
                >
                > Remember that high level OSes usually bypass the BIOS for hardware I/O
                > to operate in 32bit (protected) mode, so they are not bound by BIOS
                > settings or the Disk Parameter Table.
                >
                > This site (among many others), describes the above in detail:
                > http://www.allensmith.net/Storage/HDDlimit/Address.htm
                > HTH Doc
                >
              • Antoine Leca
                [ If your agent still hasn t told you, this is LOOOOONG post. ] ... Only reading the source (or the binary) of your own copy can you be _sure_. Even Mihail or
                Message 7 of 12 , Sep 12, 2006
                • 0 Attachment
                  [ If your agent still hasn't told you, this is LOOOOONG post. ]

                  > Do we absolutely positively know for sure that Ranish reads
                  > the BIOS to determine the number of tracks/cyls, and
                  > absolutely for sure know that it isn't off in this reading by
                  > one? Or are we conjecturing that *probably* this is the case?

                  Only reading the source (or the binary) of your own copy can you be
                  _sure_. Even Mihail or Muthu cannot say for sure.
                  See also http://www.acm.org/classics/sep95/: "You can't trust code that
                  you did not totally create yourself" (K.Thompson, the author of UNIX,
                  when awarded by ACM.)

                  However, we have very strong hints it is indeed the case:
                  - the simulation version use datas from a configuration file, these
                  datas are the BIOS ones (unmodified inside the program);
                  - old version 2.37 (open source, the source is within the zip archive),
                  while in 16 bits and with a different logic, did use the BIOS (and
                  failed to know about LBA, that's why it is not any more in use);
                  - beta versions 2.38 (same as 2.40), which were distributed with source,
                  though hard to find, also use BIOS as a base, without any modification;
                  I would be very surprised if this were modified afterwards;
                  - any experimentations made by other persons, including on disks
                  declared with 240 cylinders, did not show this off-by-one while within
                  RPM; and it was tested along with more than two tools (I currently
                  tested about 6 similar programs on many disks, and never saw any case
                  where RPM reports something different as what the BIOS told).

                  So, while I cannot be fully affirmative, there are very few probability
                  the problem lies within RPM ;-).


                  > I want to know what is causing the discrepency, not what is
                  > possibly causing the discrepency.

                  I would test with other tools to learn what the BIOS tells. This way you
                  will be more reassured.
                  you could give a try at FreeDOS' FDISK, I believe it should give you the
                  information. Try FDISK 1 /INFO, or something like that. Source is given,
                  so this way you can be pretty sure it is indeed the BIOS which is used
                  in FDISK, so use that to corroborate RPM vs. Linux fdisk differences.
                  <URL:http://www.23cc.com/free-fdisk/>


                  <ADVANCED-READINGS>
                  You can learn (much) more this about reading
                  http://www.sandersonforensics.com/manual.htm; the tool itself
                  (http://www.sandersonforensics.com/bxdr.htm) is/was priced GBP 100.
                  Another point of view, with a definitive Linux bias, is in
                  http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html, covering in
                  particular HPA (read also about BEER and PARTIES; yes, the name are
                  correct.)
                  </ADVANCED-READINGS>


                  > If a BIOS needs to reserve a final track for some critical
                  > function, I don't want my Linux installation to overwrite
                  > that track.

                  OK, now this is going more philosophical.
                  At the beginning (t'was '82), IBM engineers, when faced with the vast
                  (when compared to a 360K floppy) space of a fixed disk, choose to set
                  apart the last cylinder (605th) for testing purpose. It also nullified
                  many off-by-one error, which is a Good Thing(tm). In the same time, the
                  people who wrote the testing tools (Diagnostics) did not feel the right
                  to erase (possibly user) datas on the last cylinder, so about no test
                  program I know of are using destructively the last cylinder.
                  This situation was noticed by the hackers, and when they were in hurry
                  of more space (you know, Nature Abhors A Vacuum), you find they can
                  extend the partition to use the last cylinder as well; it was the very
                  beginning of those partition programs, we are still discussing today
                  ;-).

                  Later (I believe around 1993), some engineers did notice this (I vaguely
                  remember reading things this about, related with either Phoenix or IBM,
                  but I did not experiment it myself), and started to "hide" the last
                  cylinder at BIOS Int 13-08 level (that is, one level before); it could
                  also have been caused by some widely used tool which had an off-by-one
                  bug dealing with cylinders, so reporting one cylinder less fixed it. Of
                  course, as soon as the ATA (IDE) standard was common place, the trick
                  was fooled again, and the "unduely stolen" space was "restored" to the
                  "right" use... by the hackers (it may be some comments this about in the
                  Linux kernel.)

                  Later again, around ATA-5 definition ('99), the same idea was re-used
                  again to create HPA a.k.a. BEER+PARTIES. Again, it is one level
                  "before", this time the trick is protected by ATA interface (when
                  operated normally). It is space at the end of the disk which are
                  "reserved" for system use (usually recovery).
                  Contrary to the former uses, however, it is not usually a cylinder but
                  rather several GB! And also contrary to the former, do _not_ use this
                  space unless you know what you are doing (this is of real concern for
                  ThinkPad, which seem to be the principal users of this feature).
                  I do not feel from the informations you provided that this case applies
                  to you.

                  As a result, I do not believe there is a real NEED for BIOS to reserve a
                  cylinder (and it is certainly not critical); it was more a forecasted
                  need in my eyes, which was never actually enacted (HPA is different
                  here.)


                  > In that case Ranish is behaving correctly, and
                  > Linux users should be warned quite clearly about this
                  > possibility. Maybe Linux fdisk should be rewritten or written
                  > to produce a warning.

                  I guess it is MUCH too late for this. Linux fdisk behaves this way for
                  more than 10 years (back when it was hackerland-only), and I do not see
                  the point to revert on this now.
                  In fact, the Linux practice is so widely present that it is reverse
                  behaviour, i.e. using the last cylinder for testing purpose without
                  warning, which is certain to cause harm; just see the fuss created by
                  Intuit's 2002 TurboTax protection scheme inside track 0...


                  [...]
                  > But as soon as you try to install Linux, and partition, you
                  > will run into this discrepency, and receive false error
                  > messages from Ranish.

                  Bzzz. No. What causes these messages is rather to use TWO partition
                  programs, Linux fdisk and RPM. And it is well known that using two
                  partition programs is a good cause for confusion, as these programs are
                  not designed in an interoperable scheme, they more likely would take
                  complete ownership... (and RPM is no exception here.)

                  Bottom line: stick with only one tool. Preferably the more recent.


                  Also, I do not feel they are error messages, rather warnings. For
                  example, in a similar situation (partition table extends beyond BIOS
                  views), Partition Magic will not allow you to even _start_ the program.
                  RPM, being more technical, does, but warns you it feels you are in a
                  insecure condition, and allows you to correct it as far as it can. Since
                  it does not know about IDE parameters, RPM does not distinguish between
                  your case, and the case I alluded before of a partition tool making a
                  off-by-on error.
                  Remember that with RPM, you are not required to resolve ANY of the red
                  conditions indicated: while the program feels it is better to do so,
                  there are cases you should allow the things to stay as they are, even in
                  red. A typical exemple is the disk number in the FAT boot records, for a
                  disk you mounted as second to fix it: it reports as 128 (which is
                  correct when you'll restore it in its proper place), but RPM is
                  insisting to have 129 instead, to allow chain booting, even if very few
                  people use this "feature".


                  > And those error messages may cause you
                  > to try to correct your Linux system to one fewer cylinder --
                  > which will unfortunaley cause it to error with a "size
                  > doesn't match signature" error.

                  I am not sure I got you. Please correct me if appropriate.

                  The size of a volume is recorded in two places: one if the partition
                  structure (dealt with by RPM or fdisk), and the other is the volume
                  super block (or the boot record, if you prefer). RPM knows how to deal
                  with FAT superblocks, and gives you warnings when things do not match.
                  However, it does not know about ext2fs (or NTFS) superblocks. OTOH,
                  fdisk knows about nothing about superblocks, you have to "adjust" them
                  separately. If, after "installation", you reduce the size of the
                  partition container, you also have to a<djust down the size of the
                  volume in its superblock, otherwise while loading the kernel will
                  (rightly) warns you about a (quite dangerous) mismatch.


                  [...]
                  > That's why I would have liked to post actual OUTPUT,
                  > rather than a typed up representation.

                  Yes, I got that, and I agree with you on this one.
                  However, if it proves to be impossible to publish the screenshot on the
                  group, I guess it is certainly possible to publish it anywhere else on
                  the Internet (including within the services provided for free by Yahoo.)
                  I agree it is inconvenient, but as you may now be aware, the moderators
                  of the group (Mikhail and Muthu) are not active any more; in fact, it is
                  the whole RPM which is hardly evolving any more.


                  Antoine
                • doc_chiron
                  Doc Chiron here: doc: Hey you, VTDIY, cool it with the tantrum already. I realize that like the rest of us, you like to have just the facts, maam , but unless
                  Message 8 of 12 , Sep 13, 2006
                  • 0 Attachment
                    Doc Chiron here:

                    doc: Hey you, VTDIY, cool it with the tantrum already. I realize
                    that like the rest of us, you like to have "just the facts, maam",
                    but unless Mikhail or Muthu respond personally, you'll have to go by
                    the "preponderence of the evidence" rather than "beyond a shadow of
                    a doubt" on this.

                    Before I forget, the more recent versions of TESTDISK may be used to
                    corroborate the findings of other disk utilities and I'm sure there
                    are many others you can check with.

                    --- In partman@yahoogroups.com, "Antoine Leca" <aleca@...> wrote:

                    > <ADVANCED-READINGS>
                    > You can learn (much) more this about reading
                    > http://www.sandersonforensics.com/manual.htm;
                    > the tool itself (http://www.sandersonforensics.com/bxdr.htm)
                    > is/was priced GBP 100.

                    > Another point of view, with a definitive Linux bias, is in
                    > http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html, covering in
                    > particular HPA...

                    Doc: Antoine has it correct with this reference.
                    When it comes to the last (BIOS RESERVED) cylinder, the BIOS has
                    decided for you whether it will allow you access to it using its
                    call services. In order for Linux to over-rule the BIOS, it must be
                    bypassing the BIOS and providing its own replacement disk I/O
                    routines. To maintain compatibility with DOS that uses BIOS calls,
                    Windows has in general kept with the BIOS cylinder count for
                    compatibility.
                    From what you report about the Linux FDISK cylinder count being one
                    higher than the BIOS count (as seen in RANISH), I'm guessing that
                    Linux is treating you like a grown-up and letting you decide whether
                    you want to use that cylinder or not. I think there is very little
                    likelihood that you will encounter any problems except for disk
                    utilities that strictly go by the BIOS cylinder count (e.g.
                    PartitionMagic).
                    The same holds true for beginning the first partition at CHS 0,0,2.
                    Read this in addition to Antoines link:
                    http://www.win.tue.nl/~aeb/linux/Large-Disk-6.html#ss6

                    HTH Doc
                  Your message has been successfully submitted and would be delivered to recipients shortly.