On Mon, Aug 25, 2008 at 02:17:57PM -0400, David Boyes wrote:
>> Bacula, as far as I know, is meant to work across different Unices.
>> If you insist on putting S3 support into the operating system's
>> kernel, you're effectively limiting your S3 support to the few
>> operating systems which provide this.
> Not at all what I'm doing. I'm doing a user-space API to a managed
> storage system. 

I apologise. In that case I completely misunderstood you. I thought you
were agreeing with the SCSI<->S3 thing.

> The applications are responsible for opening a channel to the managed
> storage system, asking to store an object, and receiving a unique
> object id in return. The application keeps track of the object by
> storing that unique object ID. The remainder of the details of how the
> object is stored and managed are *not the application's problem*. 

That would map very well indeed to S3's API.

>> Tapes, file systems, and S3 are three very different interfaces to
>> storage. Any sort of common emulation layer for all three is bound to
>> be either lossy, leaky, or both.
> Not emulation.

Sorry. Bad choice of words.

> I want the entire details of how data is stored and managed to be
> *opaque and invisible*.

Gotcha. What you're outlining here is very much a lossy abstraction (as
is Bacula's storage daemon). For the specified purpose, however, this
sounds very appropriate.

> This is how DFSMS works on z/OS, and it's *extremely* effective.

I'm not familiar with neither DFSMS nor z/OS, I'm afraid.

> I have almost 2 EB managed in this form right now. It works.

The amount of data does not impress me much. You could stream punchcards
and reach the same amount of storage. What's really interesting are the
interfaces and capabilities of your interaction.

>> Don't get me wrong. I'm all for abstraction layers. I've worked on a
>> few myself.  In this case, however, the appropriate abstration layer
>> is Bacula's storage daemon.
> The appropriate interface is to teach the Bacula SD to speak to the
> managed storage system, and never have to deal with Bacula storage
> management again.

Again, I made an (apparantly incorrect) assumption. What I should have
said was: "Of the currently existing entitites (namely Bacula and the
kernel), the appropriate layer at which to place this functionality, is
Bacula." An abstraction layer that provides a superset of the
capabilities that Bacula needs is a good idea. I like it.

> You then teach the managed storage system how to work with a new
> storage medium, and *every* application that uses it can then use the
> new medium transparently. 

Right.

> Not OS specific, not platform specific, not application specific. You
> need a C compiler and a TCP socket capability. I have that even on
> z/OS and Windows. 

Where can I see the code?

-- 
Soren Hansen               | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/

signature.asc
Description: Digital signature

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users