Enterprise Software

Understanding Novell Storage Services

With NetWare 5, Novell introduced Novell Storage Services (NSS). In this Daily Drill Down, John Sheesley examines some of NSS's features and benefits.

NetWare’s strongest feature has always been file sharing. When Novell first introduced what it now calls its traditional NetWare file system with NetWare 386, the file system appeared to be limitless. In the last decade, as the numbers and sizes of files increased, the traditional file system quickly began to show its age.

With NetWare 5, Novell introduced Novell Storage Services (NSS). If you’re comfortable with the file system that came with NetWare 3.x and 4.x but you’re new to NetWare 5.x, you may be unfamiliar with the benefits of NSS. In this Daily Drill Down, I’ll look at some of NSS’s features.

Breaking down tradition
If you’ve used NetWare 3.x or NetWare 4.x in the past, you’re probably pretty used to NetWare’s file system. It hasn’t changed much since Novell first introduced NetWare 386. But then again, until recently, it didn’t really need to.

NetWare 3.x and 4.x basically share the same file system. The file system originated back in the late ’80s and early ’90s, with the introduction of NetWare 386. When Novell first designed the NetWare 3.x and 4.x file system, the system looked almost limitless. NetWare’s traditional file system was designed at a time when hard drives shipped in the hundreds-of-megabytes range. Multi-gigabyte drives that ship with the cheapest computers today were nonexistent or way too expensive for general business use.

Novell, however, did have the foresight to design NetWare’s traditional file system with plenty of room for growth. Novell’s traditional file system allows you to have 100,000 files open on your server at the same time. It supports file sizes up to 4 GB in size and drives up to 32 TB. You can also have up to 64 volumes on your server.

NetWare 3.x and 4.x versions up to NetWare 4.1 also allow up to 2,097,152 directory entries per volume. When Novell released NetWare 4.11, it increased this maximum to 16 million directory entries. Directory entries are entries in NetWare’s file system that identify files on the server. They can represent directories or files.

However, the number of directory entries doesn’t directly reflect the maximum amount of files you can place on each volume. That’s because a file may consume more than one directory entry. This most commonly occurs when you have more than one name space loaded on your volume. A file will take one directory entry for each name space loaded. Therefore, if you have three name spaces loaded on a NetWare 3.x volume, you can have a maximum of only 699,050 files on your server. If these are all 1-KB files, you could theoretically fill up a multi-gigabyte hard drive with as little as 699 MB because of directory-entry limitations.
The 699,050 estimate is made without delving into all the details of how other factors affect that maximum, including block size, suballocation, and NetWare system files. I offer that estimate for argumentative purposes only. Many different factors will determine the maximum number of files and the amount of space they’ll take on your server.
Eventually, as networks became more essential in business and as the Internet grew in popularity, the traditional NetWare file system’s limitations became increasingly apparent. For example, as volume size grew, the amount of time it took for volumes to mount also grew—sometimes to unacceptable levels. Additionally, as volumes grew, the amount of time it took to repair volumes increased. (It’s not uncommon for VRepair to take hours to run on very large volumes.) Finally, as volumes increased, the amount of server memory needed to cache files on the server increased. Taking all these factors into account, you can see why the NetWare’s traditional file system was quickly starting to show its age.

NSSity—the child of invention
To overcome some of the limitations of NetWare’s traditional file system, Novell created Novell Storage Services. NSS first shipped with NetWare 5.0. Novell also included and updated it with NetWare 5.1. NSS has some important benefits over the traditional file system. Some of the improvements and benefits include:
  • Faster volume mount times.
  • Faster volume repair times.
  • Smaller memory footprint.
  • Larger volume limit.
  • Increased file size limit.
  • Increased number of open files available.
  • Increased number of mountable volumes.
  • Increased directory entry limits.

If you have large volumes on your NetWare server, you probably know how slow NetWare traditional file system volumes can be to load. In some cases, the server may go through its entire boot-up sequence, but your users won’t be able to access data because of the lag associated with long volume mounts.

Novell claims that after a clean shutdown, NSS volumes can load in about one second, no matter what size they are. Generally, traditional file system volumes take longer to mount the larger they are. Multi-gigabyte drives can take minutes to mount.

Mount times can be even longer if you have to recover from a crash. Doing a VRepair on a multi-gigabyte traditional volume can take as long as an hour, depending on the number of files and size of the volume. With NSS, Novell has claimed recovery times of under a minute, no matter what size volume needing repair.

If you’re familiar with the traditional file system, you also know that as volume sizes grow, you must have more RAM in your server. That’s because NetWare caches hard drive information about the volumes in the server’s RAM. The bigger the volumes are, the more information it must retain in RAM. If you don’t have enough RAM in your server for a given volume, the volume won’t mount.

On the other hand, NSS will mount any size volume with hardly any additional memory in your server at all. In fact, it requires only 1 MB of RAM. That’s in addition to the 10 MB of RAM that the NSS NLMs require. It doesn’t matter whether the volume in question is multi-megabyte, multi-gigabyte, or multi-terabyte in size. They all mount with the same amount of RAM in your server.

Because NSS can support much larger volumes than traditional NetWare volumes, more efficient use of RAM when mounting large volumes helps your NetWare server. Although the 32-TB limit of the traditional file system may seem like enough, in today’s network environment, you can quickly hit that limit, because files are getting larger and programs are taking more space on the network. NSS volumes can grow as large as 8 exabytes. (One exabyte is equivalent to one million gigabytes, or 2^60 bytes.)

Not only can you have larger volumes, but you can also mount more of them. As I mentioned earlier, the traditional file system allows you to mount only 64 volumes at any one time. NSS allows you to mount as many volumes as you want. The only limitation you’ll encounter is due to your client’s software. Current clients can see only the first 255 mounted volumes on the server.

NSS also lets you store larger files on those volumes. NSS can store individual file sizes up to 8 TB in size. This is very important if you’re going to use your NetWare server as a database server in conjunction with Oracle or another database program.

As if that wasn’t enough, NSS allows you to hold more files open than the traditional file system. Again, although the old limitation of 100,000 simultaneous open files sounds like an unreachable boundary, as your network grows and you start using it for more tasks, you can bump into that limit. NSS allows you to have one million files open at the same time.

Finally, NSS does away with almost all the limitations associated with directory entries in the traditional file system. As I said earlier, with NetWare 4.11/4.2, Novell allowed you to store up to 16 million directory entries on the volume. However, because of name space issues and other factors, the actual number of files you can store on your server will be far less.

In contrast, NSS can store up to 8 trillion files with its file system. Additionally, NSS automatically handles DOS, LONG, UNIX, and Mac name spaces without creating additional directory entries.

Nobody’s perfect
The limitations contained in the traditional file system don’t have anything to do with ineptness on the part of Novell programmers. Instead, the limitations come inherently with the 32-bit design that went into NetWare 386. As 64-bit computing has now become possible, Novell programmers can expand NSS to accommodate the limits of the new platform.

However, as powerful as NSS is, it still doesn’t do everything perfectly. Some tasks it can’t handle at all. Some of the key tasks that NSS currently can’t do include:
  • DVD drives—NSS will mount CD-ROM volumes as well as regular disk drives. However, it currently doesn’t work with DVD drives.
  • File compression—The traditional file system automatically compresses files that haven’t been used for a determined amount of time, preserving space on the volume. NSS can’t do this.
  • Block suballocation—Block suballocation allows the traditional file system to store files in partially empty data blocks. For example, if the block size is 64 KB on your traditional NetWare volume and you store a 65-KB file, it will consume two data blocks, filling one 64-KB block while using 1 KB of the next 64-KB block. The traditional file system can store data in the unused 63 KB that remains in the partially used block. With NSS, the block size is fixed at 4 KB, and partially used blocks are inaccessible. Novell plans to add block suballocation when it adds variable block size support to NSS.
  • SYS volumes—NetWare 5 and 5.1 force you to make the SYS volume a traditional file system volume.
  • Transaction Tracking System (TTS)—NSS doesn’t support TTS, which is a primary reason why you can’t host SYS on an NSS volume. TTS ensures that partially written transactions aren’t written to disk. NSS supports its own journaling file system, which isn’t currently compatible with TTS.
  • Disk mirroring/duplexing—You can enable disk mirroring and drive duplexing with traditional NetWare volumes. Currently, NSS doesn’t support either of these features. If you want any type of drive redundancy, you must rely on a hardware solution, such as using a RAID 5 controller and disk array.
  • VRepair—As you know, you use VRepair to fix problems on your traditional volumes if your server crashes. NSS doesn’t use VRepair. The VRepair utility has been replaced by the Rebuild and Verify utilities for NSS volumes. You can still use VRepair on your existing traditional NetWare volumes.
  • Disk striping—NetWare’s traditional file system internally allows you to stripe data across multiple drives to speed disk access to files. NSS doesn’t currently support software based disk striping. Although it does support disk spanning to spread NSS volumes across multiple drives, it won’t automatically locate files across multiple disks to speed disk access.
  • In-place upgrade—NSS doesn’t support the ability to automatically upgrade traditional volumes. If you want to replace an existing traditional volume with an NSS one, you must back up the old volume and then restore the data to the new NSS volume.

Novell has recently added one key feature to NSS that was missing from the original version of NSS that accompanied NetWare 5 and 5.1. That feature is user space restrictions. As you’re probably well aware, in NetWare you can restrict the amount of space a user can take on your network. Even if you have a 100-GB volume, you can allow a user to store only 1 MB of data on the volume.

NSS doesn’t support this feature. On an NSS volume, users can store as much as they want on your server and you can’t limit them. However, with the release of Support Pack 4 for NetWare 5 and Support Pack 1 for NetWare 5.1, Novell has corrected this oversight. I’ll show you how to put user space restrictions on your NSS volumes in an upcoming Daily Drill Down.

According to the NSS documentation, NSS does not support file and record locking. That’s an error in the documentation. NSS does indeed support all types of file locking. Novell states that NSS doesn’t support file locking by filename, but that’s not directly a problem of NSS. Instead, it’s been a problem in all versions of NetWare.

Don’t confuse regular file locking with the Opportunistic File Locking feature found in NetWare clients to speed access to files on your server. Opportunistic File Locking isn’t supported on NSS volumes.

As with any 1.0 release software, NSS has had a few growing pains since its introduction. One of the most troublesome cropped up after the release of Support Pack 1 for NetWare 5. If you applied Support Pack 1 to a NetWare 5 server that had an NSS volume, the Support Pack would destroy the NSS volume. Not a pretty sight. Since then, Novell has worked hard to test its support packs for problems with NSS. Even so, you should always make sure you have thorough backups, especially of your large NSS volumes.

In this Daily Drill Down, I’ve introduced you to the new NSS features found in NetWare 5 and 5.1. Although it’s not perfect in every way, NSS eliminates some of the limitations found in NetWare’s traditional file system. In upcoming Daily Drill Downs, I’ll show you how to deploy NSS volumes on your server, how to administer NSS, and how to enforce user space restrictions on NSS volumes.

John Sheesley has been supporting networks since 1986, when he got his hands on NetWare 2.2. Since then, he’s worked with the Jefferson County Police Department in Louisville, KY and the Genlyte-Thomas Group. John’s been a technical writer for several leading publishers, including TechRepublic, The Cobb Group, and ZDJournals. If you’d like to contact John, send him an e-mail .

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox