StorNext cvfsck free space fragmentation


Many StorNext users have a handful of tools that come with the default StorNext installation, basic or full blown with interface.

One of those tools which can assist in troubleshooting is cvfsck. The most common use of cvfsck is to verify the file system itself. It’s a simple and powerful command line tool if you use it for the right reasons.


Checking the health of the file system can be done when the file system if active but not really recommended as the journal is updated frequently. It’s basically a sanity check which may lead you to the action to take the file system offline. Continue reading

Short-Sizing StorNext (cvfs) LUNs


Every now and then you may have seen it or never have … lucky you. Under certain circumstances you may face the problem that you have configured your RAID with the same LUN size or even have used the wizard of the RAID vendor and StorNext (and other tools) will show you a different size on the LUNs in the OS.


As a starting point, let’s assume our configured RAID provides 4 LUNs to the system. Two of those LUNs have a sector size of 9065074317 and two LUNs have a sector size of 9065074333. This can be seen in the output of /usr/bin/cvfs/cvlabel -l as follows: Continue reading

Never Mix Up Throughput or IOPS with Stream Performance

What to Know and What to Ask When You Shop for Storage at NAB or

How to Evaluate Different Storage Solutions for Post,  Where Real-Time Access Is Crucial


The most important mistake to avoid when evaluating a SAN (or NAS) storage solution is also the most common one: confusing throughput or IOPS with stream performance. Throughput or high IOPS will not provide you with the performance you need in a workflow with real-time access requirements.

And this is where it becomes tricky. Unfortunately not all storage vendors possess the expertise or experience to really understand the difference between the requirements of their standard industrial customers and their customers in the M&E or post-production sector. While industrial customers consider a storage setup with high throughput and IOPS to be high performance, customers in M&E need high (real-time) streaming performance. Bandwidth and IOPS are secondary, if not entirely irrelevant.  Post-production applications working with sequence-based raw (single frame) material write to and read from the storage sequentially, as opposed to unstructured IT environments where data is read and written randomly.

A pretty common and recurring situation when it comes to buying storage could look like this. A customer expects to have eight attached clients in total, six of which need real-time read/play in 2K raw, while two clients will require 4K raw access. Most customers do the math this way: 2 clients x 4K = 2400MB/s   +   6 clients x 2K = 1800MB/s; therefore a total throughput of 4200MB/s is required.

Since all storage vendors know what their products can do in regard to IOPS or random throughput, a vendor may tell the customer that they need, for example, two RAIDs, each providing 2500MB/s. Combined, that will provide the requested 4200MB/s, plus 800MB/s of overhead. For a standard IT-based environment, this calculation might be correct, and the SAN would probably be perfectly suitable. But when it comes to sequential and concurrent data access by more than one client at a time, the entire setup becomes a whole different beast. With a setup like this, the post-production facility will realize a couple of weeks after the SAN has been deployed that the performance is far below the eight concurrent streams they actually needed.

What went wrong? Our example customer XYZ’s requirements have not been accounted for, or – even worse – were not understood in full. To explain this in a pictographic example, customer XYZ needed a setup that was able to play two songs from a record at the same time – and vendor ZYX provided one turntable record player. Now the customer has to lift the arm of the record player (seeking) and move it to the new position on the record (latency), then lift the arm again to return it to the original position (seeking and latency) and start from the beginning. Every time the arm is lifted, there will be no music playing, no matter how fast the arm is moved.


Read full article at


  • " “Hello and welcome to my personal blog.

    In 20+ years working in diversified IT environments, I’ve gathered some wisdom that I’m happy to pass on and share some (hopefully) helpful and interesting tips and tricks around SAN/NAS solutions. "

    Roger L Beck
  • How to manage permissions on a StorNext filesystem


    In a shared environment as in a Linux based NAS, the permissions can be set/enforced via the exports file or the Samba configuration or even through yp (yellow pages aka NIS). Comparing it to a SAN based solution you will most likely run into permission issues which you haven’t experienced before. Before each client was writing into the shared volume and all the others could collaborate as expected and since you have a SAN, you face the problem that content created by client-A can’t be modified from client-B or others.
    Continue reading