Comments on: Objects To Desire

By: christophe

christophe — Wed, 18 Apr 2007 08:32:35 +0000

Indeed, as ernst pointed out, the term object looks strangely simplified to me. I do not know anything about OSD (yet another TLA with 20 meanings, including ObjectStorageDevice?, OnScreenDisplay, etc), but why would an object not have a name, access controls and metadata ? In software, it even has methods to access it, encapsulation etc.

On the other hand, it’s clear to me that the storage of the future won’t be a hierarchical file system. Directories are things of the past. Attaching resources to a tree is a pain, and there should never be something like two different copies of the same information just because it’s located in another leaf of the tree.

So, why not consider “Storage 2.0″ directly, and introduce more meaning (and security) in the storage subsystems ? From what I see here, OSD is likely “too little too late” to change a whole industry.

By: Andrew

Andrew — Mon, 19 Mar 2007 01:58:23 +0000

interesting…

What would be the key reason to move away from blocks to objects?

By: Ernst Lopes Cardozo

Ernst Lopes Cardozo — Fri, 16 Mar 2007 09:53:49 +0000

The OSD component keeps track of which blocks are used to store the object. In that decision it must also take care of performance issues: is this object accessed often? Is it mostly read or also written to? Such issues determine where on the disk (inner or outer track), striped over how many disks and even on what type of disk the object should be stored. To know these parameters requires metadata that today typically resides in a directory in the file system. That could be separated, but then each object has a sidecar to keep track of these usage parameters, not quite your naked object any more. Also, to be able to optimally allocate blocks to the object, the OSD function must reside way above the disk drive layer, so we probably need more than simply an extension of the SCSI protocol. Otherwise, certainly an interesting thought. Always good to create separate architecture layers for separate functions.

By: Chris M Evans

Chris M Evans — Fri, 16 Mar 2007 08:08:09 +0000

Hmm, whilst I see the point, I don’t see how it could be easily adopted. Existing file systems, DBMSs etc have all been built and optimised to work with blocks. That would require rather a large rewrite of an awful lot of code. If there was a nice migration strategy, then perhaps it does have a future.

By: Robert Pearson

Robert Pearson — Fri, 16 Mar 2007 05:08:39 +0000

RE: “We’d simply manage . . . . OK, what would we manage?”
Interesting thought…
Objects are pretty close to bytes and blocks but less than files. Not talking size here but atomic/molecular qualities.

My solution to this was to introduce the “Unit of Information”. I have a big, long “Operational” definition to try and cover all the exceptions, dead-ends and loop-holes. The “Unit of Information” has been greeted with deafening silence. The “Managed Unit of Information” hasn’t fared well either.

A “Managed Unit of Information” is a “Unit of Information” with an SLA (Service Level Agreement). This means some human decided the Unit of Information has ROI (Return on Investment) capability. All Units and Managed Units of Information have TCO. It is the ROI/TCO ratio that matters.

You can use the same approach for OSD and its objects. It fits nicely.

ECM (Enterprise Content Management) needs a Lower Metric molecular concept to deal with Information. The atomic is not sufficient. The atomic works fine for Units of Technology.

You can also apply qualities like scalar and vector to OSD objects or Units of Information. Vector Information has more ROI potential but higher TCO than scalar. Applying these qualities can be very interesting for mapping the Information Content.

When you have all these objects flying around in ad hoc Information space the “Speed Limit of the Information Universe” becomes very important.
How quickly can these objects be aggregated and dispersed in response to requests?

The Information Stack (IS) takes on a new meaning and significance.