50Micron.com

So I’m trying a disk upgrade.  One of the spare 250G drives I threw into the Mac when I got it failed (Lower-bay, which I’m assuming was disk-2 of 2) so I decided I would try my hand at upgrading the disk.

I realized that the 250G drives i put in there won’t be enough to hold my pictures and music alone, let alone the rest of the stuff that I usually keep on my desktop.

So I found a 2TB drive to put in it’s place.

The Swap went swimmingly.  Shut down, pop the old drive out, pop the new drive in, took a little playing around (and a quick google search) to get the new disk added to the raid-set, and a few hours later, Tah-Dah. 

So then it comes to adding the other 2TB drive in and mirroring back.  Simple process right?

I shut down again, pulled the top drive out, put the new 2TB drive in it’s place, etc etc etc.

Nada.

It seems that while the data is contained on both disks, the host is only set to look at the first disk for it’s boot device.  Oversight?

So I used the google, something I’m priding myself on my ability to do these days.  (What do people with only one computer do when they get into trouble?)  And found that I have to boot from the CD and manually mirror the disk back using the disk-utilities on the CDRom.

Makes sense.  Though you’d think it wouldn’t be too hard to, on failing to retrieve boot information from disk0, to look on disk1 before giving up.

Does anyone of my five readers know if there is there a way to force a boot to the “up” drive in the set?

I would gravitate to the storage end of things wouldn’t I…

So here’s the underlying problem.

Note the 1.8TB RaidSet1.  Now Note the 232.8GB RaidSet1.

The problem seems to be that while both devices are owned by the raid set, and the “RAID Slice” itself on each drive is 1.8TB, the partition on the underlying slice is stubbornly stuck at 232.8G.

SO…

This makes the filesystem *WAY* smaller than it could be.

Since I don’t have anything appreciable on it…  I’m going to back it up using Time Machine, and reinstall.  (I’ve heard complaints about time machine, so I’m going to want to see work it before I actually come to depend on it.)

*THAT* will be tomorrow’s post.

My definition of “Day” changes…well…daily.

I’m having to do some shuffling of data off my old PC Workstation and I found something interesting.

MacOS can’t WRITE to an NTFS volume without a third-party driver.  It can read from it just fine.

I ran into a situation where I had to consolidate data from 2x 2TB drives onto one to free space for “The Next Step” (which you’ll read about tomorrow if you care) and so I connected them both to the Mac to hopefully do a quick ‘copy’ from one to the other.

Nope.  Not a chance.

MacOS can’t write to an NTFS volumes.  Now I found a few third-party drivers and tried one that had a 15 day trial version…  Only to find my way into what I can only assume is the Mac version of the “Blue Screen of Death”  (The “You must turn your computer off NOW” screen – how rude.)

What I find interesting about this is this.  Linux can read/write from an NTFS volume just fine.  Since MacOS is BSD Linux, I can only assume that Apple has made the conscious decision not to support NTFS writes.  Probably because it provides people with a simple migration path OFF Apple hardware, which, as any hardware vendor would like to believe, no-one would ever want to do.

Still – my experience is largely positive.  Got my work VPN up and running on it without too much angst and work.  And my son is sufficiently horrified at the sound of the power-on chord (there’s probably a fancy word for it) that I make up reasons to reboot when he’s in the room.

I can see that the entertainment value of this investment will be limitless.

Ok, given the changes to the storage arena I’ve been working on a revised “Tiering system” to incorporate all of the levels of data…importance?

My version of Storage Tiering is (or should be) as follows:

• Tier-1    – Symmetrix/Replicated – High Performance/Criticial Data
• Tier-2    – Symmetrix/NonReplicated – High Performance/Non-Criticial Data
• Tier-3   – Symmetrix/SATA/Replicated – High-Medium Performance/Critical Data
• Tier-4   – Symmetrix/SATA/NonReplicated – High-Medium Performance/Non-Critical Data
• Tier-5    – Clariion/FC/Replicated – Medium Performance/Critical Data
• Tier-6    – Clariion/FC/NonReplicated – Medium Performance/Non-Critical Data
• Tier-7    – Clariion/SATA/Replicated – Low Performance/Critical Data
• Tier-8    – Clariion/SATA/NonReplicated – Low Performance/Non-Critical Data
• Tier-9    – CelerraNAS/Replicated – Network Attached/Critical Data
• Tier-10  – CelerraNAS/NonReplicated – Network Attached/Non-Criticial Data
• Tier-11  – Atmos – Network Attached / Low Performance
• Tier-12  – Centerra (Content Addressable Storage) – Low Performance Archive / Highly Available
• Tier-13  – Primary Tape-In-Library (Automatic loading on demand via HSM)
• Tier-14  – Primary Tape-Out-Of-Library (Manual Intervention Required)

“Critical Data” vs. “Non-Critical Data” is simply a matter of how long you can be without the data should a failure or accidental deletion occur.  As all data is available in Tier8/9 storage (in theory).

I’ve also considered using Tier1/Tier1B to describe DMX storage vs. Clariion storage, given that there is a LOT of overlap in performance characteristics these days…

Oh, and iSCSI would be somewhere between 10 and 13….

Any thoughts?

I don’t know what most people know about TimeFinder, so I’ll start with a short introduction.

EMC Timefinder was developed to provide customers with a dynamic mirror they could use to try and cut some of the tediousness out of copying data, whether from one host to another or within the same host.

When I was working for EMC, Timefinder was still more or less in it’s infancy, and only came in one flavor.  (Now referred to as “TimeFinder/Mirror”)

A Timefinder volume is a volume that is essentially a dynamic mirror of a production volume.  Called a ‘BCV’ (for Business Continuance Volume) it was a straight 1:1 mirror of your production data.  (If you were running in a 2-Way-Mirrored configuration, the BCV essentially become a third mirror.)  At a point-in-time, you could split the third mirror off it’s production pair and make it available to another host.

The main benefits were obviously discovered in Backup.  You could split a BCV of your production data off, mount it to another host, and back it up to a locally attached tape library with zero network overhead.  Using this you could also use a single backup host to back-up copies of BCV’s from multiple production hosts.

Another good use for BCV’s was in development.  One story I like to tell was from I was an admin several years ago.  Developers liked to “break” their database on a friday afternoon, knowing that the restore from tape would take the better part of a day and in doing so they guaranteed they would make their tee-time.  With the advent of TimeFinder, I was able to tell them “Not a problem, I’ll have it back up in 20 minutes.”   The reason being that I could restore from the mirror almost instantly.

The main negatives for TF/Mirror are that in all cases, the initial synchronization has to complete before the data can be made available to the target system.  Now this is mitigated by the fact that after the initial relationship is established all further mirrors are incremental, meaning that only changed tracks are copied to the BCV volume, but it can still be a time consuming process.

Now EMC has come out with two new forms of TimeFinder in Symmetrix, very similar to the Clariion functionality.

TimeFinder/SNAP

  SNAP uses a process called “Copy On First Write”.   This uses a much smaller volume than the production volume as a “virtual device”  (Called a VDEV)   The VDEV serves as a list of pointers for each track in the volume.  Reads are serviced from the original volume until the track is changed.  When the track is changed the original data is copied to a cache area, and the pointer for this track in the VDEV device is changed to point to the cached original track.  In doing this the VDEV device will contain an exact copy of the production data as it was when the Snap session was activated.  When the data is no longer needed, you terminate the Snap session and the cached changes are discarded.

The data is available the instant the SNAP session is activated.

The downside to this is that all reads touch the production volumes.  In a heavily utilized system there can be a noticible impact.  Another negative is that SNAP sessions are limited to the amount of cache set aside.  A usual configuration is to set aside about 20% of the area used by production as “SnapCache”  This can then be used as needed.  If the SnapCache fills up, the Snap session ends and that is that.

TimeFinder/CLONE

  Clone uses another process, similar to SNAP, called “Copy On Access”.  Clone volumes are identically sized to the production volumes, which of course uses up more space, but provides for a more permanent home.  This provides the data permanance of TimeFinder Mirror, the speed of TimeFinder Snap, and the agility to move data from Standard volume to another standard volume. (Raid-1 production volumes to Raid-5 Development volumes is a good example)

What copy-on-access offers is the unique ability to use the volume before it’s actually finished mirroring.  When a clone session is first started, all the target volume contains are pointers to the source volume.  Every time a track is accessed, (read or write) it is copied to the target volume first.  (prior to any write operations)  If no options are selected this is the only time a track is copied.  If the -copy option is selected when the Clone session is created, a background copy of the production volume is started.  This will eventually result in a copy of the data that will persist after the clone session is terminated.  (when no option is specified, the data will disappear when the session is terminated)  There is also the option to copy (mirror) the entire production volume to the target volume before the session is activated.  This is called “Precopy” and is a close emulation to what is done using TimeFinder mirror without the limitations of having to use BCV’s as targets.

TF/Clone has to be the best of all worlds.  It gives you the flexibility of Snap with the data-resilience of Mirror, and the flexibility of being able to go from one volume to another without restrictions on what type of volume your target is.  (TimeFinder/Mirror requires the use of BCV volumes)

Timefinder is the production that gave me my introduction into EMC.  TimeFinder and SRDF are also the technologies I’ve implemented more often than any others in my work for (and with) EMC.

If you’ve got questions, feel free to post them.  You’re probably not the only ones.

RAID-S isn’t striped.  If it were it would be Raid-5.

EMC utilized Raid-S as a stop-gap to the fact that they didn’t offer Raid5. (the constant XOR computations slowed down performance – until the faster DMX line came up which now allows for both 3+1 and 7+1 raid5.

Raid-S takes three volumesand computes a parity bit based on them, but lets them maintain their separate identities.

so SYMDEV1, SYMDEV2, and SYMDEV3 each have data, and can be mounted as /u01, /u02, and /u03. If a volumeis lost, that volume’s data is extrapolated from the parity volume. If two volume are lost (either two data volumes or one data volume and one parity volume) the data on the third (or remaining two in the event of a parity volume failure)

This actually gives you an added level of protection in that you don’t lose the entire group on the failure of multiple volumes as you do in Raid5.

Note I said volumes and not disks. Raid-S volumes are hypervolumes (or partitions) of disks and not whole physical disks.