Object storage: The blob creeping from niche to mainstream Storage dull? Dry? Uninteresting? Not a bit. Everybody and everything uses data storage. Without we'd be lost. And thanks in part to the growth of cloud computing and big data, storage has risen up the agenda. In the big data universe, things are changing. Our methods of naming, storing and retrieving filesystems need to be …
Any time I hear someone telling me that planning is no longer necessary, I cringe.
Here, we are being told that we no longer have to worry about a single application taking up 80% of the shared storage space.
I beg to differ. If a single application takes up 80% of my allocated storage, I think I'd pretty damn well better know why and have planned for it beforehand, because if this is a surprise, then it puts in question the whole data structure that I have put in place.
Sure, I understand that all I have to do is subscribe to an additional block of shared storage. That doesn't mean that I shouldn't have planned it beforehand.
Planning is never an option.
I can see you missed the point of this.
When the storage pool is 80% full, your ex-boss will get a friendly call from EMC/IBM/HP/HDS* quoting him for more capacity, and he'll have all the money he used to pay you to buy it with.
* Delete as applicable
Interesting piece, Adrian. Good to see more discussion relative to the object technology space...finally. Just wanted to mention a feature I didn't see in the article, and in my opinion, one of object's most valuable, its capabilities in providing a foundation for information management. So much potential with this, but the architecture has to be right and you're correct that the products on the market today differ quite a bit in architecture. Having spent over 15 years in this space I've evaluated/competed with all of them and there's tremendous opportunity to really disrupt the storage industry; primarily file systems with that "right architecture".
Object won't obviate the need for file systems, but will substantially impact their use. As the advanced computing team from a major US university said during an executive briefing last year "...the file system has pretty much reached the end of its useful life", but also recognized it would continue to occupy a place in the environment (though much smaller in size). We'll also see object adoption move faster when SW engineers really begin to recognize what they can do with object and start using it as a development platform to deliver apps. Good to see Ms. Collier is in agreement on this point (worked with her in the past, Hi Lynn!).
The new paradigm of storing and interacting with information has emerged from the community networks and content sharing sites (Facebook, LinkedIn, Shutterfly, etc.) that rely on relationships, links, associations and "likes" (tags/metadata) where those relationships hold as much, if not more value than the actual content. The new generation of consumers, corporate users and technologists understand this paradigm far more than the stodgy, block-based, folder/file hierarchical technology of yester-year. Object technology provides an infrastructure that can persist and protect that data while enabling the creative "bit twiddlers" to take advantage of it in unique and exciting ways.
Anything that displaces the conventional file system is likely to require that same displaced file system under the covers. It may be invisible, embedded in some highly proprietary storage layer. However, sooner or later something is going to have to address it in conventional terms. That might even be the end user or admin. Less abstract elements of systems don't suddenly go away when a better abstraction is found.
A file name (or something like it) will likely continue to remain the most efficient path to an object regardless.
Yes and no to the "still need a filesystem under the covers". You can pretty much chop the directory tree off a traditional UNIX filesystem and use inode numbers as object IDs. For instance, the Object Storage Targets inside Lustre can be mounted locally on the storage servers for maintenance when the cluster filesystem is down, and what you then see is a placeholder filename for each inode in use, hashed into a containing directory tree to keep the directory sizes manageable. When the cluster filesystem is mounted, most operations refer directly to the inodes - it's only when a new object is created that its placeholder filename has to be added too.
As for efficiency: if you expose inode numbers to the filesystem layer, bypassing the directory tree and addressing inodes directory is certainly no *slower*...
....
As for efficiency: if you expose inode numbers to the filesystem layer, bypassing the directory tree and addressing inodes directory is certainly no *slower*...
Ummm I hate to have to point this out... but the inodes are the fucking filesystem. The directory tree is only a dictionary of inode assignment. So your object storage model is a filesystem without an inode dictionary.
A file name (or something like it) will likely continue to remain the most efficient path to an object regardless.
Thank you, it's nice to read a comment which is written by someone who understands storage. Maybe next time you can ask them a searching question about it as well, something about how they intend to maintain block pointers without a filesystem type of structure, and therefore make optimal use of the underlying storage technology?
"each unit benefits from an extended metadata identifier"
"the desire for information quality is driving data ingest ‘granularity’"
"his firm’s Simpana 10 product exists in this space as a hardware-agnostic software storage solution"
"we can intelligently expose data for more use cases through API integration"
"service-based virtualised computing architectures"
Centera was one of the first and is still the best. That is why almost every financial institution and thousands of health care and other companies have it. EMC tried to replace it but it it is so sticky because customers love it and it just keeps selling. Long live Object. Long live Centera.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
