Re: Too many files in one directory (again) - VMS

This is a discussion on Re: Too many files in one directory (again) - VMS ; From: Hein RMS van den Heuvel > I thought the description a little odd, so that's why I quoted it. > It must be the minimum or 100 and 1/2 current, rounded up to cluster > size. That would seem ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Too many files in one directory (again)

  1. Re: Too many files in one directory (again)

    From: Hein RMS van den Heuvel

    > I thought the description a little odd, so that's why I quoted it.
    > It must be the minimum or 100 and 1/2 current, rounded up to cluster
    > size.


    That would seem to agree better with reality (if not with
    optimality).

    > [...]
    > So pre-allocating would not have helped much/any, other then taking
    > away rampant speculation.


    I did only see that multi-second pause when the directory allocation
    grew, which was not often enoug to account for much.

    > The only hint we have to explain the high IO rats is the Dir Data
    > Attempt Rate @ 6700.
    > Apply those 70% hits and that leaves a potential for 2000 IO/sec.
    >
    > Was that a quick worst-case picture, or over minutes ?
    > Unfortunately the MONITOR output sorely lacks in the space.
    > Plenty of room on that screen! T4 would help there.


    It was a snapshot, but very typical. Whenever I looked at it, it
    looked pretty much the same.

    > > So, it took only about 35 hours on a (newer, faster) VMS system to do
    > > what took about 35 minutes on the HP-UX system.

    >
    > And that's what hurts and needs to be pointed out.
    > Thank you for the topic!


    Always glad to complain. Now I'll just settle back (hold my breath?)
    and wait for something to appear in the release notes.

    SMS.

  2. Re: Too many files in one directory (again)

    Steven M. Schweda wrote:
    > From: Hein RMS van den Heuvel
    >
    >>I thought the description a little odd, so that's why I quoted it.
    >>It must be the minimum or 100 and 1/2 current, rounded up to cluster
    >>size.

    >
    >
    > That would seem to agree better with reality (if not with
    > optimality).
    >
    >
    >>[...]
    >>So pre-allocating would not have helped much/any, other then taking
    >>away rampant speculation.

    >
    >
    > I did only see that multi-second pause when the directory allocation
    > grew, which was not often enoug to account for much.
    >
    >
    >>The only hint we have to explain the high IO rats is the Dir Data
    >>Attempt Rate @ 6700.
    >>Apply those 70% hits and that leaves a potential for 2000 IO/sec.
    >>
    >>Was that a quick worst-case picture, or over minutes ?
    >>Unfortunately the MONITOR output sorely lacks in the space.
    >>Plenty of room on that screen! T4 would help there.

    >
    >
    > It was a snapshot, but very typical. Whenever I looked at it, it
    > looked pretty much the same.
    >
    >
    >>>So, it took only about 35 hours on a (newer, faster) VMS system to do
    >>>what took about 35 minutes on the HP-UX system.

    >>
    >>And that's what hurts and needs to be pointed out.
    >>Thank you for the topic!

    >
    >
    > Always glad to complain. Now I'll just settle back (hold my breath?)
    > and wait for something to appear in the release notes.
    >
    > SMS.


    No, don't hold your breath. Just don't put too many files in a
    directory. ISTR that something like 100 blocks is as big as a directory
    can get and still work reasonably well. The only time I EVER saw a
    directory bigger than that was when some damned fool went on vacation
    and left something running that created 70,000 files in a directory; an
    incident I've mentioned earlier in this thread.

    If you REALLY NEED to do something like that, use a tool suited to the
    job. VMS is NOT such a tool!!!!

    If I were again faced with 70,000 files in a director, I think I would
    initialize the disk and restore from backup!!!!!!!!!! Yes, it's that bad!!




  3. Re: Too many files in one directory (again)

    Richard B. Gilbert wrote:

    > If you REALLY NEED to do something like that, use a tool suited to the
    > job. VMS is NOT such a tool!!!!


    In the early days of VMS, VMS was used in isolated islands. Software was
    designed for VMS and ran on VMS. People wrote their own software.

    And during the 1980s, Digital developped a LOT of software/applications
    that were optimised for VMS.

    Today however, the owner of VMS has a very tiny portfolio of actively
    developped applications specific to VMS.

    New software generally comes from other platforms and must be adapted to
    run around the restrictions imposed by VMS.

    The fewer restrictions exsist, the better such software can run on VMS
    and the easier it would have been to port it to VMS.

    But lets face it, VMS is NOT KEEPING UP. Porting Mozilla to VMS was a
    great accomplishement, but they haven't kept up and VMS is way behind
    now. We can undeerstand why this is, and can't fault the engineers. But
    the end result is that VMS has lagged the industry with no change in
    sight that would allow VMS to catch up.

+ Reply to Thread