Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size) - SCO

This is a discussion on Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size) - SCO ; The thought has hit me in the past and thought I would see what you guys think. If you are running old SCO applications on a new linux box wouldn't we need to concerned with the old 2gb fs limit ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

  1. Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    The thought has hit me in the past and thought I would see what you guys think.

    If you are running old SCO applications on a new linux box wouldn't we need to
    concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    the old inode problems from the old SCO days if the fs was to big??

    bk


  2. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    Brian Keener wrote:
    > The thought has hit me in the past and thought I would see what you guys think.
    >
    > If you are running old SCO applications on a new linux box wouldn't we need to
    > concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    > larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    > the old inode problems from the old SCO days if the fs was to big??
    >
    > bk


    Hello Brian,

    Why would you be concerned? That limit might be the reason you'd move
    to Linux in the first place.

    Unless you're talking about a limitation in your application
    environment...
    As I write that, ISTR that you work in bbx. There's a problem with
    older
    bbx and pro5 interpreters, but I think that has to do with the
    interpreter
    using the wrong inode number to access a file. This is because the old
    interpreters are 16 bit. This problem is seen when there are a large
    number
    of files. You could probably alleviate that by limiting the number of
    inodes
    when you make the filesystem.

    Regards,
    Dan Martin


  3. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    On Thu, Dec 07, 2006, Brian Keener wrote:
    >The thought has hit me in the past and thought I would see what you guys think.
    >
    >If you are running old SCO applications on a new linux box wouldn't we need to
    >concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    >larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    >the old inode problems from the old SCO days if the fs was to big??


    There are two issues here. First is that the linux-abi required
    to run COFF binaries doesn't work on 2.6 Linux kernels, only on
    2.4 and earlier (at least SuSE 9.0 Pro is the latest SuSE version
    I've been able to use for this). Second, many of these
    applications barf if they see file related pointers that are
    larger than the 31 bits available, seeing negative numbers.

    Bill
    --
    INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    ``Find out just what people will submit to, and you have found out the
    exact amount of injustice and wrong which will be imposed upon them; and
    these will continue until they are resisted with either words or blows, or
    both. The limits of tyrants are prescribed by the endurance of those whom
    they oppress.'' -- Frederick Douglass.

  4. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    In article ,
    Brian Keener wrote:
    >The thought has hit me in the past and thought I would see what you guys think.
    >
    >If you are running old SCO applications on a new linux box wouldn't we need to
    >concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    >larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    >the old inode problems from the old SCO days if the fs was to big??


    Apps don't for the most part care how big the filesystem is. I would guess
    you're remembering the 16-bit inode numbers that date from the same era that
    had 2GB filesystem size limits. And yes, you need to worry about that if you
    run an app that cares about inode numbers using files on a filesystem that has
    more than 64K inodes.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  5. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    Bill Campbell wrote:
    > There are two issues here. First is that the linux-abi required
    > to run COFF binaries doesn't work on 2.6 Linux kernels, only on
    > 2.4 and earlier (at least SuSE 9.0 Pro is the latest SuSE versio


    Bill,

    Actually I am using CENTOS 4.2 (which I believe is based On RH9) but I am using
    a 2.6.9-22.0.1 kernel and ABI is working just fine (so far) and they are COFF
    binaries.

    Your second point about the pointers is probably what gets the older BBx's and
    Basics.

    bk


  6. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    Dan Martin wrote:
    > As I write that, ISTR that you work in bbx. There's a problem with
    > older
    > bbx and pro5 interpreters, but I think that has to do with the
    > interpreter
    > using the wrong inode number to access a file. This is because the old
    > interpreters are 16 bit. This problem is seen when there are a large
    > number
    > of files. You could probably alleviate that by limiting the number of
    > inodes
    > when you make the filesystem.


    You are correct - BBx and OpenBasic both had Inode issues with large file
    systems and mine are older versions.

    adn't thought of limiting the inodes and would have to read up on that as I am
    not sure how you would do in Linux.

    bk


  7. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)


    Brian Keener wrote:

    > You are correct - BBx and OpenBasic both had Inode issues with large file
    > systems and mine are older versions.
    >
    > adn't thought of limiting the inodes and would have to read up on that as I am
    > not sure how you would do in Linux.


    Depends on the filesystem: for mk2efs, it's -N

    --
    Tony Lawrence
    Unix/Linux/Mac OS X Resources
    http://aplawrence.com


  8. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    spcecdt@armory.com (John DuBois) hath wroth:

    >In article ,
    >Brian Keener wrote:
    >>The thought has hit me in the past and thought I would see what you guys think.
    >>
    >>If you are running old SCO applications on a new linux box wouldn't we need to
    >>concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    >>larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    >>the old inode problems from the old SCO days if the fs was to big??


    >Apps don't for the most part care how big the filesystem is. I would guess
    >you're remembering the 16-bit inode numbers that date from the same era that
    >had 2GB filesystem size limits. And yes, you need to worry about that if you
    >run an app that cares about inode numbers using files on a filesystem that has
    >more than 64K inodes.


    Methinks BBx does care. See:
    http://www.basis-knowledgebase.com/kb00686.html
    for details. I recently had to transplant a BBx4 based application
    from 3.2v5.0.4 to SUSE 9.3 with linux-abi 2.6.something and found that
    that it would only run in a 2GByte filesystem. I wasted a huge amount
    of time trying several Linux mutations, different filesystems, and did
    battle with Linux-abi 2.4 patches without any luck. Only a <2GByte
    filesystem seems to work.

    Also, please don't remind me of obscure database managers that use a
    raw filesystem for index numbers but were limited to 16 bit inodes and
    pointers. I'm glad that nightmare is over.


    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  9. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    In article <2v3rn2lr9mq6nuo4ja8j7sgd6168aebkht@4ax.com>,
    Jeff Liebermann wrote:
    >spcecdt@armory.com (John DuBois) hath wroth:
    >
    >>In article ,
    >>Brian Keener wrote:
    >>>The thought has hit me in the past and thought I would see what you guys think.
    >>>
    >>>If you are running old SCO applications on a new linux box wouldn't we need to
    >>>concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    >>>larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    >>>the old inode problems from the old SCO days if the fs was to big??

    >
    >>Apps don't for the most part care how big the filesystem is. I would guess
    >>you're remembering the 16-bit inode numbers that date from the same era that
    >>had 2GB filesystem size limits. And yes, you need to worry about that if you
    >>run an app that cares about inode numbers using files on a filesystem that has
    >>more than 64K inodes.

    >
    >Methinks BBx does care. See:
    > http://www.basis-knowledgebase.com/kb00686.html


    That seems to be saying just what I did: the issue is the number of files on
    the filesystem, not the filesystem size. Keep a filesystem of any size under
    64K inodes and you will avoid the 16-bit inode number limitation.

    >for details. I recently had to transplant a BBx4 based application
    >from 3.2v5.0.4 to SUSE 9.3 with linux-abi 2.6.something and found that
    >that it would only run in a 2GByte filesystem. I wasted a huge amount
    >of time trying several Linux mutations, different filesystems, and did
    >battle with Linux-abi 2.4 patches without any luck. Only a <2GByte
    >filesystem seems to work.


    If that really had to do with the 2GB fs size, and not that <2GB fs size
    coincided with <64K inodes, then yes, BBx would be the exception.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  10. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    On Mon, 11 Dec 2006 20:04:11 -0000, spcecdt@armory.com (John DuBois)
    wrote:

    >In article <2v3rn2lr9mq6nuo4ja8j7sgd6168aebkht@4ax.com>,
    >Jeff Liebermann wrote:
    >>spcecdt@armory.com (John DuBois) hath wroth:
    >>
    >>>In article ,
    >>>Brian Keener wrote:
    >>>>The thought has hit me in the past and thought I would see what you guys think.
    >>>>
    >>>>If you are running old SCO applications on a new linux box wouldn't we need to
    >>>>concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    >>>>larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    >>>>the old inode problems from the old SCO days if the fs was to big??

    >>
    >>>Apps don't for the most part care how big the filesystem is. I would guess
    >>>you're remembering the 16-bit inode numbers that date from the same era that
    >>>had 2GB filesystem size limits. And yes, you need to worry about that if you
    >>>run an app that cares about inode numbers using files on a filesystem that has
    >>>more than 64K inodes.

    >>
    >>Methinks BBx does care. See:
    >> http://www.basis-knowledgebase.com/kb00686.html

    >
    >That seems to be saying just what I did: the issue is the number of files on
    >the filesystem, not the filesystem size. Keep a filesystem of any size under
    >64K inodes and you will avoid the 16-bit inode number limitation.


    As far as I can read between the lines, the number of files problem
    mentioned has to do with the probability of hitting a duplicate inode
    number for given file. Obviously, the more files in the filesystem,
    the higher the probability.

    >>for details. I recently had to transplant a BBx4 based application
    >>from 3.2v5.0.4 to SUSE 9.3 with linux-abi 2.6.something and found that
    >>that it would only run in a 2GByte filesystem. I wasted a huge amount
    >>of time trying several Linux mutations, different filesystems, and did
    >>battle with Linux-abi 2.4 patches without any luck. Only a <2GByte
    >>filesystem seems to work.


    >If that really had to do with the 2GB fs size, and not that <2GB fs size
    >coincided with <64K inodes, then yes, BBx would be the exception.


    It's not the exception when the problem was to move the BBx4
    application to a different operating system. As I vaguely recall, the
    filesystem had only about 2,000 files, mostly programs. BBx4 likes
    LOTS of tiny files for programs that constantly load, unload, re-load,
    unload, etc. Quite a light show on the HD light. When I was doing my
    testing, the number of files was constant so I couldn't tell if that
    had an effect. However, the only thing that worked was a 2GB
    filesystem with <64K inodes.

    --
    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831-336-2558 jeffl@comix.santa-cruz.ca.us
    # http://802.11junk.com jeffl@cruzio.com
    # http://www.LearnByDestroying.com AE6KS

  11. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    From what I remember the main issue for BBx and such was the number of inodes
    and it would start accessing the wrong files. Tell it to open one file and you
    got something else. Cannot vouch for the 2gb filesystem although as others
    have said I remember it in relation to the number of inodes.

    Brings up another thought as well though - if I have a linux machine with an
    8gb drive/partition and then another 2gb drive/partition. In this case I am
    booting from the 8gb and the 2gb is only there because of these softwares with
    2gb limits. When I mount the 2gb to /u on the / directory of the 8gb drive
    what it the software on the 2gb drive going to see if I restrict them to the /u
    directory IE do not open anything below /u - with the logical inodes and fs
    still be within my limits. Along this same thought it would seem the normal
    practice of installing BBx in say the /usr directory might be a mistake (since
    that would be the 8gb fs and I would want to install in /u where the 2gb drive
    is mounted.

    bk



  12. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    Brian Keener wrote:
    > The thought has hit me in the past and thought I would see what you guys think.
    >
    > If you are running old SCO applications on a new linux box wouldn't we need to
    > concerned with the old 2gb fs limit from SCO machines. IE with the newer and
    > larger disk drives wouldn't we want a 2gb fs for the linux machine to prevent
    > the old inode problems from the old SCO days if the fs was to big??
    >
    > bk
    >

    This is an old thread I know, but why not just format a partition as
    fat32 which Linux can use transparently, and has a 2GB filesize limit?

  13. Re: Old SCO 3.2v4.2 Programs on a Linux machine (Filesystem size)

    Stabby wrote:
    > This is an old thread I know, but why not just format a partition as*
    > fat32 which Linux can use transparently, and has a 2GB filesize limit?


    I guess I missed something here because I am not sure I understand this. I
    have old SCO Unix Application that I will be running on Linux using Linux ABI
    and in the old days the SCO Systems had a 2gb limit. If I was going to create
    a fat32 with a 2gb why not create a standard linux partition at 2gb and limit
    the inodes especially since I have always thrown in the complication of using
    Linux ABI.

    bk



+ Reply to Thread