Thanks to the following people who'd responded:

- Tim McCarthy - John McLoughlin - July

Your clarifications were perfect.

As it turns out, we were running OnTap 6.3.x on a 740. We ended up seeing the insidious '1111' messages before enabling the DS14 shelves crashed the filer (upon boot and otherwise). We updated to OnTap 6.5.x and all became happy in the land of DS14s. In addition, we had one of the drives on the FC9 fail this afternoon and it grabbed one of the spare 36g drives -- NOT the 144g drives as I'd hoped.

Per your clarification(s), it looks like the remedy is to provide enough spares for the FC9 so failures of 36g drives won't tap into our pool of 144g spares.

-- Nathan Patwardhan, UNIX System[s] Administrator, Sr. Akamai Technologies, 839B/8CC x 83035 npatward@akamai.com AIM: notoriousnvp71

-----Original Message----- From: Patwardhan, Nate [mailto:nvp@akamai.com] Sent: Wednesday, April 05, 2006 8:52 PM To: toasters@mathworks.com Subject: OnTap 6.x, mixed shelves, and spares.

All,

I am migrating a 740 so that the shelf/volume configuration looks like the following:

vol0 -> 1 x DS9 @ 36g (raid4) data -> 1 x DS14 @ 144g (raid4)

Basically, I wanted to not waste a 144g drive on vol0 while maximizing my space on the DS14. Note that we're also going to be consolidating many of our NetApps in the future, so it made sense (to me, at least) to keep 'data' on a separate shelf.

However, I have concerns with the above configuration. I'm not concerned with disk failures on 'vol0' (or any other volume that might live on 36g drives) since I'm pretty sure that OnTap will do the right thing and take a 36g drive from the spares pool. I am pretty concerned that 'data' might pull a 36g drive from the spares pool instead of a 144g drive.

Is my concern justified? Will OnTap 6.3.x do the right thing for the 'data' volume and pull a 144g drive from the spares pool or is there the chance that it would pull a 36g drive? Or is OnTap smart enough to know that a 144g disk with more than 36g utilization should be replaced with a disk of at least 36g?

-- Nathan Patwardhan, UNIX System[s] Administrator, Sr. Akamai Technologies, 839B/8CC x 83035 npatward@akamai.com AIM: notoriousnvp71