[Deploying Sakai] deprecating a bodyVolume

[Matthew Jones]

Just as a small amount of additional information. as described in confluence
[1] Sakai doesn't do any disk size checking on the body volumes and will
just randomly pick one of the volumes listed to put files into. So it could
potentially be better just to either manually rotate one volume as Jeff
described or use a file system that allows for dynamically expandable
storage space (like a virtual or network drive?)

BaseContentService.java
11235                 volume += m_bodyVolumes[(int)
(Math.abs(time.getTime()) % ((long) m_bodyVolumes.length))];

Also, even though Sakai won't actively create new content in the old storage
space(s), if any content that previously exists is updated by a user then
the file on disk will be also modified, so it could potentially still
increase in size.

[1]
https://confluence.sakaiproject.org/display/DOC/Sakai+Admin+Guide+-+Binary+Content+and+Filesystem+Settings

On Wed, Jan 5, 2011 at 10:50 AM, Cousineau, Jeffrey <cousinea at umich.edu>wrote:

> Hi John,
>
> This is correct.  As long as the old volume(s) are still accessible to the
> app servers, you should be ok.
>
> At U-M we have historically created a new volume each calendar year, so we
> only have one volume configured at a time.  Previous volumes remain
> NFS-mounted on the app servers so older content is still accessible.
>
> Our configuration is currently:
>
> bodyVolumes at org.sakaiproject.content.api.ContentHostingService=fs2011
>
> Jeff
>
> On Jan 5, 2011, at 10:37 AM, John F. Hall wrote:
>
> >
> > Our production server was initially set up with a single content volume:
> > bodyVolumes at org.sakaiproject.content.api.ContentHostingService =vol1
> >
> > When usage hit 70% we added two more (vol2,vol3) and new files are now
> > being spread across all three successfully.
> >
> > However, I'd like to have Sakai stop putting new files on vol1 since
> > it's over 70% full, but still have the content currently there be
> available.
> >
> > I think that simply taking 'vol1' out of the list is what I'd want to do
> > like:
> > bodyVolumes at org.sakaiproject.content.api.ContentHostingService=vol2,vol3
> > since existing vol1 content references would still be in the database.
> >
> > Testing on our development server seems to show this works, but I'd like
> > to get some confirmation that this is indeed the right thing to do.  I
> > couldn't find anything in the documentation.
> >
> > Could someone verify if this is (or isn't) what I should do?
> >
> > Thanks,
> > John
> > --
> > ______________ John F. Hall ______________
> > Programmer/Analyst III, IT-Web Development
> >         University of Delaware
> > _______________________________________________
> > production mailing list
> > production at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/production
> >
> > TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
> --
>
> Jeff Cousineau
> Application & Web Infrastructure, Core Services and Infrastructure
> Infrastructure Services, Information and Technology Services
> University of Michigan
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20110105/230ce82a/attachment-0001.html