Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Sakai Data Storage - Campus Installations

Existing File System - AFS

Currently, UC Davis people have home directories in AFS space, and that CourseManagement also utilizes this space.

  1. User's AFS Space Allocation
  2. User space in AFS is in the form of the directory stucture below:
    /afs/home.ucdavis.edu/home/sn/samerson
    Above, sn is the first initial of firstname, and last initial of lastname.
  1. Course AFS Space Allocation
    AFS space for courses is allocated via CRN, and CourseManagement in MyUCDavis writes data to this directory. The ACL is the MyUCDavis user.

Problem Statement

Here are some of the questions we need to answer:

  1. How do we integrate Sakai's resources and our current AFS file system?
  2. When user's create worksites, how does this get mapped?
  3. What location does it get mapped?
  4. Do course type of worksites get stored in existing AFS CourseManagement space?
  5. Where do project/research/ or any other non-user and non-course Sakai sites get stored?

How Sakai stores content

Current Sakai architecture supports storing course and user content both inside/outside of a database. The content path can be mapped to any given path one gives it in the sakai.properties configuration file:

ref: http://bugs.sakaiproject.org/confluence/display/FAQ/2.2.7.1+Configuration

This content is taken from bugs.sakaiproject.org/confluence
The best place for configuring this is the sakai.properties file.

# the file system root for content hosting's external stored files (default is null, i.e. store them in the db)
bodyPath@org.sakaiproject.service.legacy.content.ContentHostingService =${sakai.home}content

Enable the above line, and point at the root folder for the files to be stored.

# when storing content hosting's body bits in files, an optional set of folders just within the content.filesystem.root

# to act as volumes to distribute the files among - a comma separate list of folders.  If left out, no volumes will be used.
bodyVolumes@org.sakaiproject.service.legacy.content.ContentHostingService = v1,v2,v3

Enable the above line, and set the list of "volumes" for storage. You can specify one or more volume names, comma separated on this line. These are folders under the file system root. Files will be distributed among these volumes.

If you are going to use multiple volume devices, you need to map them to these volume names that live "under" the root. We have done this with our AFS file storage system at the University of Michigan. If you are not using separate devices, then you can use any folder names for the volumes. Provide at least one.

Files will be stored under each volume in a way so that there are not too many in any one folder. The folder structure we use is:

YYYY/DDD/HH/id, where YYYY=year, DDD=day of year, HH=hour of day, and the 1111...=an id-based file name

for example,

2005/070/03/3223479379834-2343

or, using the above root and volumes, it might be:

/usr/local/tomcat/sakai/content/v2/2005/070/03/3223479379834-2343

Note that the resource name and type is not at all encoded here. The date/time used to form the file name is the date/time of file creation.

Proposed solution(s)

a. user's space

b. courses
Use the ACL associated with the current MyUCDavis user, however make the reference now the Sakai user.

  • No labels