IBM i Single Level Store …. In Lieu of a Crystal Ball

When the System/38 was being architected, it was recognized that underlying hardware technology was subject to unpredictable change. While it didn’t take a crystal ball to understand that change would be inevitable, having one to forecast the future of storage technology sure would have been nice. But as we all know, there is no crystal ball. This reality led to the development of Single Level Store. A key feature of Single Level Storage (SLS) architecture is that it insulates the upper-level code from the specifics of the storage technology it uses. Along with the Technology Independent Machine Interface, TIMI (see Steve Will’s “TIMI - Protecting Investments and Integrity in IBM i”), SLS is a fundamental element of the design that has allowed IBM i to continue to take advantage of new capabilities seamlessly.

Single level storage makes memory and disk space one entity; you do not need to know where your programs or files are stored. When you access something, you request it by name, and IBM i will automatically find it for you. Is it already in memory? Super! If it’s not, the storage management component will find it, wherever it may reside on disk and bring it into memory. You don’t need to worry about where the disk is or what type of disk is used. You can easily add additional storage, including solid state drives, to your existing disk configuration. The storage management support effortlessly introduces disks to the system regardless of their capabilities or technological frameworks.

Let’s review some of the technical advantages at your fingertips with IBM i and SLS along with the integrated storage management it incorporates: 

1. You can seamlessly optimize the use of solid state drives. This ability is an extension of automatic storage management. IBM i can automatically place your frequently accessed data on SSDs; IBM i with SLS manages your storage.
   
   But did you know that with the magic of SLS, you can also get immediate benefits of a very fast IPL by putting your load source on SSDs? Several IBM i clients have moved entirely from spinning disks to SSDs; substantially reduced IPL time was among the many benefits
   
   
2. You can transparently add more disk capacity and automatically balance your use of that additional storage.
   It’s critical to have your data and files distributed across disk units to allow for parallelism when accessing that data; you do not want a single disk unit to become a bottleneck. IBM i’s storage management will do this automatically for you. You do have controls, such as trace and balance for fine tuning, but once you have a configured environment, IBM i will take care of it all for you.
   
   
3. You are alleviated of the need to manage where your data is stored or the space allocated to file systems.
   On many non-i systems, you will find storage allocated to file systems. When the file system gets full, you will get errors until you either increase the size of the file system or delete files to free up space. There may be plenty of space available on the physical disk, it’s just not assigned to that particular file system.
   
   When I first started working with some software on a Unix environment and I discovered this requirement, I was dumbfounded. Why would anyone want to worry about how much storage is allocated to which file system? Why doesn’t the system take care of that for you? After all, there’s plenty of disk storage available!

IBM i Single Level Storage is well documented in the IBM i Information Center topic, IBM i Storage Management. Interestingly, this article is geared toward readers familiar with x86 storage architecture.

Other blogs on SLS include Steve Will’s “The “New” Value of Single Level Store” and Mike Cain’s “One of the Crown Jewels: Single Level Storage.”

Single Level Storage makes i easy.

 

 

 

 

Comments

[andres]

LS is about mirror.

Because of SLS, is it impossible to create a distributed database in IBMi?

I´d like to see a feature in IBMi where i can switch iASP in seconds and i dont need to varyonn the database in the second node.

[Dawn May]

The following information was provided by my DB2 contacts:

Single-level store does not prevent from doing what you want.
In general, an IASP is also a relational database. The IASP must be varied on or the disks simply are not available. However, you do not have to switch to the IASP to access the database. Like any other database product, your application can issue an SQL CONNECT statement to connect to that database and issue SQL statements.

Even easier, we support 3-part names and aliases in SQL so we can implicitly connect for you when you issue an SQL statement that references a remote database.