Different disk models to extend an aggregate

[JSITSUPPORT]

Hi All,

Our ageing FAS2220 is on its last legs (EOL end of November), were hoping to get a shiny C190 soon but in the meantime have to keep our old friend running and its running low on space.

We have managed to source a few disks (cheap refurbs) to extend the aggregate as an interim measure but they are slightly different models to the existing ones in the aggregate.

All are 450GB 10k SAS however the existing are X421_FAL12 where the new ones are X421_HCOBD. Are the two compatible and is it safe just to add them to the aggregate?

Thanks in advance for any replies!

[aborzenkov]

Yes, all disks with the same NetApp number are compatible and interchangeable. NetApp number is X421 in this case.

You may need to update disk qualification package though.

[JSITSUPPORT]

Thanks very much for the reply and clarification!

Sorry, one further question as we are far from experts. We have had a look on the compatibility site and our current disk firmware is A02 and the required for the new disks is A05 so we will need the disk qualification package. The question is, could the package cause the A02 firmware disks to update automatically and is there any risk to this operation (e.g. data loss)? We will obviously back up the data first but would like to know the possibility of things going wrong.

Thanks very much again!

[aborzenkov]

Disk qualification package is not the same as disk firmware and same NetApp part number comes from different sources which have different firmware (versions). You can not compare apples and oranges.

Installing DQP does not update any firmware.

[JSITSUPPORT]

Thanks again for the response.

We have managed to add the disks and change the ownership. It did give a label error which is to be expected which we fixed with an unfail command, it updated the firmware on the disks and we zeroed the spares and added them into the aggregate.

Final question if you please?

The best practice now dictates that we should run a reallocate  on all the volumes (not the aggregate) for all volumes on this aggregate but there seem to be many threads advising not to do this on a snapshot enabled, deduplicated volume aggregate. The articles did all seem to point to version 7, where we are on 8.2. Is this still an issue/are we safe to run a reallocation on these volumes?

Thanks very much for any responses, your help is very, very much appreciated!

[GidonMarcus]

Hi

i can remember some 8.1 bugs with dedup space not getting cleaned. but it solved before 8.2... i assume it should be safe to do, as it's a very standard practice to do it after expansion.

you can look on bug solved on version a bit higher than yours to make sure yours dosen't have any "big ones".

Gidi

[JSITSUPPORT]

Thanks for the suggestion. I have logged a call with Netapp to check as it could cause potential issues. I will post back when I get a response.

[JSITSUPPORT]

For completion, here is the eventual response I recieved,

"After we have compared the autosupports from before and after the expansion:

- /aggr0/plex0/rg0 expanded from 11 to 15 disks

- volumes do not have space guarantee,

- used data on volumes has gone down as well.

it turns out that right now there would be no immediate need to use reallocation as there would be (1) enough space on disks themselves and (2) enough disks have been added to the raid group to avoid 'hot disk'.

The only scenario when you would need reallocation is when there are performance issues due to deleting large amount of data (causing large fragmentation). If such a problem ever occurs in the future, please open a performance issue (Cat 1 - Performance) and we will assist you accordingly."

Thanks for the input on this thread!