A Perfectly Normal Namespace for the DESY Open Storage Manager
Paper: 409
Session: C (talk)
Speaker: Fuhrmann, Patrick, DESY, Hamburg
Keywords: data management, file systems, hierarchical storage management, mass storage
A Perfectly Normal Namespace for the
DESY Open Storage Manager
Patrick Fuhrmann
DESY Hamburg ZDV
Abstract
Up to the end of '96 the three large active experiments at
DESY produced an amount of 15 TBytes of raw data for that
year. This number is at least doubled by the process of data
reconstruction. In total there are more than 30 TBytes of
all kind of data online available on two different robot
systems. The management of that impressive amount of data
is handled by the Open Storage Manager (OSM), an derivative
of the original Lachmann product. Beside the fixed structure,
which divides the volume space into Stores, Storage Groups
and Storage Levels, the namespace of the userfiles is flat
and doesn't support any kind of hierarchy. A simple and
reliable method of mapping this namespace to an hierachical
one is to store the tapefile identifiers in files of an
ordinary filesystem and to use special tools to do all the
necessary manipulations like remove, listfile and copydata.
Those tools operate on the filesystem names and behave
similar to the corresponding native commands but they
actually handle the files on tape. This scheme worked fine
for at least two years but contained certain drawbacks and
pitfalls. Unexperienced users tend to use the native
filesystem calls on that construct, so we often ended up in
files on tape with no reference in the filesystem or large
datafiles in the filesystem itself which were intended to
reside on tape. Another missing feature was some kind of
quota system with configurable user grouping which extends
the existing unix groups. So the idea was to create
something more convenient for us and the enduser. The new
design should not have any special requirements to the
client. It should be able to distribute the namespace among
the clients of different Unix Platform. The enduser should
be able to assign a small piece of information to the
tapefile. This metadata stays with the tapefile across moves
and renames but is direct accessable and does not reside on
tape. Our way to come along with all those requirements was
to build our own NFS2 service with an upgrade option to NFS3.
This solution gave us the power to perform the filesystem
and OSM actions consistently. The requirement for the clients
are minimized. They only need TCP/IP sockets, the ONC RPC's
and NFS2. Due to the poor performance of NFS2 concerning the
transport of large amounts of data we decided to switch off
all kind of real I/O via NFS2 and stay with a special tool
to do the real file I/O. So using the 'cp' command by
mistake, will result in an I/O error to remind the user to
use 'osmcp'. All other filesystem operations are allowed
and reflect the attributes of the tapefile.
Additionally we are using this NFS Filesystem as database
for the administration and distribution of OSM related
applications, which gives us a nice way to administer a
highly distributed system from just one point.
The descibed scheme is in production since November 1996 and
contains all data managed by the Open Storage Manager.
We estimate, that during the first quarter of 1997 nearly all
active data will be handled by the OSM.