You've probably already thought about this, but could you just steal a spare from the other filer, or buy another disk to use as a spare? If the spare disk was your last spare in the filer and you can't buy or steal another spare or it forces you to another shelf, then it's worth going through this process. Otherwise you may want to just not mess with it.

If you do have to deal with the problem by copying and recreating the volume, it seems like you ought to be able to get that downtime window to be smaller if you use snapmirror to mirror your problem volume to the new volume in the other filer. This at least cuts down on the time it takes to do the first copy.

...

...

Aaron Sherman ajs@ajs.com 08/21/00 10:46PM >>>

On Mon, Aug 21, 2000 at 10:23:13PM +0100, Mark Simmons wrote:

The real secret to this is re-laying out the filesystem data and altering and relaying out the metadata, which is why AFAIK, only VxFS can do this at the moment - it's perceived to be both hard and uncommon (despite all sysadmin's experiences to the contrary, and the manifest existence of fs-reorganisers) so most fs authors don't bother.

Just in case a) this is what's being thought and b) there's anyone from NetApp listening: THIS WOULD NOT JUST BE A COOL FEATURE... IT WOULD SAVE ME DAYS OF EFFORT.

You see, our database is on that volume, so we have to schedule database downtime, copy the data to a second filer (lucky we have one, or this'd be to tape!) and then back. It's probably going to be 1-3 hour process which will suck up our downtime window for a whole week!