Our LF volumes were set up as physical volumes instead of logical volumes.  This needs to be corrected due to a disk storage limitation.  Here is my plan (specifics removed).  I'd appreciate any feedback.  Thanks, Jim.

  Maximum amount of storage on the D drive on SERVER1 has brought forth the need to alter and formalize the physical storage configuration of our repositories.

Current configuration

SERVER1

1. REPOSITORY1 repository
   1. DEFAULT logical volume
      1. Unused read-only volume left over from initial installation
   2. VOLUME1 physical volume
      1. Current location of all contents of the REPOSITORY1 repository
      2. Mapped to the D drive on SERVER1 and at over 80% capacity of the virtual drive
      3. Virtual drive is limited to 2TB in size
      4. Volume security is set to Everyone has default access
2. REPOSITORY1DEV repository
   1. DEFAULT logical volume
      1. Mapped to the D drive on SERVER1 which is at >80% capacity as noted above
      2. Volume security is set to Everyone has default access

SERVER2

1. REPOSITORY2 repository
   1. VOLUME3 physical volume
      1. Current default volume for the REPOSITORY2 repository except for “F1” folder.
      2. Mapped to the F drive on SERVER2
      3. Virtual drive is at 1% maximum capacity
      4. Volume security is set to Everyone has default access
   2. VOLUME4 physical volume
      1. Current default volume for the “F1” folder
      2. Mapped to the F drive on SERVER2
      3. Virtual drive is at 1% maximum capacity
      4. Volume security is set to Everyone has default access

Issues

1. About to run out of disk space on SERVER1 D drive.
2. Unable to expand VOLUME1 volume due to it being a physical volume on a space limited virtual disk drive.
3. Volume security would allow for a user to attempt to create a document on a full, or nearly full, volume.
4. Want to ensure that the new default volume is propagated to the entire repository.

Plan

  For REPOSITORY1 repository on SERVER1

1. Create new logical volume for REPOSITORY1 repository called VOLUME2 with path E:\LF_Volumes\LF_VOLUME2.  This is pointing to the new GPT virtual drive.
2. Make physical volumes in VOLUME2 rollover at 1,000,000 MB.  Increase size of the new GPT drive in 1 or 2 TB increments.  Current size of this new GPT drive is 2 TB, with a maximum value of 18 TB.  Note that changing the physical path of a logical volume will only affect the creating of new child physical volumes, therefore when the new GPT drive becomes full, pointing the logical volume to a new disk drive will only affect the creation of new physical volumes.  It would probably be best to leave extra space available on the existing drive to accommodate the expansion of existing documents.
3. Set default volume for REPOSITORY1 repository to VOLUME2.
4. Set volume VOLUME2 access to standard access for “Everyone” and complete access for “Admins”.
5. Set volume VOLUME1 access to default minus “Create documents” for “Everyone” and complete access for “Admins”.  This will allow for updating existing documents “in place,” while new documents will be created on the new volume.  If free space on the SERVER1 D drive starts to approach maximum (2 TB) then first remove the DEV volumes from that drive.

  For REPOSITORY1DEV on SERVER1

1. No change until such time as the SERVER1 D drive starts to become full.
   1. Alternatively, use development repository as a test bed for moving the contents to the new drive by changing the logical and then the physical fixed path.

  For REPOSITORY2 repository on SERVER2

1. Add complete access to both volumes for “R2 Admin” group.
2. Restrict access to VOLUME3 volume to only “R2 Admin” group.
3. Currently, leave access to the VOLUME4 volume as is.  In the future when other entities are added to the REPOSITORY2 repository we can tailor the access to specific volumes for specific groups representing specific entities.
   1. Alternatively, modify access to VOLUME4 to default access for ENTITY1 group and eliminate “Everyone” access
4. When new scanned images for ENTITY1 are to be added to the “F1” top-level folder of the REPOSITORY2 repository by attaching an exported volume, attach the volume as a temporary convenience and migrate the documents to the VOLUME4 volume.

Questions

1. Does modifying the default volume at the repository level change the default volume for all child folders in the repository?  Can I reasonably presume that I do not need to change the default volume on every folder?  Hypothetically, if a child folder has a default volume that does not match the default volume for the repository, would changing the default volume for the repository change the default volume for the unmatched folder?
2. If I change the path on a logical volume, does the complete path have to already exist, or will LF create the necessary folder structure?