Following up on the question of M and E datastreams - where does the M content
actually go?
At Yale, we've been using the DefaultLowlevelStorageModule without incident
with fedora 3.4 for the past 3-4 years, but in planning for a future larger and
integrated fedora repository are looking at other options.
There is this document (not sure if it's up to date):
https://wiki.duraspace.org/display/FEDORA34/Configuring+Low+Level+Storage
in which akubra is described to have a non-database dependent hash driven file
system vs the date/time algorithm of the default module. But I'm not sure what
that means in terms of real advantages in maintenence and performance.
In that document there is also mention of 3rd party plugins for iRODS, SRB, and
Sun Honeycomb, which kind of goes a little way to Richard Green's suggestion on
the list earlier today about a wish for integration of object policies. There
was also a recent post from Nikhl Tayal currently creating a Dell DX6000 plugin
and some fedora futures initiatives to connect with asynchronous storage
solutions. Again I'm not entirely clear of the pro's and con's of these are in
terms of a large scalable fedora implemetation/cluster that can handle TB+ of
heterogenous data from small metadata files to large video preservations
masters.
So I guess I'm asking if anyone has any suggestions, recommendations, or
experience working with these various LLStore modules.
Thanks,
Eric
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
