Skip to main content

A Redundant Array of Inexpensive Flash Drives

A redundant ZFS volume on flash drives? A RAID set on flash drives obviously has no practical value right now, but perhaps someday small redundant storage devices will be common. So why not experiment a bit and see what they look like.

Start with an old Sun desktop, Solaris 10 08/07, and a cheap USB 2.0 PCI card. Add a powered USB hub and a handful of cheap 1GB flash drives.

Plug it in, watch it light up.



If you've got functioning USB drivers on your Solaris install you should see them recognized by the kernel and the links in /dev should automatically get created. USB events get logged to /var/adm/messages, so a quick check there should tell you if the flash drives are recognized. If you can't figure out what the drives got named in /dev, you should be able to match up the descriptions in /var/adm/messages. In my case, they ended up as c2t0d0, c3t0d0, c4t0d0, c5t0d0.

For this project, I didn't want the volume manager to automatically mount the drives, so I temporarily stopped volume management.

# svcs volfs
STATE STIME FMRI
online 21:50:41 svc:/system/filesystem/volfs:default

#svcadm disable volfs

# svcs volfs
STATE STIME FMRI
disabled 22:38:15 svc:/system/filesystem/volfs:default


I labeled each of the drives


# fdisk -E /dev/rdsk/c2t0d0s2
# fdisk -E /dev/rdsk/c3t0d0s2
# fdisk -E /dev/rdsk/c4t0d0s2
# fdisk -E /dev/rdsk/c5t0d0s2


Then I created a RAIDZ pool called 'test' using all four drives.

zpool create test raidz c2t0d0s2 c3t0d0s2 c4t0d0s2 c5t0d0s2

The pool got built and mounted in a couple seconds.



# zpool status
pool: test
state: ONLINE
scrub: scrub completed with 0 errors on Sun Mar 23 21:55:32 2008
config:

NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
raidz1 ONLINE 0 0 0
c2t0d0s2 ONLINE 0 0 0
c3t0d0s2 ONLINE 0 0 0
c4t0d0s2 ONLINE 0 0 0
c5t0d0s2 ONLINE 0 0 0

errors: No known data errors


The file system shows up as available


# zfs list
NAME USED AVAIL REFER MOUNTPOINT
test 105K 2.81G 36.7K /test


I'm not sure what I'm going to do with it yet. It certainly isn't something I'll carry around in my pocket.

But if someone would make a USB stick that was the size of a current USB drive, and let me plug 4 or 5 8GB micro SD's in to it, and build the RAID magic into the drive, I'd have a whole bunch of storage in a pocketable form factor and redundancy as a bonus.

Comments

Popular posts from this blog

Cargo Cult System Administration

“imitate the superficial exterior of a process or system without having any understanding of the underlying substance” --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:Failing to understand the difference between necessary and sufficient. A daily backup is necessary, b…

Ad-Hoc Verses Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to …

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:
In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. The…