Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.1
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-228Clean up lib directory
      KULRICE-10682Move KRAD sampleapp JMeter tests to rice-framework/krad-sampleapp and update CI JMeter jobs
      KULRICE-231Provide Maven2 POM to rice-commons to build Rice Commons and allow other projects to use rice-commons through maven2
      KULRICE-6359Remove old upgrade directories from the scripts sub directory
      KULRICE-3959database-impex build directories
      KULRICE-3640Create groovy script to update attachment directory
      KULRICE-10377improve usability of the notes & attachments section
      KULRICE-631Refactor package structure to be in line with the rest of Rice
      KULRICE-11656Additive Database Structure: Split Up Impex Resources
      KULRICE-11657Additive Database Structure: Adapt DevOps libraries to compensate

      Description

      Need to change to a tiered directory structure to get around an AIX limitation of 32K files in a single directory.

      We also need to create a script for existing rice implementations to upgrade to the new attachment directory structure, and document this change and procedure in the release notes.

      >>>>> On Sep 17, 2009, at 6:23 PM, McHenry,Kevin wrote:
      >>>>>> File attachments are creating a unique directory under the
      >>>>>> attachments directory for each file. At CSU, we have run into the
      >>>>>> limit on AIX of 32k directories under a parent directory. It
      >>>>>> sounds
      >>>>>> like this is also a limit on other operating systems. Does anyone
      >>>>>> have any ideas on how to get around this? Can KFS/Rice be
      >>>>>> configured not to create directories? Although the performance
      >>>>>> for
      >>>>>> opening a file attachment would probably be terrible.
      >>>>>>
      >>>>>> The message in the incident reports is:
      >>>>>> DistributionOfIncomeAndExpenseForm:Could not generate directory
      >>>>>> for
      >>>>>> File at: /doc-kfs/prd/attachments/84817A27-67C8-FC24-
      >>>>>> EDC1-4D3989FA3CF4

        Issue Links

          Activity

          Hide
          Thomas Bradford (Inactive) added a comment -

          Change made to AttachmentServiceImpl as well as a bash script created to restructure an existing attachments directory. Documentation still needed for release notes, and as this is an impacting change, it needs to be approved by the KTI before being committed.

          Show
          Thomas Bradford (Inactive) added a comment - Change made to AttachmentServiceImpl as well as a bash script created to restructure an existing attachments directory. Documentation still needed for release notes, and as this is an impacting change, it needs to be approved by the KTI before being committed.
          Hide
          Eric Westfall added a comment -

          Putting a comment here that summarizes what the solution was that was implemented for this:

          CSU has run into a production problem where they've maxed out the
          number of links that a single inode can reference. On linux through
          ext3, this limit is 2^14, while on AIX (what they're using, it's 2^15).

          What I propose as a solution is to modify the AttachmentServiceImpl to
          store the attachment directories in a trie-style hierarchy similar to
          what most ISPs do to separate out their user's home dirs.
          Specifically, I'd like to break out the hierarchy to 4 or 6 sub-levels
          representing the first four (or six) characters of the Object-ID.

          If we're talking about 4 sub-levels, that gives us 16^4 terminating
          buckets to place these attachment directories, which should be
          relatively evenly distributed among them (if the OID's hash algorithm
          is worth its salt). That will give us a total of about 2 billion
          attachments instead of (16-32k). If we go with 6 sub-levels, that's
          about 549 billion.

          So a document with an OID of 5A691AF93B5A424DE0404F8189D80D73 would be
          in a subdirectory of:

          [Attachment Dir]/5/A/6/9/5A691AF93B5A424DE0404F8189D80D73/

          Show
          Eric Westfall added a comment - Putting a comment here that summarizes what the solution was that was implemented for this: CSU has run into a production problem where they've maxed out the number of links that a single inode can reference. On linux through ext3, this limit is 2^14, while on AIX (what they're using, it's 2^15). What I propose as a solution is to modify the AttachmentServiceImpl to store the attachment directories in a trie-style hierarchy similar to what most ISPs do to separate out their user's home dirs. Specifically, I'd like to break out the hierarchy to 4 or 6 sub-levels representing the first four (or six) characters of the Object-ID. If we're talking about 4 sub-levels, that gives us 16^4 terminating buckets to place these attachment directories, which should be relatively evenly distributed among them (if the OID's hash algorithm is worth its salt). That will give us a total of about 2 billion attachments instead of (16-32k). If we go with 6 sub-levels, that's about 549 billion. So a document with an OID of 5A691AF93B5A424DE0404F8189D80D73 would be in a subdirectory of: [Attachment Dir] /5/A/6/9/5A691AF93B5A424DE0404F8189D80D73/
          Hide
          Eric Westfall added a comment -

          Note that the final implementation went with 6 sub-levels.

          Show
          Eric Westfall added a comment - Note that the final implementation went with 6 sub-levels.

            People

            • Assignee:
              Thomas Bradford (Inactive)
              Reporter:
              Jeremy Hanson
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel