May have misread, then. Having a volume of made up of shelves of different types is bad. As I understand it, it's impossible to have 9s and 18s in the same _shelf_, and there's no problem in having different _volumes_ of shelves of different drives. In other words, b) is the problem -- a) and c) are fine. The problem occurred in write performance (which went absolutely to pieces under load, causing nvram to double-fill and nfs to stall), because of the issues in balancing writes across different sizes of drives. The fact that the 18s are faster drives makes things quirky as well.

The parity and spare drive issues are also present, but not the actual cause of what we saw. You just have to maintain separate spare pools, and parity needs to be the largest drive type.

--DRS

David Schairer njal@concentric.net writes:

...

It will kill your performance, not now, but once you get things filled up. This has not historically been part of NetApps docs but I believe it's becoming so (Hi, Sam!).

Make a separate volume of 18s, migrate data, do what you have to, but don't mix your shelves. It's like crossing the streams.

Howdy- Could I ask for a little more clarififcation about this (either from you or the folks at NetApp)? The way I read this message was he was going to add 9G disks to a volume composed of 9GB disks and and 18GB disks to a volume composed of 18GB disks. Are you saying that:

a) having both 9GB and 18GB disks on the same *filer* is bad? b) mixing 9GB and 18GB drives in the same *volume* is bad (I would guess this would be true if one didn't watch out for the parity & spare drive gotchas)? c) having a volume served from two different *shelves* is bad (can't believe this is the case)?

Thanks!

Respectfully, David N. Blank-Edelman Director of Technology College of Computer Science Northeastern University