Can I have multiple interfaces in one subnet?


It may have crossed your mind to have multiple Ethernet interfaces in a single subnet . Reasons might be that you would like to have some kind of manual load balance or restrict access in some way. And the result: It does not work quite right. I have heard many times that this is an invalid and wrong setup and won’t work. The thing is, you can make it work and if you need to have multiple interfaces in the same subnet, read on.


You configured your new and extremely fast NAS head. Plenty of storage, incredible local read and write speed and enough 10Gbit interfaces to satisfy the connected clients and the ones form your neighbor is necessary. You thought about trunking those interfaces but that doesn’t give you the control you’d like to have about the data flow. And, because you are a believer of a single subnet as long as you have less than 240 devices, you added the 4 new 10GbE ports into the same subnet.
Everything seems to be working fine but you expected more performance. While analyzing the traffic on the ports, you realize that the traffic isn’t distributed at all. Moreover, traffic from clients addressing port-3 goes over port-1. Whaaaaat?

Continue reading

Performance testing with vidio and frametest


Once you have your StorNext file system up and running, you may want to know what the performance is.

File system performance measurement and a holding hand to perform some troubleshooting to hunt down the root cause.


When you set up your file system, you may have or have not performed a speed test. Especially in a shared environment, you most likely want to know, how fast you can push/pull data from the file system. You also have researched the internet for some good ideas, tools, and what you should get out of your file system. Assuming here, that you stumbled upon dd, frametest, AJA System Test and BMD Disk Speed Test.  What you may not have found is the small command line tool within StorNext called vidio.

Continue reading

Here Is the Physics Behind the Magic 80% Rule for Media Storage and File Systems

You Shall Never Exceed 80% Usage. Ever. But Why?

This article was published on December 27, 2017 at and on January 1st, 2018 at

We’ve all heard it — the advice of both storage vendors and solutions providers to never use more than 80% of your storage . Otherwise …

Otherwise what? What terrible disaster can possibly happen if this rule is ignored?

Only a few obedient, safety-oriented users actually follow the instructions. The majority feels bold enough to bravely disregard the warnings. In their minds, they just want to use the entire capacity of the storage space they’ve purchased. 500 TB should be 500 TB and not 400 TB , they figure. Why lose 100TB of precious space for unknown reasons?

I feel the urge to write this article because I’ve seen many users, full of optimism, headed straight into disaster. Stunned to see that so many — even admins! — don’t seem to care, I want to spread the word: media storage is not an empty barrel that can be filled until it spills. You will run into a whole lot of problems trying to fill that barrel, long before it runs over.


 So Why Is There an Invisible Limit Assigned?

Continue reading

What’s the Best SAN File System for Sharing Media?

Spoiled for Choice:

Since it is an essential requirement for every computer, the file system has been taken for granted for a long time. There are more than 85 different choices for local file systems (at least that was the case last time I counted), including HFS(P), APFS, FAT32, NTFS, EXT4, XFS, and Btrfs to name just a few, all covering various kinds of hardware and providing a variety of features. You can find many informative articles explaining the differences in performance and limitations of local file systems, so I want to focus here on shared file systems — a whole different beast. Let’s start with a short trip into the past, to help us figure out why there are so many file systems to choose from in the first place.

SAN file systems

Know the Past to Understand the Present – and to Be Prepared for the Future

Not that long ago, really, we were grateful for the ability to share data amongst computers at all, utilizing protocols such as Network File System ( NFS ) for the *nix world, the Common Internet File System ( CIFS , aka Server Message Block or SMB) for Windows machines, followed by the Apple Filing Protocol ( AFP , aka AppleShare) for Apple computers. Network speeds were an earth-shattering 10 Mbit then, and with a lot of money, or a little luck, you might even have had an Asynchronous Transfer Mode (ATM) based network, providing a mind-blowing speed of 155 Mbit.

Performance has multiplied dramatically since then, with 40 Gbit basically being the standard today, and 100 Gbit right on the horizon — and that’s just for the Ethernet protocol. The development was similar with Fibre Channel (FC). A then-phenomenal throughput of 1 Gbit in 1997 has jumped to 128 Gbit some 20 years later, at least with adequate switches available today from vendors such as Brocade. In addition to these, the two most popular topologies for shared file systems, there are of course InfiniBand (IB) and Serial Attached SCSI (SAS), more commonly used for server-to-server or RAID-system-to-JBOD expansion, etc.

The Big Shift

Demands on network performance and speed skyrocketed when the movie industry started the digital revolution and created more and more computer-generated (CG) imagery. From 3D CG to VFX to color correction, every step in the production and post-production process of moving pictures was suddenly generating numerous digital media files. Instead of countless video tapes piling up in the archives of post-production facilities, unstructured (or “unfiled”) media files flooded the IT servers, creating data chaos and leaving IT personnel to invest a lot of manual effort in detangling the mess.

Read full article at →

configure XSAN 4 – Yosemite – El Capitan


You want to connect an OSX 10.10 (Yosemite) or OSX 10.11 (El Capitan) client to your existing StorNext SAN or XSAN. Both OSX versions are XSAN 4 based.

Yosemite’s embedded XSAN version is compatible with SNFS 4.3 & 4.7.
The XSAN version within El-Capitan apparently is only compatible with StorNext 5.x but not with StorNext 4.7 as officially listed in the matrix.

I don’t claim to know it better as the officials from Quantum or Apple but if you look under the hood, the cvversion command returns a 4.3 build. Based on that and the knowledge that many other users have connected their XSAN 4 clients to a SNFS 4.7 based MDC’s without any issues of connectivity or data integrity (would be the worst case ever), it’s up to you to go that path and connect to an existing 4.7 based StorNext MDC and step outside the supported matrix.

Continue reading