INIT params for disk to build on-disk save sets - VMS

This is a discussion on INIT params for disk to build on-disk save sets - VMS ; I have a system...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: INIT params for disk to build on-disk save sets

  1. INIT params for disk to build on-disk save sets

    I have a system

  2. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 4:12*pm, AEF wrote:
    > I have a system


    Uh, I fat fingered an premature Send. Stay tuned for the full
    question.

    AEF

  3. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 4:14*pm, AEF wrote:
    > On Oct 23, 4:12*pm, AEF wrote:
    >
    > > I have a system


    Boy, I wish I could have seen the looks on your faces when you saw
    that the line above was the entire post!

    >
    > Uh, I fat fingered an premature Send. Stay tuned for the full
    > question.
    >
    > AEF


    Uh, that should have been:

    "Uh, I fat-fingered a premature Send. Stay tuned for the full
    question."

    Anyway, here's my question:

    I have a system with four RZ28 disks installed. I want to use one of
    them as a target for on-disk backups of the other disks which will
    then be FTPed to another, possibly remote, system. So this means that
    I will primarily have just one large file on this disk at any given
    time, and maybe a few small files for whatever reason (and a few
    directories, of course). What params should I use to INITIALIZE this
    disk? (For those of you who are too young to remember, these disks are
    2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    OK, so I was thinking of

    large value for /CLUSTER

    large value for /EXTEND, maybe 10000

    small value for /HEADERS

    medium value for /MAXIMUM_FILES

    What do y'all think? Is it even worth bothering with?

    Thanks!

  4. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 4:27*pm, AEF wrote:
    :
    > I will primarily have just one large file on this disk at any given

    :
    > disk? (For those of you who are too young to remember, these disks are
    > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)


    I'm old enough... 7200 rpm, narrow scsi, big then, very small now.
    You are better of with a $99 500GB USB drive if you can hook that up!


    > OK, so I was thinking of large value for /CLUSTER.

    Yeah sure... like 512.

    > large value for /EXTEND, maybe 10000

    Certainly, line 64000

    > small value for /HEADERS

    Sure... 100?
    > medium value for /MAXIMUM_FILES

    Sure... 1000?

    And maybe add /INDEX=BEG

    > What do y'all think? Is it even worth bothering with?

    I would, but I would not expect much from it other then no longer
    having the think whether I should have tweaked it some. :-). Piece of
    mind.

    Hein.

  5. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 3:27 pm, AEF wrote:
    > On Oct 23, 4:14 pm, AEF wrote:
    >
    > > On Oct 23, 4:12 pm, AEF wrote:

    >
    > > > I have a system

    >
    > Boy, I wish I could have seen the looks on your faces when you saw
    > that the line above was the entire post!
    >
    >
    >
    > > Uh, I fat fingered an premature Send. Stay tuned for the full
    > > question.

    >
    > > AEF

    >
    > Uh, that should have been:
    >
    > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    > question."
    >
    > Anyway, here's my question:
    >
    > I have a system with four RZ28 disks installed. I want to use one of
    > them as a target for on-disk backups of the other disks which will
    > then be FTPed to another, possibly remote, system. So this means that
    > I will primarily have just one large file on this disk at any given
    > time, and maybe a few small files for whatever reason (and a few
    > directories, of course). What params should I use to INITIALIZE this
    > disk? (For those of you who are too young to remember, these disks are
    > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)
    >
    > OK, so I was thinking of
    >
    > large value for /CLUSTER
    >
    > large value for /EXTEND, maybe 10000
    >
    > small value for /HEADERS
    >
    > medium value for /MAXIMUM_FILES
    >
    > What do y'all think? Is it even worth bothering with?
    >
    > Thanks!


    AEF,

    Since it is a temporary disk, it always can be redone.

    The [effective] OP, does not mention the version of the system. It may
    matter.

    Extension is important. This is similar to the situation which caused
    me to use RMS transparent file access, to gain the multibuffering
    advantage. FAL honors the RMS buffering and blocking parameters,
    BACKUP has not always done so. The DECnet overhead is far less in that
    session than the repeated extends and real time delays.

    Remember that the allocations for the directories are minimally one
    cluster, thus a truly large cluster factor is not necessarily
    efficient. Also consider whether it is wise to ZIP the resuling save
    sets (and verify that thy UNZIP correctly).

    - Bob Gezelter, http://www.rlgsc.com

  6. Re: INIT params for disk to build on-disk save sets

    AEF wrote:
    > I have a system


    Congratulations!

  7. Re: INIT params for disk to build on-disk save sets

    AEF wrote:
    > On Oct 23, 4:14 pm, AEF wrote:
    >> On Oct 23, 4:12 pm, AEF wrote:
    >>
    >>> I have a system

    >
    > Boy, I wish I could have seen the looks on your faces when you saw
    > that the line above was the entire post!
    >
    >> Uh, I fat fingered an premature Send. Stay tuned for the full
    >> question.
    >>
    >> AEF

    >
    > Uh, that should have been:
    >
    > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    > question."
    >
    > Anyway, here's my question:
    >
    > I have a system with four RZ28 disks installed. I want to use one of
    > them as a target for on-disk backups of the other disks which will
    > then be FTPed to another, possibly remote, system. So this means that
    > I will primarily have just one large file on this disk at any given
    > time, and maybe a few small files for whatever reason (and a few
    > directories, of course). What params should I use to INITIALIZE this
    > disk? (For those of you who are too young to remember, these disks are
    > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)
    >
    > OK, so I was thinking of
    >
    > large value for /CLUSTER
    >

    OK!
    > large value for /EXTEND, maybe 10000

    OK

    > small value for /HEADERS
    >

    OK
    > medium value for /MAXIMUM_FILES

    Try SMALL! You are proposing to put THREE files on this disk; a Master
    File Directory, INDEXF.SYS and a BACKUP saveset.

    The smallest INDEXF.SYS you could have would be one block (I think). The
    BACKUP saveset could be less than a GB and you might manage to have two
    or three of them. I'd try something like /MAXIMUM_FILES=10.
    >
    > What do y'all think? Is it even worth bothering with?
    >
    > Thanks!


  8. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 4:51 pm, "Richard B. Gilbert"
    wrote:
    > AEF wrote:
    > > On Oct 23, 4:14 pm, AEF wrote:
    > >> On Oct 23, 4:12 pm, AEF wrote:

    >
    > >>> I have a system

    >
    > > Boy, I wish I could have seen the looks on your faces when you saw
    > > that the line above was the entire post!

    >
    > >> Uh, I fat fingered an premature Send. Stay tuned for the full
    > >> question.

    >
    > >> AEF

    >
    > > Uh, that should have been:

    >
    > > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    > > question."

    >
    > > Anyway, here's my question:

    >
    > > I have a system with four RZ28 disks installed. I want to use one of
    > > them as a target for on-disk backups of the other disks which will
    > > then be FTPed to another, possibly remote, system. So this means that
    > > I will primarily have just one large file on this disk at any given
    > > time, and maybe a few small files for whatever reason (and a few
    > > directories, of course). What params should I use to INITIALIZE this
    > > disk? (For those of you who are too young to remember, these disks are
    > > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >
    > > OK, so I was thinking of

    >
    > > large value for /CLUSTER

    >
    > OK!
    > > large value for /EXTEND, maybe 10000

    >
    > OK
    >
    > > small value for /HEADERS

    >
    > OK
    > > medium value for /MAXIMUM_FILES

    >
    > Try SMALL! You are proposing to put THREE files on this disk; a Master
    > File Directory, INDEXF.SYS and a BACKUP saveset.
    >
    > The smallest INDEXF.SYS you could have would be one block (I think). The
    > BACKUP saveset could be less than a GB and you might manage to have two
    > or three of them. I'd try something like /MAXIMUM_FILES=10.
    >
    >
    >
    > > What do y'all think? Is it even worth bothering with?

    >
    > > Thanks!



    Richard,

    With the cluster sizes proposed, the maximum files (and file headers)
    might as well be one or two clusters each. Anything less just does not
    use the space allocated.

    - Bob Gezelter, http://www.rlgsc.com

  9. Re: INIT params for disk to build on-disk save sets

    In article <26e02b21-95a3-4ad2-89db-2709bb4a8e74@m3g2000hsc.googlegroups.com>, Bob Gezelter writes:
    >On Oct 23, 4:51 pm, "Richard B. Gilbert"
    >wrote:
    >> AEF wrote:
    >> > On Oct 23, 4:14 pm, AEF wrote:
    >> >> On Oct 23, 4:12 pm, AEF wrote:

    >>
    >> >>> I have a system

    >>
    >> > Boy, I wish I could have seen the looks on your faces when you saw
    >> > that the line above was the entire post!

    >>
    >> >> Uh, I fat fingered an premature Send. Stay tuned for the full
    >> >> question.

    >>
    >> >> AEF

    >>
    >> > Uh, that should have been:

    >>
    >> > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    >> > question."

    >>
    >> > Anyway, here's my question:

    >>
    >> > I have a system with four RZ28 disks installed. I want to use one of
    >> > them as a target for on-disk backups of the other disks which will
    >> > then be FTPed to another, possibly remote, system. So this means that
    >> > I will primarily have just one large file on this disk at any given
    >> > time, and maybe a few small files for whatever reason (and a few
    >> > directories, of course). What params should I use to INITIALIZE this
    >> > disk? (For those of you who are too young to remember, these disks are
    >> > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >>
    >> > OK, so I was thinking of

    >>
    >> > large value for /CLUSTER

    >>
    >> OK!
    >> > large value for /EXTEND, maybe 10000

    >>
    >> OK
    >>
    >> > small value for /HEADERS

    >>
    >> OK
    >> > medium value for /MAXIMUM_FILES

    >>
    >> Try SMALL! You are proposing to put THREE files on this disk; a Master
    >> File Directory, INDEXF.SYS and a BACKUP saveset.
    >>
    >> The smallest INDEXF.SYS you could have would be one block (I think). The
    >> BACKUP saveset could be less than a GB and you might manage to have two
    >> or three of them. I'd try something like /MAXIMUM_FILES=10.
    >>
    >>
    >>
    >> > What do y'all think? Is it even worth bothering with?

    >>
    >> > Thanks!

    >
    >
    >Richard,
    >
    >With the cluster sizes proposed, the maximum files (and file headers)
    >might as well be one or two clusters each. Anything less just does not
    >use the space allocated.


    Exactly. However, for a couple of files, is this going to be an enormous
    storage saving? I am not fond of stuffing a drive close to its capacity
    in some cases as there's the potential of inadequate space for the task at
    hand.

    Wipe out the File Systems Internals and look up the calculations if you're
    not familiar with them to use the space most wisely.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  10. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 5:39*pm, "Richard B. Gilbert"
    wrote:
    > AEF wrote:
    > > I have a system

    >
    > Congratulations!


    Thanks!

    Man, I couldn't have fat-fingered better.

    AEF

  11. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 4:52*pm, Bob Gezelter wrote:
    > On Oct 23, 3:27 pm, AEF wrote:
    >
    >
    >
    > > On Oct 23, 4:14 pm, AEF wrote:

    >
    > > > On Oct 23, 4:12 pm, AEF wrote:

    >
    > > > > I have a system

    >
    > > Boy, I wish I could have seen the looks on your faces when you saw
    > > that the line above was the entire post!

    >
    > > > Uh, I fat fingered an premature Send. Stay tuned for the full
    > > > question.

    >
    > > > AEF

    >
    > > Uh, that should have been:

    >
    > > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    > > question."

    >
    > > Anyway, here's my question:

    >
    > > I have a system with four RZ28 disks installed. I want to use one of
    > > them as a target for on-disk backups of the other disks which will
    > > then be FTPed to another, possibly remote, system. So this means that
    > > I will primarily have just one large file on this disk at any given
    > > time, and maybe a few small files for whatever reason (and a few
    > > directories, of course). What params should I use to INITIALIZE this
    > > disk? (For those of you who are too young to remember, these disks are
    > > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >
    > > OK, so I was thinking of

    >
    > > large value for /CLUSTER

    >
    > > large value for /EXTEND, maybe 10000

    >
    > > small value for /HEADERS

    >
    > > medium value for /MAXIMUM_FILES

    >
    > > What do y'all think? Is it even worth bothering with?

    >
    > > Thanks!

    >
    > AEF,
    >
    > Since it is a temporary disk, it always can be redone.
    >
    > The [effective] OP, does not mention the version of the system. It may
    > matter.


    VAX/VMS V6.2 with all needed ECO kits applied (according to the
    "installation ratings").

    >
    > Extension is important. This is similar to the situation which caused
    > me to use RMS transparent file access, to gain the multibuffering
    > advantage. FAL honors the RMS buffering and blocking parameters,
    > BACKUP has not always done so. The DECnet overhead is far less in that
    > session than the repeated extends and real time delays.


    Yes, I figured extension was the most important as I've seen such
    operations go much, much faster with a large extension value.

    >
    > Remember that the allocations for the directories are minimally one
    > cluster, thus a truly large cluster factor is not necessarily
    > efficient. Also consider whether it is wise to ZIP the resuling save
    > sets (and verify that thy UNZIP correctly).


    Well, I was worried more about performance than space. Zip is an
    interesting option, but I don't think I'll have enough space for it.

    >
    > - Bob Gezelter,http://www.rlgsc.com


    Thanks to all who have replied.

    AEF

  12. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 7:10*pm, VAXman- @SendSpamHere.ORG wrote:
    > In article <26e02b21-95a3-4ad2-89db-2709bb4a8...@m3g2000hsc.googlegroups.com>, Bob Gezelter writes:
    >
    >
    >
    > >On Oct 23, 4:51 pm, "Richard B. Gilbert"
    > >wrote:
    > >> AEF wrote:
    > >> > On Oct 23, 4:14 pm, AEF wrote:
    > >> >> On Oct 23, 4:12 pm, AEF wrote:

    >
    > >> >>> I have a system

    >
    > >> > Boy, I wish I could have seen the looks on your faces when you saw
    > >> > that the line above was the entire post!

    >
    > >> >> Uh, I fat fingered an premature Send. Stay tuned for the full
    > >> >> question.

    >
    > >> >> AEF

    >
    > >> > Uh, that should have been:

    >
    > >> > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    > >> > question."

    >
    > >> > Anyway, here's my question:

    >
    > >> > I have a system with four RZ28 disks installed. I want to use one of
    > >> > them as a target for on-disk backups of the other disks which will
    > >> > then be FTPed to another, possibly remote, system. So this means that
    > >> > I will primarily have just one large file on this disk at any given
    > >> > time, and maybe a few small files for whatever reason (and a few
    > >> > directories, of course). What params should I use to INITIALIZE this
    > >> > disk? (For those of you who are too young to remember, these disks are
    > >> > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >
    > >> > OK, so I was thinking of

    >
    > >> > large value for /CLUSTER

    >
    > >> OK!
    > >> > large value for /EXTEND, maybe 10000

    >
    > >> OK

    >
    > >> > small value for /HEADERS

    >
    > >> OK
    > >> > medium value for /MAXIMUM_FILES

    >
    > >> Try SMALL! *You are proposing to put THREE files on this disk; a Master
    > >> File Directory, INDEXF.SYS and a BACKUP saveset.

    >
    > >> The smallest INDEXF.SYS you could have would be one block (I think). The
    > >> BACKUP saveset could be less than a GB and you might manage to have two
    > >> or three of them. *I'd try something like /MAXIMUM_FILES=10.

    >
    > >> > What do y'all think? Is it even worth bothering with?

    >
    > >> > Thanks!

    >
    > >Richard,

    >
    > >With the cluster sizes proposed, the maximum files (and file headers)
    > >might as well be one or two clusters each. Anything less just does not
    > >use the space allocated.

    >
    > Exactly. *However, for a couple of files, is this going to be an enormous
    > storage saving? *I am not fond of stuffing a drive close to its capacity
    > in some cases as there's the potential of inadequate space for the task at
    > hand. *
    >
    > Wipe out the File Systems Internals and look up the calculations if you're
    > not familiar with them to use the space most wisely.
    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker * * *VAXman(at)TMESIS(dot)COM
    >
    > ... pejorative statements of opinion are entitled to constitutional protection
    > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >
    > Copr. 2008 Brian Schenkenberger. *Publication of _this_ usenet article outside
    > of usenet _must_ include its contents in its entirety including this copyright
    > notice, disclaimer and quotations.


    Brian,

    WADR, you DID mean "whip out", correct? ["Wipe out" seems singularly
    destructive, as the book is out of print and arguably collectable? --
    (smile)]

    - Bob Gezelter, http://www.rlgsc.com

  13. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 5:51*pm, "Richard B. Gilbert"
    wrote:
    > AEF wrote:
    > > On Oct 23, 4:14 pm, AEF wrote:
    > >> On Oct 23, 4:12 pm, AEF wrote:

    >
    > >>> I have a system

    >
    > > Boy, I wish I could have seen the looks on your faces when you saw
    > > that the line above was the entire post!

    >
    > >> Uh, I fat fingered an premature Send. Stay tuned for the full
    > >> question.

    >
    > >> AEF

    >
    > > Uh, that should have been:

    >
    > > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    > > question."

    >
    > > Anyway, here's my question:

    >
    > > I have a system with four RZ28 disks installed. I want to use one of
    > > them as a target for on-disk backups of the other disks which will
    > > then be FTPed to another, possibly remote, system. So this means that
    > > I will primarily have just one large file on this disk at any given
    > > time, and maybe a few small files for whatever reason (and a few
    > > directories, of course). What params should I use to INITIALIZE this
    > > disk? (For those of you who are too young to remember, these disks are
    > > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >
    > > OK, so I was thinking of

    >
    > > large value for /CLUSTER

    >
    > OK!
    > > large value for /EXTEND, maybe 10000

    >
    > OK
    >
    > > small value for /HEADERS

    >
    > OK
    > > medium value for /MAXIMUM_FILES

    >
    > Try SMALL! *You are proposing to put THREE files on this disk; a Master
    > File Directory, INDEXF.SYS and a BACKUP saveset.
    >
    > The smallest INDEXF.SYS you could have would be one block (I think). The
    > BACKUP saveset could be less than a GB and you might manage to have two
    > or three of them. *I'd try something like /MAXIMUM_FILES=10.


    Well, since the value for /MAXIMUM_FILES is such a hard limit, I
    thought I'd play it safe in case I want to put some other (small)
    files there. OTOH, as another poster pointed out, re-INITing the disk
    is easy.

    Thanks.
    [...]
    AEF

  14. Re: INIT params for disk to build on-disk save sets

    Bob Gezelter wrote:
    > On Oct 23, 7:10 pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article <26e02b21-95a3-4ad2-89db-2709bb4a8...@m3g2000hsc.googlegroups.com>, Bob Gezelter writes:
    >>
    >>
    >>
    >>> On Oct 23, 4:51 pm, "Richard B. Gilbert"
    >>> wrote:
    >>>> AEF wrote:
    >>>>> On Oct 23, 4:14 pm, AEF wrote:
    >>>>>> On Oct 23, 4:12 pm, AEF wrote:
    >>>>>>> I have a system
    >>>>> Boy, I wish I could have seen the looks on your faces when you saw
    >>>>> that the line above was the entire post!
    >>>>>> Uh, I fat fingered an premature Send. Stay tuned for the full
    >>>>>> question.
    >>>>>> AEF
    >>>>> Uh, that should have been:
    >>>>> "Uh, I fat-fingered a premature Send. Stay tuned for the full
    >>>>> question."
    >>>>> Anyway, here's my question:
    >>>>> I have a system with four RZ28 disks installed. I want to use one of
    >>>>> them as a target for on-disk backups of the other disks which will
    >>>>> then be FTPed to another, possibly remote, system. So this means that
    >>>>> I will primarily have just one large file on this disk at any given
    >>>>> time, and maybe a few small files for whatever reason (and a few
    >>>>> directories, of course). What params should I use to INITIALIZE this
    >>>>> disk? (For those of you who are too young to remember, these disks are
    >>>>> 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)
    >>>>> OK, so I was thinking of
    >>>>> large value for /CLUSTER
    >>>> OK!
    >>>>> large value for /EXTEND, maybe 10000
    >>>> OK
    >>>>> small value for /HEADERS
    >>>> OK
    >>>>> medium value for /MAXIMUM_FILES
    >>>> Try SMALL! You are proposing to put THREE files on this disk; a Master
    >>>> File Directory, INDEXF.SYS and a BACKUP saveset.
    >>>> The smallest INDEXF.SYS you could have would be one block (I think). The
    >>>> BACKUP saveset could be less than a GB and you might manage to have two
    >>>> or three of them. I'd try something like /MAXIMUM_FILES=10.
    >>>>> What do y'all think? Is it even worth bothering with?
    >>>>> Thanks!
    >>> Richard,
    >>> With the cluster sizes proposed, the maximum files (and file headers)
    >>> might as well be one or two clusters each. Anything less just does not
    >>> use the space allocated.

    >> Exactly. However, for a couple of files, is this going to be an enormous
    >> storage saving? I am not fond of stuffing a drive close to its capacity
    >> in some cases as there's the potential of inadequate space for the task at
    >> hand.
    >>
    >> Wipe out the File Systems Internals and look up the calculations if you're
    >> not familiar with them to use the space most wisely.
    >>
    >> --
    >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>
    >> ... pejorative statements of opinion are entitled to constitutional protection
    >> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >>
    >> Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    >> of usenet _must_ include its contents in its entirety including this copyright
    >> notice, disclaimer and quotations.

    >
    > Brian,
    >
    > WADR, you DID mean "whip out", correct? ["Wipe out" seems singularly
    > destructive, as the book is out of print and arguably collectable? --
    > (smile)]
    >


    There are a number of us who can't tipe gud.

  15. Re: INIT params for disk to build on-disk save sets

    AEF wrote:
    > On Oct 23, 5:51 pm, "Richard B. Gilbert"
    > wrote:
    >> AEF wrote:
    >>> On Oct 23, 4:14 pm, AEF wrote:
    >>>> On Oct 23, 4:12 pm, AEF wrote:
    >>>>> I have a system
    >>> Boy, I wish I could have seen the looks on your faces when you saw
    >>> that the line above was the entire post!
    >>>> Uh, I fat fingered an premature Send. Stay tuned for the full
    >>>> question.
    >>>> AEF
    >>> Uh, that should have been:
    >>> "Uh, I fat-fingered a premature Send. Stay tuned for the full
    >>> question."
    >>> Anyway, here's my question:
    >>> I have a system with four RZ28 disks installed. I want to use one of
    >>> them as a target for on-disk backups of the other disks which will
    >>> then be FTPed to another, possibly remote, system. So this means that
    >>> I will primarily have just one large file on this disk at any given
    >>> time, and maybe a few small files for whatever reason (and a few
    >>> directories, of course). What params should I use to INITIALIZE this
    >>> disk? (For those of you who are too young to remember, these disks are
    >>> 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)
    >>> OK, so I was thinking of
    >>> large value for /CLUSTER

    >> OK!
    >>> large value for /EXTEND, maybe 10000

    >> OK
    >>
    >>> small value for /HEADERS

    >> OK
    >>> medium value for /MAXIMUM_FILES

    >> Try SMALL! You are proposing to put THREE files on this disk; a Master
    >> File Directory, INDEXF.SYS and a BACKUP saveset.
    >>
    >> The smallest INDEXF.SYS you could have would be one block (I think). The
    >> BACKUP saveset could be less than a GB and you might manage to have two
    >> or three of them. I'd try something like /MAXIMUM_FILES=10.

    >
    > Well, since the value for /MAXIMUM_FILES is such a hard limit, I
    > thought I'd play it safe in case I want to put some other (small)
    > files there. OTOH, as another poster pointed out, re-INITing the disk
    > is easy.
    >


    It's easy ONLY if you don't care about the stuff that is on the disk!

  16. Re: INIT params for disk to build on-disk save sets

    AEF wrote:
    > [...snip...]
    >> The smallest INDEXF.SYS you could have would be one block (I think). The
    >> BACKUP saveset could be less than a GB and you might manage to have two
    >> or three of them. I'd try something like /MAXIMUM_FILES=10.

    >
    > Well, since the value for /MAXIMUM_FILES is such a hard limit, I
    > thought I'd play it safe in case I want to put some other (small)
    > files there. OTOH, as another poster pointed out, re-INITing the disk
    > is easy.


    I don't have my File System Internals in front of me at the
    moment, so I *could* be wrong ;-)

    There is one bit per possible file header in the Index File
    so, there's no advantage to having /MAXIMUM_FILES set to
    less than 4096 (1 block of 512 bytes times 8 bits = 4096).

  17. Re: INIT params for disk to build on-disk save sets

    In article , Bob Gezelter writes:
    >On Oct 23, 7:10=A0pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article <26e02b21-95a3-4ad2-89db-2709bb4a8...@m3g2000hsc.googlegroups.=

    >com>, Bob Gezelter writes:
    >>
    >>
    >>
    >> >On Oct 23, 4:51 pm, "Richard B. Gilbert"
    >> >wrote:
    >> >> AEF wrote:
    >> >> > On Oct 23, 4:14 pm, AEF wrote:
    >> >> >> On Oct 23, 4:12 pm, AEF wrote:

    >>
    >> >> >>> I have a system

    >>
    >> >> > Boy, I wish I could have seen the looks on your faces when you saw
    >> >> > that the line above was the entire post!

    >>
    >> >> >> Uh, I fat fingered an premature Send. Stay tuned for the full
    >> >> >> question.

    >>
    >> >> >> AEF

    >>
    >> >> > Uh, that should have been:

    >>
    >> >> > "Uh, I fat-fingered a premature Send. Stay tuned for the full
    >> >> > question."

    >>
    >> >> > Anyway, here's my question:

    >>
    >> >> > I have a system with four RZ28 disks installed. I want to use one of
    >> >> > them as a target for on-disk backups of the other disks which will
    >> >> > then be FTPed to another, possibly remote, system. So this means tha=

    >t
    >> >> > I will primarily have just one large file on this disk at any given
    >> >> > time, and maybe a few small files for whatever reason (and a few
    >> >> > directories, of course). What params should I use to INITIALIZE this
    >> >> > disk? (For those of you who are too young to remember, these disks a=

    >re
    >> >> > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >>
    >> >> > OK, so I was thinking of

    >>
    >> >> > large value for /CLUSTER

    >>
    >> >> OK!
    >> >> > large value for /EXTEND, maybe 10000

    >>
    >> >> OK

    >>
    >> >> > small value for /HEADERS

    >>
    >> >> OK
    >> >> > medium value for /MAXIMUM_FILES

    >>
    >> >> Try SMALL! =A0You are proposing to put THREE files on this disk; a Mas=

    >ter
    >> >> File Directory, INDEXF.SYS and a BACKUP saveset.

    >>
    >> >> The smallest INDEXF.SYS you could have would be one block (I think). T=

    >he
    >> >> BACKUP saveset could be less than a GB and you might manage to have tw=

    >o
    >> >> or three of them. =A0I'd try something like /MAXIMUM_FILES=3D10.

    >>
    >> >> > What do y'all think? Is it even worth bothering with?

    >>
    >> >> > Thanks!

    >>
    >> >Richard,

    >>
    >> >With the cluster sizes proposed, the maximum files (and file headers)
    >> >might as well be one or two clusters each. Anything less just does not
    >> >use the space allocated.

    >>
    >> Exactly. =A0However, for a couple of files, is this going to be an enormo=

    >us
    >> storage saving? =A0I am not fond of stuffing a drive close to its capacit=

    >y
    >> in some cases as there's the potential of inadequate space for the task a=

    >t
    >> hand. =A0
    >>
    >> Wipe out the File Systems Internals and look up the calculations if you'r=

    >e
    >> not familiar with them to use the space most wisely.
    >>
    >> --
    >> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME=

    >SIS(dot)COM
    >>
    >> ... pejorative statements of opinion are entitled to constitutional prote=

    >ction
    >> no matter how extreme, vituperous, or vigorously expressed they may be. (=

    >NJSC)
    >>
    >> Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article =

    >outside
    >> of usenet _must_ include its contents in its entirety including this copy=

    >right
    >> notice, disclaimer and quotations.

    >
    >Brian,
    >
    >WADR, you DID mean "whip out", correct? ["Wipe out" seems singularly
    >destructive, as the book is out of print and arguably collectable? --
    >(smile)]


    Yes, whip not wipe.

    I shouldn't post late night.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  18. Re: INIT params for disk to build on-disk save sets

    In article , "Richard B. Gilbert" writes:
    >Bob Gezelter wrote:
    >> On Oct 23, 7:10 pm, VAXman- @SendSpamHere.ORG wrote:
    >>> In article <26e02b21-95a3-4ad2-89db-2709bb4a8...@m3g2000hsc.googlegroups.com>, Bob Gezelter writes:
    >>>
    >>>
    >>>
    >>>> On Oct 23, 4:51 pm, "Richard B. Gilbert"
    >>>> wrote:
    >>>>> AEF wrote:
    >>>>>> On Oct 23, 4:14 pm, AEF wrote:
    >>>>>>> On Oct 23, 4:12 pm, AEF wrote:
    >>>>>>>> I have a system
    >>>>>> Boy, I wish I could have seen the looks on your faces when you saw
    >>>>>> that the line above was the entire post!
    >>>>>>> Uh, I fat fingered an premature Send. Stay tuned for the full
    >>>>>>> question.
    >>>>>>> AEF
    >>>>>> Uh, that should have been:
    >>>>>> "Uh, I fat-fingered a premature Send. Stay tuned for the full
    >>>>>> question."
    >>>>>> Anyway, here's my question:
    >>>>>> I have a system with four RZ28 disks installed. I want to use one of
    >>>>>> them as a target for on-disk backups of the other disks which will
    >>>>>> then be FTPed to another, possibly remote, system. So this means that
    >>>>>> I will primarily have just one large file on this disk at any given
    >>>>>> time, and maybe a few small files for whatever reason (and a few
    >>>>>> directories, of course). What params should I use to INITIALIZE this
    >>>>>> disk? (For those of you who are too young to remember, these disks are
    >>>>>> 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)
    >>>>>> OK, so I was thinking of
    >>>>>> large value for /CLUSTER
    >>>>> OK!
    >>>>>> large value for /EXTEND, maybe 10000
    >>>>> OK
    >>>>>> small value for /HEADERS
    >>>>> OK
    >>>>>> medium value for /MAXIMUM_FILES
    >>>>> Try SMALL! You are proposing to put THREE files on this disk; a Master
    >>>>> File Directory, INDEXF.SYS and a BACKUP saveset.
    >>>>> The smallest INDEXF.SYS you could have would be one block (I think). The
    >>>>> BACKUP saveset could be less than a GB and you might manage to have two
    >>>>> or three of them. I'd try something like /MAXIMUM_FILES=10.
    >>>>>> What do y'all think? Is it even worth bothering with?
    >>>>>> Thanks!
    >>>> Richard,
    >>>> With the cluster sizes proposed, the maximum files (and file headers)
    >>>> might as well be one or two clusters each. Anything less just does not
    >>>> use the space allocated.
    >>> Exactly. However, for a couple of files, is this going to be an enormous
    >>> storage saving? I am not fond of stuffing a drive close to its capacity
    >>> in some cases as there's the potential of inadequate space for the task at
    >>> hand.
    >>>
    >>> Wipe out the File Systems Internals and look up the calculations if you're
    >>> not familiar with them to use the space most wisely.
    >>>
    >>> --
    >>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>>
    >>> ... pejorative statements of opinion are entitled to constitutional protection
    >>> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >>>
    >>> Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    >>> of usenet _must_ include its contents in its entirety including this copyright
    >>> notice, disclaimer and quotations.

    >>
    >> Brian,
    >>
    >> WADR, you DID mean "whip out", correct? ["Wipe out" seems singularly
    >> destructive, as the book is out of print and arguably collectable? --
    >> (smile)]
    >>

    >
    >There are a number of us who can't tipe gud.


    I'm one of them but I can speak _well_!

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  19. Re: INIT params for disk to build on-disk save sets

    VAXman- @SendSpamHere.ORG wrote:
    > In article , "Richard B. Gilbert" writes:
    >> Bob Gezelter wrote:
    >>> On Oct 23, 7:10 pm, VAXman- @SendSpamHere.ORG wrote:
    >>>> In article <26e02b21-95a3-4ad2-89db-2709bb4a8...@m3g2000hsc.googlegroups.com>, Bob Gezelter writes:
    >>>>
    >>>>
    >>>>
    >>>>> On Oct 23, 4:51 pm, "Richard B. Gilbert"
    >>>>> wrote:
    >>>>>> AEF wrote:
    >>>>>>> On Oct 23, 4:14 pm, AEF wrote:
    >>>>>>>> On Oct 23, 4:12 pm, AEF wrote:
    >>>>>>>>> I have a system
    >>>>>>> Boy, I wish I could have seen the looks on your faces when you saw
    >>>>>>> that the line above was the entire post!
    >>>>>>>> Uh, I fat fingered an premature Send. Stay tuned for the full
    >>>>>>>> question.
    >>>>>>>> AEF
    >>>>>>> Uh, that should have been:
    >>>>>>> "Uh, I fat-fingered a premature Send. Stay tuned for the full
    >>>>>>> question."
    >>>>>>> Anyway, here's my question:
    >>>>>>> I have a system with four RZ28 disks installed. I want to use one of
    >>>>>>> them as a target for on-disk backups of the other disks which will
    >>>>>>> then be FTPed to another, possibly remote, system. So this means that
    >>>>>>> I will primarily have just one large file on this disk at any given
    >>>>>>> time, and maybe a few small files for whatever reason (and a few
    >>>>>>> directories, of course). What params should I use to INITIALIZE this
    >>>>>>> disk? (For those of you who are too young to remember, these disks are
    >>>>>>> 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)
    >>>>>>> OK, so I was thinking of
    >>>>>>> large value for /CLUSTER
    >>>>>> OK!
    >>>>>>> large value for /EXTEND, maybe 10000
    >>>>>> OK
    >>>>>>> small value for /HEADERS
    >>>>>> OK
    >>>>>>> medium value for /MAXIMUM_FILES
    >>>>>> Try SMALL! You are proposing to put THREE files on this disk; a Master
    >>>>>> File Directory, INDEXF.SYS and a BACKUP saveset.
    >>>>>> The smallest INDEXF.SYS you could have would be one block (I think). The
    >>>>>> BACKUP saveset could be less than a GB and you might manage to have two
    >>>>>> or three of them. I'd try something like /MAXIMUM_FILES=10.
    >>>>>>> What do y'all think? Is it even worth bothering with?
    >>>>>>> Thanks!
    >>>>> Richard,
    >>>>> With the cluster sizes proposed, the maximum files (and file headers)
    >>>>> might as well be one or two clusters each. Anything less just does not
    >>>>> use the space allocated.
    >>>> Exactly. However, for a couple of files, is this going to be an enormous
    >>>> storage saving? I am not fond of stuffing a drive close to its capacity
    >>>> in some cases as there's the potential of inadequate space for the task at
    >>>> hand.
    >>>>
    >>>> Wipe out the File Systems Internals and look up the calculations if you're
    >>>> not familiar with them to use the space most wisely.
    >>>>
    >>>> --
    >>>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>>>
    >>>> ... pejorative statements of opinion are entitled to constitutional protection
    >>>> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >>>>
    >>>> Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    >>>> of usenet _must_ include its contents in its entirety including this copyright
    >>>> notice, disclaimer and quotations.
    >>> Brian,
    >>>
    >>> WADR, you DID mean "whip out", correct? ["Wipe out" seems singularly
    >>> destructive, as the book is out of print and arguably collectable? --
    >>> (smile)]
    >>>

    >> There are a number of us who can't tipe gud.

    >
    > I'm one of them but I can speak _well_!
    >


    It's "point and grunt" for me!

  20. Re: INIT params for disk to build on-disk save sets

    AEF writes:

    >> > I have a system with four RZ28 disks installed. I want to use one of
    >> > them as a target for on-disk backups of the other disks which will
    >> > then be FTPed to another, possibly remote, system. So this means that
    >> > I will primarily have just one large file on this disk at any given
    >> > time, and maybe a few small files for whatever reason (and a few
    >> > directories, of course). What params should I use to INITIALIZE this
    >> > disk? (For those of you who are too young to remember, these disks are
    >> > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >>
    >> > OK, so I was thinking of

    >>
    >> > large value for /CLUSTER

    >>
    >> OK!
    >> > large value for /EXTEND, maybe 10000

    >>
    >> OK
    >>
    >> > small value for /HEADERS

    >>
    >> OK
    >> > medium value for /MAXIMUM_FILES

    >>
    >> Try SMALL! =A0You are proposing to put THREE files on this disk; a Master
    >> File Directory, INDEXF.SYS and a BACKUP saveset.
    >>
    >> The smallest INDEXF.SYS you could have would be one block (I think). The
    >> BACKUP saveset could be less than a GB and you might manage to have two
    >> or three of them. =A0I'd try something like /MAXIMUM_FILES=3D10.


    >Well, since the value for /MAXIMUM_FILES is such a hard limit, I
    >thought I'd play it safe in case I want to put some other (small)
    >files there. OTOH, as another poster pointed out, re-INITing the disk
    >is easy.


    This whole thread reminds me of a time long ago, where I tried to come
    up with INIT parameters that would squeeze every possible block out of
    RX33 and other small disks, to maximize the space for one or a small
    number of user files by minimizing that used by INDEXF.SYS and friends.

+ Reply to Thread
Page 1 of 2 1 2 LastLast