3ware 8506-4LP degraded RAID array rebuild (R10)

Another recent technology victory.

I didn't want to try a hot-swap.  Too important.

# tw_cli

> info c0

Shows that disk in port 2 (/c0/p2) is DEGRADED.  I wrote down the serial number of the degraded disk, in case the hardware port to driver port mapping was criss-crossed.

Nope.  Port 2 (3rd one down: 0, 1, then 2) actually housed the "bad" disk.  Put in the new disk.  Used the power-screwdriver at the colo (Bravo, HE) to mount the new one in the housing, and put it back in the array.

:)

Rebooted.  Alt-3, and selected the new disk (not a part of any array), and the degraded array.  This put an asterisk next to both, then tabbed down to [Rebuild Array].  It marked the array for a rebuild--this part was confusing--and said it would start on [F8].  I assumed (luckily correctly) that it was wanting me to put F8 to start the rebuild.  When I did, it continued the boot.

This is the part that seems like it should require more explicit direction or description.  I mean, clearly, if you reboot here, that would seem bad, unless the controller wrote something to the firmware.  I guess that makes sense.  Still, it would be nice if it told you that no matter what you did, it would be safe.  Still...

:/

Ok...Linux boots.  fsck has its fun.  And, when I get the shell back, I run tw_cli again.  It says the array has status "REBUILDING".

:)

I remembered something about being able to reset priorities during a rebuild...

# tw_cli

> set rebuild c0 1

The range of the last argument is from 1 to 5, inclusive.  5 is the lowest, prioritizing I/O over the rebuild.  1 is the highest, prioritizing the rebuild over I/O.  3ware FTW.

:))

X-Rite MonacoPROFILER

The product, for the most part, is reasonable.  It makes input, output, and monitor profiles, generally easily.

But, to make a scanner profile with a Q60 target it doesn't recognize?  Woe is you.

:(

For whatever reason, the set of "allowed" Q60 targets that can be chosen is fixed.  To get your own data in there (e.g., if you bought your own target, and it's not one of the ones listed), then you have go through the following hack:

1. Duplicate the folder called "IT8 Targets" in the X-Rite system directory  (/Library/Application Support/X-Rite/IT8 Targets), and make sure you've copied all the files inside to the newly-duplicated folder.
2. Then, open PROFILER.
3. Select Input
4. Select IT8.7/2 (Reflective)
5. Select "Other...", and write down one of the filenames which is *NOT* grayed-out.
6. Now, go back to the Finder.
7. Open that file with the name you wrote down, using Textedit.
8. Replace that file's contents with the custom Q60 data you have (i.e., cut-and-paste from new Q60 file into the existing Q60 file).
9. Now, go back to PROFILER.
10. Select the file you just chose.
11. Continue in PROFILER.
12. (make profile)
13. Put the files you messed with back, using the copy you made in Step 1.

I suspected something with the file format, permissions, or other metadata.  Not really...I used 'od -c' to check it.  No CR/LF issues.  I also checked the metadata, and it looks like they have different creators, and different file-types (at least in terms of the app used to open them).  But, it's hard to imagine that PROFILER reads the extended MacOS metadata.

:((

My best guess at this point is that those targets are built-in to PROFILER.  Which makes me wonder if the profile it made is really using the new data I copied-and-pasted, or if it's just using the data built-in.

:(((

Parallels and Qimage

New times:

• Phase 1a: ~3 min
• Phase 1b: ~4 min
• Phase 2: (who cares)

It's a little disappointing, actually, that turning on 4 CPUs in Parallels and giving the VM 2 GB of RAM does nothing for print speeds, esp. since Qimage ought to be able to parallelize the rasterization.  For a second, though, it seemed that the multithreaded thumb generation was going to work faster (using 4-cores), but alas, it slowed the VM to a crawl.  Is it because of the printer running out of paper?  Is that somehow jamming up the XP kernel?  Or, is it just that giving the VM all 4 cores is jamming up the physical machine?

:(

Would love to print from Leopard using the 16-bit drivers from Epson.  Looks like ColorSync can be disabled in the printer preferences by enabling Epson color mangaement and not ColySync (really?) and Epson's drivers look like they can be told to turn off color management.

Will try LR2 later to see if printing directly can yield a good result.  Something tells me that the interpolation techniques used by Qimage will be better, but won't make too much practical difference unless I have higher resolution images with high-frequency areas.  But, if 16-bit printing is possible, that might make up for the difference.

But, a second perusal on the interwebosphere still show signs that Mac OS Printing is stupid...

:/

Printer Driver & Qimage Upgrades - Epson Settings

Qimage and the Epson drivers needed upgrading.

So I decided to finish all the WinXP patches while I'm installing the auto-Qimage update.  Bad idea, since WinXP wanted to install SP3 while Qimage was installing.  So, naturally, I had to cancel the Qimage install (how was I going to do the update, now that I cancelled the auto-update?), and let XP reboot the VM several times.  Joy.  :|

But, as usual, that finished without much of a problem (since I'm so careful about updates).  After the final reboot, I restart the Qimage auto-update.  No problem.  It works beautifully, just overwriting the existing update file--but I *DID* have to find my old "new" password...

Good thing I bought the Studio Edition of Qimage.  Lifetime free upgrades.  But, earlier this year, they changed the way they handled our accounts.  So, they sent us a new password for grabbing the updates.  So, I had to track down the emails (from DDI Tech Support--ddisoftware.com) with my new password.  That confused for a few minutes.  :(

But, it upgrades without a fuss.  Then, I install the new Epson drivers (before starting up Qimage).  No issues, and I can see it installing the tools.  Bravo, Epson, for bundling the tools with the driver--DUH!  :)

Then, start up Qimage.  It notices that the driver is different (!) and wants to reset printer settings.  Ok.  Starts up in crappy skin.  :|  But, on to the settings first.  And, what starts as the relearning of all the Epson driver idiosyncrasies.

The most important is that getting the driver to allow true 720-dpi printing is a fairly obscure setting.  It's the "Finest Details" setting in the "Quality Options" dialog--which is now super-weird.  :(  You have to RE-select the "Quality Options" in the "Print Quality" to get the dialog to appear (the weird part).  In that dialog, the key is checking the "Finest Detail" box.  This 1 setting allows the printer to print at 720-dpi.  :((

Having done that, it's back to the other options.  Some other things to keep in mind:

• No Color Adjustment
• Borderless Printing
• And, in the "Expansion..." dialog, choose "Retain Size"

The curse of consumer electronics, which is odd, since the Epson Stylus Pro 4800 is not a consumer device, really, IMO.  But, since I'm sure the driver guys are just a couple of outsourced Asian subcontractors, they are trying to design an interface for a faceless user.  Typical.

The "No Color Adjustment" is duh, Since Qimage is doing that.  The "Borderless" printing is more of a mystery, but has to be done, so that Qimage can use its own database of printer hardware margins to accurately position images on the paper.  Finally, "Retain Size" is a must versus "Auto Expand", which will undo all the work that Qimage is doing.  :((

Obscurity FTL^2!

I try toprint the test set.  Which is it's own trauma.  For starters, why won't the test image print beyond 300-ppi?  :(((

I chose "Original Size" in Qimage "Print Properties".  This should allow the image to choose its own resolution (if tagged in the TIFF data).  Right??  Wrong.  Turns out that "Original Size" means something totally different...So, I decide to adjust the setting to customize the "behavior" of "Original Size", because that's my primary suspect in this printing madness.

This customization uses yet another strange UI paradigm.  If you select "Custom" in the "Print Properties" combo box, a dialog appears.  Strage.  But, instead of creating a new size (which "Custom" might imply), it simply gives a list of options on "Sizing Method".  Turns out that this list corresponds to the DEFAULT list of sizing methods, which is the same as the DEFAULT list of "Print Properties" values in the combo box.  Yeah.  CRAZY.  :((((

Ok.  I chose "Use ORIGINAL/embedded size", thinking that's the obvious choice.  Turns out it is, except that in the "Original Size" subsetting area, there is a box checked called "Override embedded size", with a value of "300" in "If no embedded size, use ___ PPI".  ZOMG--So, "Original Size" actually meant:

Assume that the image is 300-ppi.  Nevermind the TIFF data.  Then, print it, unscaled, at 300-ppi.

And, "Original Size" should have just read: "Preserve size using fixed 300-ppi".  Like rational people, who aren't insane and get angry at computers, I move on and uncheck the box.  Change the override value to "720 ppi" in that value (target resolution in printer driver).  Turn auto-cropping off.  And lock print orientation.  Finally, choose "Permanently" as the application method.  [OK].  :(((((

FINALLY!

The image wants to print, in the center (gotta do that manually, in Qimage, too, but it stays that way until you "Clear Margins"), at 720 ppi, which is the dpi setting in the TIFF data.  Finally.

Make some test prints.  Turns out, 2880-fast causes horizontal misalignment.  2880-slow doesn't.  So, the real question is...Is the the "Microweave" improvement in 2880, or is it just the "High Speed" option?  So, print 1440-slow, 2880-fast, and 1440-fast.

Results: 

1. 2880-slow = FTW.  No banding (well, maybe some super-faint horizontal banding, but might just be me).
2. 1440-slow.  No vertical banding.  Light horizontal banding.
3. 2880-slow.  Vertical banding.  Light horizontal banding.
4. 1440-fast = FTL.  Heavy vertical banding.  Horizontal banding.

Nothing surprising.  Basically, for small test-prints, use 1440-fast.  For a big, super-high-res finished print, 2880-slow.

But, practically, why do the images look fine at 1440-fast?  Well, because I'm shooting 12MP images.  Without any cropping, at 21x14, that's about 4200x2900 pixels.  Which is about 200-dpi in the final print.  So, there are *NO* features, esp with up-sizing (even with fancy Qimage algorithms) that is adding features greater than 200-dpi.  It just smooths out features that already exist.  So, until I get a camera with at least 3x or 4x more pixels, this problem won't really show up, since the banding is only apparent in super-high-frequency and high-contrast regions (e.g., black lines on white paper).

BTW, Qimage settings:

• 720: ppi
  
• Hybrid SE: interpolation
  
• 5: sharp
  
• IGSPP9: Ilford profile for GSP
  

And, finally, print time for a full 14x21 image at 2880-slow:

• Phase 1: 7:16 (~7 minutes)
  
• Phase 2: 22:20 (~22 minutes)
  
• Total: ~30 minutes

Phase 1 consists of getting the data from Qimage to the printer and hearing the familiar ker-chunk, ker-chunk.  Phase 2 is just the miracle of the swish-zoom, swish-zoom, until the page is fully ejected and the printer stops ker-chunking.

Everything is straightened out now.  For now.  ;)

Restart

A print was needed.

But the last time I printed anything real on the Epson Stylus Pro 4800, I had Mac OS X 10.4.x with Parallels 3.0, running Windows XP and using Qimage as a RIP-lite.

Uh-oh, because now I have Leopard and no Parallels.  Could I get everything working in 2 days?  It was the 23rd, and I needed it for a Christmas gift...

* * *

So, I installed the Epson driver: 12787 (Leopard-6.11), and 12690 (RemotePaneUtil-3.13).  Turns out I really *did* only need the driver, and not the utility.  That's quite nice of Epson to create a unified driver/utils bundle.

Then, I reinstalled Parallels-3.0, since I figured that would get the old VMs up and running as quickly as possible.  Had to remember to search on laptop for P-3.0 license key, stored under Element5, the online retailers that handles Parallels purchases before this year.

Then, tried to start the VM.  Kernel panic on the Mac.  Prob because I upgraded the Mac's video card (ATI 1900 -> NV8800, because the fan on the ATI blew up, and started a jet-engine-loudness in my right ear; that install went nicely, BTW)  :(  Which happened to blow up the auto-download of Para-4.0, which I just bought the upgrade to, while waiting for Para-3.0 to install.  :((

Fixed the download by just installed the demo from the main Para site.  Then, installed it, and used the new license keys.  Had to go through a stupid VM install (won't start Para without going through the creation of a dummy guest OS).  Still unhappy at this point.  :(((

But, once I did that, I opened an old Para-3.0 VM.  It told me I had to convert it to the Para-4.0 format.  Fine.  When it's done, it tells me I have to start the VM to finish the conversion.  :((((

At this point, I'm still printing nozzle tests for the printer--which hasn't printed since Dec '07--and don't want to blow that up in case it KPs (kernel-panics) again.  So I wait until the check finishes.  Done.  Start the new VM.  It works!  Holy crap!  :)

Then, I start up Qimage.  Works, and all the settings are saved!  :))

*Whew*

A few prints later, and all the nozzles are clear.  I'm pretty impressed, after all.  Thank goodness I covered the printer with the plastic sheet, since the sheet is covered in fine detritus.  While I'm doing that, I'm starting up Lightroom, and fixing up the export options.  OBTW, the old VM knew where the "shares" were, and accessed them just fine.  So the export from LR to Qimage didn't really change.

:)))

Everything is as I remember, and I'm ready for a print.

Mac OS X, Parallels, and Qimage FTW.