Disk replace 2TB by 1TB

vmsjaak13 · ‎2011-05-26

Hello,

I need to replace a 2TB disk in a raidgroup by a 1TB disk.

Situation: aggregate expanded by adding a new RG. All disks are 1TB, except the parity disk in the RG.

I made a mistake, and used a 2TB disk..... Which I want back very much

I have 2 spares of each size left.

Disk replace moans that it can't replace the 2TB parity disk by a 1TB disk, because the disk is smaller.

How can I get that 2TB disk out of the aggregate, and replace it with a 1TB disk?

Regards,

Niek

shaunjurr · ‎2011-05-26

Hi,

Unfortunately, unless you can move the data and delete the aggregate, you can't. I've always found this a bit puzzling myself, but I've had occasion to have gotten "odd" size disks (a 250GB disk in an otherwise 500GB aggregate via 'vol/aggr add' and basically, the size of that disk in that aggregate will simply always remain the same.

If the situation, for example, were reversed, and you had a single 1TB disk in a 2TB volume, when that 1TB disk failed, a 2TB replacement would only ever use 1TB of that disk. (The same is true for my case above with the 250GB disk, btw).

Unless something has recently changed in ONTap, you basically just donated a 2TB disk for a 1TB job. Experience is sometimes a painful thing, unfortunately.

Good luck.

vmsjaak13 · ‎2011-05-26

Even if I fail the 2TB disk, it wants a 2TB spare ?: disk fail -i -f disk.number

shaunjurr · ‎2011-05-26

Well, 2TB or larger (when they get here)...

I almost hope that I am wrong, but based on my previous experiences, the size of that disk in that raid group can't be changed after it is added. You can always give it a try, but the reconstruction time could be pretty extensive (especially with -i). Basically, it would want to do a preventive copy of all of the blocks over to a new disk (without -i), so it has to be of the same size. Even the parity rebuild will want to produce the same number of blocks on the replacement. I believe you are in the same boat if you use disk replace as well.

There's probably a KB article that makes this information more official on the NOW site.

Sorry to be the bearer of bad news.

mcope · ‎2011-05-26

You could trying opening a technical support case, but I do not believe there is a way to remove the disk or force a swap with a smaller disk. Adding disks is like carpentry - measure twice and cut once.

If you have a good relationship with your NetApp reseller, you might convince them to let your borrow a "swing" or loaner shelf to migrate your data to another aggregate, destroy your aggregate, and then migrate the data back. When I was in NetApp Professional Services, I did this at least twice a year for customers when they added the wrong size drives or accidentally added all their spare drives.

dejanliuit · ‎2011-05-26

This is one major annoyance I have with Ontap.

Can anyone explain why it isn't implementet in ontap just to "mark for removal" and "reallocate away"?

It would be completly transparent to the client systems and withing the mantra for "write anywhere file system".

This would also let customers upgrade disksizes inplace, maybe one disk at time, without downtime and need to purchase/install new shelfs, not just for situations of human mistake.

shaunjurr · ‎2011-05-26

Some of the migration aspects are coming, but somethings even NetApp can't change. I'd like to see "data move" in ONTap 8.x be able to move CIFS/NFS shares as transparently as it is supposed to be able to move LUN's, at least within the same controller. I guess that would essentially make such moves possible with entire aggregates as well, but the complexity and duration of such an operation would have prohibitive risks in today's world, I would think...

Upgrading disk sizes is a phenomena that has only recently gained speed. Since the availibility of consumer grade ATA/SATA disks that were forced to compete on a purely per GB price market, sizes have expanded rapidly. It hasn't really been a necessity. You could by 144GB disks for many years, for example. The pace was slower. Perhaps this wasn't one of the highest priorities when WAFL was made.

The file system would have to be modified to understand the modifications in physical storage that were occurring somehow. I think calling WAFL a mantra is pushing things a bit far. Given enough time, money, and human resources, it probably can be done, but NetApp is a company that needs to make a profit and not an academic institution developing solutions for historic corner cases. It may become necessary, but it hasn't been so far, I would think. I don't believe there are any competitors that offer this functionality either.