SCO qurks - SCO

This is a discussion on SCO qurks - SCO ; As I slowly learn the rudiments of working with OSR 5.0.7, I'm struck by: 1. How often SCO's documentation of what files reside in which directories is wrong. It's really slowed my progress. (Thank heaven for Samba and the find ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: SCO qurks

  1. SCO qurks

    As I slowly learn the rudiments of working with OSR 5.0.7, I'm struck by:

    1. How often SCO's documentation of what files reside in which directories
    is wrong. It's really slowed my progress. (Thank heaven for Samba and the
    find command!) Most of this misinformation seems to be many months and even
    many years old. (Any company that doesn't maintain its documrentation
    deserves to die.) By contrast, in my years of working with Novell NetWare,
    an equally qurky tech-only OS, I rarely found documentation errors; it might
    be convoluted, but was rarely wrong. Microsoft's documentation, though
    often incomplete, is also rarely wrong.

    2. How slow its filesystem is. An internal 7000DLT tape drive that's hung
    on a SCSI-3 bus stops and starts during cpio backup and restore operations.
    DLT7000's are very fast; I guess that the tape drive has emptied the
    operating system's buffers. A similar SCSI adapter/DLT tape drive in a
    NetWare server streamed on and off the tape without pause.

    My question regarding point 2 is: Is there a method of increasing the buffer
    size(s) when doing cpio operations to and from tape? (I've set the block
    size to 65536 kB.)



    TIA,
    Arby




  2. Re: SCO qurks


    "Arby" wrote in message
    news:Bb6dnVXymfHvup3anZ2dnUVZ_r2nnZ2d@giganews.com ...
    >
    > My question regarding point 2 is: Is there a method of increasing the
    > buffer size(s) when doing cpio operations to and from tape? (I've set the
    > block size to 65536 kB.)


    Correction: 65536 BYTES



  3. Re: SCO qurks

    On Sun, 30 Sep 2007 19:06:06 -0400, "Arby"
    wrote:

    >
    >"Arby" wrote in message
    >news:Bb6dnVXymfHvup3anZ2dnUVZ_r2nnZ2d@giganews.com ...
    >>
    >> My question regarding point 2 is: Is there a method of increasing the
    >> buffer size(s) when doing cpio operations to and from tape? (I've set the
    >> block size to 65536 kB.)

    >
    >Correction: 65536 BYTES
    >


    man cpio, specifically looking for the -C option.

    HTH


    Scott McMillan

  4. Re: SCO qurks


    "Scott McMillan" wrote in message
    news:66t1g3tp741ae8lpg9ecnfl620gbnsoa7l@4ax.com...
    > On Sun, 30 Sep 2007 19:06:06 -0400, "Arby"
    > wrote:
    >
    >>
    >>"Arby" wrote in message
    >>news:Bb6dnVXymfHvup3anZ2dnUVZ_r2nnZ2d@giganews.com ...
    >>>
    >>> My question regarding point 2 is: Is there a method of increasing the
    >>> buffer size(s) when doing cpio operations to and from tape? (I've set
    >>> the
    >>> block size to 65536 kB.)

    >>
    >>Correction: 65536 BYTES
    >>

    >
    > man cpio, specifically looking for the -C option.
    >
    > HTH
    >
    >
    > Scott McMillan


    Thanks, I've tried -C65536 and -C131072, without seeing great results: the
    DLT7000 tape drive still starts and stops while executing cpio -o. On a
    similar spec CPU/motherboard/disk system (both the SCO and the NetWare
    server feed the DLT7000 tape drive through a dedicated Adaptec 2940UW
    PCI-based SCSI adapter.) - based NetWare 3.12 server, I see continuous
    streaming on- and off- the DLT7000 tape drive. On that server I use CA
    Arcserve, with buffer size set to 64KB (I think . . . maybe it's only 16KB).
    In fact, I can keep that tape drive streaming continuously even when backing
    up remote servers over a 100 MB/s cable (when using CA Arcserve's push
    agents on the remote servers).

    Has anyone run files i/o benchmarks on SCO vs NetWare?

    I found this interesting snippet on SCO's site:
    http://www.sco.com/developers/hdk/te...0/hbacert.html
    "We recommend 150M tape drive for the multiple-volume cpio test. High
    capacity drives (e.g., DLT drives) are not recommended at this time because
    of performance issues."

    My guess is that the "performance issues" are related to their operating
    system, not the DLT tape drives.

    -Arby



  5. Re: SCO qurks

    In article , Arby
    writes
    >
    >"Scott McMillan" wrote in message
    >news:66t1g3tp741ae8lpg9ecnfl620gbnsoa7l@4ax.com...
    >> On Sun, 30 Sep 2007 19:06:06 -0400, "Arby"
    >> wrote:
    >>
    >>>
    >>>"Arby" wrote in message
    >>>news:Bb6dnVXymfHvup3anZ2dnUVZ_r2nnZ2d@giganews.com ...
    >>>>
    >>>> My question regarding point 2 is: Is there a method of increasing the
    >>>> buffer size(s) when doing cpio operations to and from tape? (I've set
    >>>> the
    >>>> block size to 65536 kB.)
    >>>
    >>>Correction: 65536 BYTES
    >>>

    >>
    >> man cpio, specifically looking for the -C option.
    >>
    >> HTH
    >>
    >>
    >> Scott McMillan

    >
    >Thanks, I've tried -C65536 and -C131072, without seeing great results: the
    >DLT7000 tape drive still starts and stops while executing cpio -o. On a
    >similar spec CPU/motherboard/disk system (both the SCO and the NetWare
    >server feed the DLT7000 tape drive through a dedicated Adaptec 2940UW
    >PCI-based SCSI adapter.) - based NetWare 3.12 server, I see continuous
    >streaming on- and off- the DLT7000 tape drive. On that server I use CA
    >Arcserve, with buffer size set to 64KB (I think . . . maybe it's only 16KB).
    >In fact, I can keep that tape drive streaming continuously even when backing
    >up remote servers over a 100 MB/s cable (when using CA Arcserve's push
    >agents on the remote servers).
    >
    >Has anyone run files i/o benchmarks on SCO vs NetWare?
    >
    >I found this interesting snippet on SCO's site:
    >http://www.sco.com/developers/hdk/te...hbacert/6.0.0/
    >hbacert.html
    >"We recommend 150M tape drive for the multiple-volume cpio test. High
    >capacity drives (e.g., DLT drives) are not recommended at this time because
    >of performance issues."
    >
    >My guess is that the "performance issues" are related to their operating
    >system, not the DLT tape drives.
    >
    >-Arby
    >
    >


    In the past when I have had streaming issues with tapes I have piped the
    cpio through dd and out to the tape.

    Don C



  6. Re: SCO qurks


    "Donald Campbell" wrote in message
    news:wxRYJuCzdUCHFAjs@suedonltd.demon.co.uk...
    > In article , Arby
    > writes
    >>
    >>"Scott McMillan" wrote in message
    >>news:66t1g3tp741ae8lpg9ecnfl620gbnsoa7l@4ax.com...
    >>> On Sun, 30 Sep 2007 19:06:06 -0400, "Arby"
    >>> wrote:
    >>>
    >>>>
    >>>>"Arby" wrote in message
    >>>>news:Bb6dnVXymfHvup3anZ2dnUVZ_r2nnZ2d@giganews.com ...
    >>>>>
    >>>>> My question regarding point 2 is: Is there a method of increasing the
    >>>>> buffer size(s) when doing cpio operations to and from tape? (I've set
    >>>>> the
    >>>>> block size to 65536 kB.)
    >>>>
    >>>>Correction: 65536 BYTES
    >>>>
    >>>
    >>> man cpio, specifically looking for the -C option.
    >>>
    >>> HTH
    >>>
    >>>
    >>> Scott McMillan

    >>
    >>Thanks, I've tried -C65536 and -C131072, without seeing great results: the
    >>DLT7000 tape drive still starts and stops while executing cpio -o. On a
    >>similar spec CPU/motherboard/disk system (both the SCO and the NetWare
    >>server feed the DLT7000 tape drive through a dedicated Adaptec 2940UW
    >>PCI-based SCSI adapter.) - based NetWare 3.12 server, I see continuous
    >>streaming on- and off- the DLT7000 tape drive. On that server I use CA
    >>Arcserve, with buffer size set to 64KB (I think . . . maybe it's only
    >>16KB).
    >>In fact, I can keep that tape drive streaming continuously even when
    >>backing
    >>up remote servers over a 100 MB/s cable (when using CA Arcserve's push
    >>agents on the remote servers).
    >>
    >>Has anyone run files i/o benchmarks on SCO vs NetWare?
    >>
    >>I found this interesting snippet on SCO's site:
    >>http://www.sco.com/developers/hdk/te...hbacert/6.0.0/
    >>hbacert.html
    >>"We recommend 150M tape drive for the multiple-volume cpio test. High
    >>capacity drives (e.g., DLT drives) are not recommended at this time
    >>because
    >>of performance issues."
    >>
    >>My guess is that the "performance issues" are related to their operating
    >>system, not the DLT tape drives.
    >>
    >>-Arby
    >>
    >>

    >
    > In the past when I have had streaming issues with tapes I have piped the
    > cpio through dd and out to the tape.
    >
    > Don C
    >
    >

    Thanks Don! I hadn't thought of that. I'll try it. Then (forgive me, I'm
    far from fluent in Unix) what's the procedure for restoring the files?

    -Arby



  7. Re: SCO qurks


    >> In the past when I have had streaming issues with tapes I have piped the
    >> cpio through dd and out to the tape.
    >>
    >> Don C
    >>
    >>

    > Thanks Don! I hadn't thought of that. I'll try it. Then (forgive me, I'm
    > far from fluent in Unix) what's the procedure for restoring the files?


    dd does not modify the data (unless you go out of your way to tell it to
    byte-swap or convert to ebcdic).

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  8. Re: SCO qurks

    In article , Arby
    writes
    >
    >"Donald Campbell" wrote in message
    >news:wxRYJuCzdUCHFAjs@suedonltd.demon.co.uk...
    >> In article , Arby
    >> writes
    >>>
    >>>"Scott McMillan" wrote in message
    >>>news:66t1g3tp741ae8lpg9ecnfl620gbnsoa7l@4ax.com...
    >>>> On Sun, 30 Sep 2007 19:06:06 -0400, "Arby"
    >>>> wrote:
    >>>>
    >>>>>
    >>>>>"Arby" wrote in message
    >>>>>news:Bb6dnVXymfHvup3anZ2dnUVZ_r2nnZ2d@giganews.com ...
    >>>>>>
    >>>>>> My question regarding point 2 is: Is there a method of increasing the
    >>>>>> buffer size(s) when doing cpio operations to and from tape? (I've set
    >>>>>> the
    >>>>>> block size to 65536 kB.)
    >>>>>
    >>>>>Correction: 65536 BYTES
    >>>>>
    >>>>
    >>>> man cpio, specifically looking for the -C option.
    >>>>
    >>>> HTH
    >>>>
    >>>>
    >>>> Scott McMillan
    >>>
    >>>Thanks, I've tried -C65536 and -C131072, without seeing great results: the
    >>>DLT7000 tape drive still starts and stops while executing cpio -o. On a
    >>>similar spec CPU/motherboard/disk system (both the SCO and the NetWare
    >>>server feed the DLT7000 tape drive through a dedicated Adaptec 2940UW
    >>>PCI-based SCSI adapter.) - based NetWare 3.12 server, I see continuous
    >>>streaming on- and off- the DLT7000 tape drive. On that server I use CA
    >>>Arcserve, with buffer size set to 64KB (I think . . . maybe it's only
    >>>16KB).
    >>>In fact, I can keep that tape drive streaming continuously even when
    >>>backing
    >>>up remote servers over a 100 MB/s cable (when using CA Arcserve's push
    >>>agents on the remote servers).
    >>>
    >>>Has anyone run files i/o benchmarks on SCO vs NetWare?
    >>>
    >>>I found this interesting snippet on SCO's site:
    >>>http://www.sco.com/developers/hdk/te...hbacert/6.0.0/
    >>>hbacert.html
    >>>"We recommend 150M tape drive for the multiple-volume cpio test. High
    >>>capacity drives (e.g., DLT drives) are not recommended at this time
    >>>because
    >>>of performance issues."
    >>>
    >>>My guess is that the "performance issues" are related to their operating
    >>>system, not the DLT tape drives.
    >>>
    >>>-Arby
    >>>
    >>>

    >>
    >> In the past when I have had streaming issues with tapes I have piped the
    >> cpio through dd and out to the tape.
    >>
    >> Don C
    >>
    >>

    >Thanks Don! I hadn't thought of that. I'll try it. Then (forgive me, I'm
    >far from fluent in Unix) what's the procedure for restoring the files?
    >
    >-Arby
    >
    >


    Just use dd to read the device and pipe into cpio that then reads,
    understands and does what you tell it to do.

    In fact you can read the tape direct with cpio as the dd (by default)
    will not change the data in anyway.


    Don C



+ Reply to Thread