Let's Bid Adieu to Block Devices and SCSI

Email Print Digg This Add to del.icio.us

The concept of block devices has been around for a long time, so long it's hard to pin down when the technology first appeared. I checked with some friends who are old-timers (although they might object to that term), and they thought that 35 years was a good guess. That is a very long time for a technology concept.

SCSI has been around for a long time too. There is an excellent historical account of SCSI here. The history is interesting, and it launched more that one company, but the standard was published in 1986, which makes it nearly 19 years old. Since that time, modest changes have been made to support interface changes, new device types, and some changes for error recovery and performance, but nothing has really changed from the basic concepts of the protocol. The last 18 years have been evolutionary at best.

So we have storage devices that have been working the same way for 35 years, and a common protocol to talk to devices that has been around for 18 years, with very little in the way of changes. Folks, I might be missing something, but that is a very long time for a set of technologies.

There are two areas that I see as big problems with these dated technologies:

1. End-to-end lack of coordination and knowledge
2. RAID rebuild

File systems and block devices are not well coordinated. What file systems are supposed to do is virtualize the storage so that you do not have to keep track of or maintain an understanding of the underlying storage topology. Well, we have achieved that, and things do not work very well. Here are some examples:

• File systems cannot pass the location or locations of a file to a RAID device, so RAID devices cannot determine what blocks to "readahead" into the cache so that the next request comes from the RAID cache.
• File systems do not track access patterns to readahead by skip increments. If a file is read reading 64 KB, skipping 128 KB and reading 64 KB, the file system will not issue a readahead nor can the RAID controller.
• Many file systems stripe data so that blocks are not sequential on LUNs, and RAID devices have no chance to read data ahead since the blocks requested are not sequential.

We'll go into more detail on these issues below.

Location of a File

If the file is sequentially allocated on a single LUN and read sequentially, then a RAID device's readahead cache will work just fine. More often that not, that is usually not the case. Most file systems I have seen have multiple write streams creating and adding to existing files. Given that almost all file systems use a first fit algorithm for allocation, data is not sequentially allocated. See this article for more information on file system allocation.

If files are not sequentially allocated, simple block devices have no idea how to readahead the data. A number of file systems try to get around this by allocating large blocks of data and then releasing it when the file is closed, or similar techniques that try to preallocate data space. From what I have seen, these techniques help, but over time the allocation maps become fragmented unless the files are all the same size, so you are back to square one.

Continued on Page 2.

Email Print Digg This Add to del.icio.us

Enterpriseitplanet Forum Topic By Replies Updated Starter bitbyte 0 11-18-2008 06:56 AM Best Raid array for (6x) 1TB hard drives MarcusXP 2 11-11-2008 12:43 PM When you're a small business and you can't afford to lose those accounting statements Planet 3 11-4-2008 06:32 AM Storage Software jaxbackup 2 11-2-2008 03:57 AM Micronet Unveils Maxnastm Hybrid NAS/iSCSI Planet 0 10-30-2008 09:41 PM