File storage and block storage

Question

I came across file storage and block storage and was exploring and based on what I could understand, it is as follows:

1. Block level storage

   A. Requires a separate volume and an operating system on which it will be mounted as a separate hard disk and can be used to store raw files.

   B. Is used on the server side and for performance over capacity.

   C. It has its own backup software, etc.

   D. It uses fibre channel and iSCSI communication for access.

   E. It has no access to anything inside, it's just blocks of data.

2. File level Storage

   A. File level storage does not require a separate OS to operate.

   B. It is chosen for capacity over performance.

   C. It does not have a separate backup software of its own.

   D. It is the the file access system which is done through NAS etc…

Based on the above, my questions are:

1. Block level storage questions:

   A. Block level storage is just bare metal storage with no access to files, so why does it require a separate OS because OS will also have a file management system, so it will become more of a hyrbrid with both File and block storage options?

   B. If the above is true, then are SSD and SATA hard-disks kinds of block storage devices?

   C. If the above is true, then block level storage is also present on the user side because of the SSDs and others, why then is it used only on server side?

   D. Why is backup software required when we do not have access to any files inside?

2. File level storage questions:

   A. How does file storage does not require separate software to operate?

   B. When you have have access to files in this and can modify, read and write files, then why is backup software not present?

   C. Just like we have finder on Mac OS X, which is also file level storage, wherein we get to manage our files?

Please clarify my above questions and let me know where I am wrong.

Answer 1

It seems to me that you're confusing cloud block storage solutions like Rackspace's Cloud Block Storage or Amazon Elastic Block Store with the management of actual network storage hardware. When you launch a cloud server, you don't get anything like a public iSCSI endpoint to attach your own storage to; since iSCSI is cleartext that would be a giant security hole.

Instead, cloud providers offer block storage as a layer of abstraction over network (or local) storage solutions within the datacenter your server is actually located within. You can think of block storage like a virtual USB key - you can plug a volume in to a server, mount it like any other drive, read and write files on it, then detach it and re-attach it to another - and ideally you don't have to worry about the mechanism that's physically used to accomplish this (as long as your performance is satisfactory, of course).

Points A, B and C under "file storage" really sound to me like they're describing object storage, like Cloud Files or S3, instead. You generally don't mount these directly like a drive (although it is technically possible), and instead use them through a REST API of some sort. They offer the potential of much greater storage capacity than you'd get on a typical hard drive, with the costs of being eventually consistent and having higher-latency access. On Rackspace, you can also publish them to a content delivery network to do things like host a static website. Useful, but it doesn't sound like what you're looking for.

To answer your specific questions:

1. Block level storage.

   A. Attaching a block storage volume to a server is just like plugging in a USB key or hooking up a physical drive. It exposes raw, uninterpreted device access. So, just like any other drive, you need an OS on a server to format it and do useful work with its data. A volume has no processor, so unless it's attached to a cloud server, it can't do anything useful!

   B. When you create a block storage volume at Rackspace, you get to choose whether you want it to be backed by an SSD or a SATA drive, to give you some control over performance tradeoffs: SSDs will be much faster but more expensive. Both are kinds of block storage devices, though.

   C. I'm not sure what you mean by "the user side" here. Because of the security concerns I linked before, you can't mount a block storage volume outside of the datacenter it's created in, so you can only attach it to cloud servers within that datacenter. You can't, for example, mount one from your desktop.

   D. Snapshots (Block Storage backups) are just byte-for-byte copies of whatever you've put there, so it actually doesn't deal with the filesystem at all.

2. File level storage.

   A. If you are talking about Cloud Files: you don't need specific software because it uses a REST API, so you can use anything that talks HTTP to manipulate it, such as Rackspace's web UI.

   B. That's a good question! I have heard other customers request some kind of backup capability, but I don't know where it is on the roadmap. In the meantime, you can use the COPY operation to perform server-side copies of your stored objects and do backups manually that way.

   C. Since you generally don't mount Cloud Files containers directly into your filesystem like I said before, you can't use Finder directly to manipulate objects - instead you use the API, an SDK, or the web UI to work with them.