Storage optimize

Block level storage vs. file level storage: A comparison

Block level storage sales have gone through the roof as more businesses realize its flexibility. File level storage is still a better option when you just need a place to dump raw files. Learn more about when to use which type of storage.

Long gone are the days of one file server sitting in a corner humming away while employees save their files to the local hard drives. Today, storage devices are abstracted from the server.

IT pros are now required to make important decisions when choosing storage for a particular task. To help with your decision making process, here's an overview of some of the high-level differences between block level storage and file level storage. I also provide information about when to use which type of storage.

Block level storage

Anyone who has used a Storage Area Network (SAN) has probably used block level storage before. Block level storage presents itself to servers using industry standard Fibre Channel and iSCSI connectivity mechanisms. In its most basic form, think of block level storage as a hard drive in a server except the hard drive happens to be installed in a remote chassis and is accessible using Fibre Channel or iSCSI.

When it comes to flexibility and versatility, you can't beat block level storage. In a block level storage device, raw storage volumes are created, and then the server-based operating system connects to these volumes and uses them as individual hard drives. This makes block level storage usable for almost any kind of application, including file storage, database storage, virtual machine file system (VMFS) volumes, and more. You can place any kind of file system on block level storage. So, if you're running Windows, your volumes will be formatted with NTFS; VMware servers will use VMFS.

File level storage devices are often used to share files with users. By creating a block-based volume and then installing an operating system and attaching to that volume, you can share files out using that native operating system. Remember, when you use a block-based volume, you're basically using a blank hard drive with which you can do anything.

When it comes to backup, many storage devices include replication-type capabilities, but you still need to think about how to protect your workloads. With this type of storage, it's not unusual for an organization to be able to use operating system native backup tools or third-party backup tools such as Data Protection Manager (DPM) to back up files. Since the storage looks and acts like a normal hard drive, special backup steps don't need to be taken.

With regard to management complexity, block-based storage devices tend to be more complex than their file-based counterparts; this is the tradeoff you get for the added flexibility. Block storage device administrators must:

  • Carefully manage and dole out storage on a per server basis.
  • Manage storage protection levels (i.e., RAID).
  • Track storage device performance to ensure that performance continues to meet server and application needs.
  • Manage and monitor the storage communications infrastructure (generally iSCSI or Fibre Channel).

From a use case standpoint, there are a lot of applications that make use of this block-level shared storage, including:

  • Databases. This is especially true when you want to cluster databases, since clustered databases need shared storage.
  • Exchange. Although Microsoft has made massive improvements to Exchange, the company still does not support file level or network-based (as in, CIFS or NFS) storage. Only block level storage is supported.
  • VMware. Although VMware can use file level storage via Network File System (NFS), it's very common to deploy VMware servers that use shared VMFS volumes on block level storage.
  • Server boot. With the right kind of storage device, servers can be configured to boot from block level storage.

File level storage

Although block level storage is extremely flexible, nothing beats the simplicity of file level storage when all that's needed is a place to dump raw files. After all, simply having a centralized, highly available, and accessible place to store files and folders remains the most critical need in many organizations. These file level devices -- usually Network Attached Storage (NAS) devices -- provide a lot of space at what is generally a lower cost than block level storage.

File level storage is usually accessible using common file level protocols such as SMB/CIFS (Windows) and NFS (Linux, VMware). In the block level world, you need to create a volume, deploy an OS, and then attach to the created volume; in the file level world, the storage device handles the files and folders on the device. This also means that, in many cases, the file level storage device or NAS needs to handle user access control and permissions assignment. Some devices will integrate into existing authentication and security systems.

On the backup front, file level storage devices sometimes require special handling since they might run non-standard operating systems, so keep that in mind if you decide to go the file level route.

With the caveat that you may need to take some steps with regard to authentication, permissions, and backup, file level-only devices are usually easier to set up than block level devices. In many cases, the process can be as simple as walking through a short configuration tool and moving forward.

If you're looking for storage that screams -- that is, if you need high levels of storage performance -- be very careful with the file level option. In most cases, if you need high levels of performance, you should look at the block level options. Block level devices are generally configurable for capacity and performance. Although file-level devices do have a performance component, capacity is usually the bigger consideration.

File level use cases are generally:

  • Mass file storage. When your users simply need a place to store files, file-level devices can make a lot of sense.
  • VMware (think NFS). VMware hosts can connect to storage presented via NFS in addition to using block level storage.

Convergence of block and file storage

The block and file worlds are converging. Some new storage devices include both block and file-level capabilities. So if you are torn about whether to go with block or file, a hybrid/converged device might fit your needs.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

6 comments
SrTechGuy
SrTechGuy

Hi Scott,  I've read this and still don't understand the difference.  You say: "This makes block level storage usable for almost any kind of application, including file storage..."  But if block can be used for file, how is file different than block? 

You also say: "nothing beats the simplicity of file level storage when all that's needed is a place to dump raw files."  But with block storage I can store files with it as well.  You said: "think of block level storage as a hard drive in a server"  OK, so I can put files there, so I'm still left with the fundamental question: What is the difference between block and file storage?  I don't know if you are still following this as your post is 3 years old, but I'd appreciate a response if you can.  I just don't get this.  No offense, but your article didn't help me at all.  In fact, it confused me further.

s2ms2r2
s2ms2r2

I was asked this exact question for an interview, and tho I did explain, I couldn't have done it as well as this article.

oldorange1
oldorange1

you'd think with 15 years in IT this article would actually explain and convey in detail the real and basic concepts of, differences between, and practical use's of, file vs block storage devices. sorry, i still don't get it.

pgit
pgit

it isn't simply all about cost. I can see there's some serious consideration to be made regarding backups, too. I'd sort of been of the mind that your block solutions are inherently better for any given task, but an expensive luxury. Nice to know that for 99% of my clients I've actually given them the more desirable AND less expensive option. =) (i.e. I don't do clustered databases)