Mailing List Archive

Since this is snapmirror, you can’t really have a different number of snapshots between the two volumes… you would have to use snapvault for that…
Of cause there can be more snapshots on the source, until the destination catches up…

Again, because this all snapmirrored volumes, pretty much all the settings from the source are mirrored.. also space guarantee and fractional reserve etc… but of cause I checked…

/Heino

Fra: Timothy Naple <tnaple@vectordata.com>
Dato: fredag, 5. august 2022 kl. 17.00
Til: Heino Walther <hw@beardmann.dk>, toasters@teaparty.net <toasters@teaparty.net>
Emne: Re: Space issues on older NetApp...
My first guess would be that you might somehow be retaining more snapshots on the destination, perhaps at the volume level? snap list for all the volumes is identical on source and destination? Does df -h on both sides show which volumes, if any, have a size discrepancy?

Maybe a 2nd guess would be that the space guarantee settings are different on the destination volumes.
________________________________
From: Toasters <toasters-bounces@teaparty.net> on behalf of Heino Walther <hw@beardmann.dk>
Sent: Friday, August 5, 2022 7:31 AM
To: toasters@teaparty.net <toasters@teaparty.net>
Subject: Space issues on older NetApp...


Hi there



We have two systems that mirror eachothers volumes via snapmirror.

We are talking 7mode ONTAP 8.1.4

The two systems have the same controller: FAS3240

They have the same disks and aggregate configuration (70TB aggregates)



On the source side we use volumes that are thin-provisioned with LUNs that have space reservation enabled, the LUNs are mostly close to 16TB (which is max)



All volumes are snapmirrored to volumes on the destination system with the same size and placed on the same aggregates that mirror the source aggregates in size…



The aggregates on the source are all below 95% used.



Yet.. we are now at the situation where a few destination aggregates are 100% full, while the source aggregates are still under 95% used…

I have checked almost everything, like aggregate snapshot reserves etc.. but they should be the same…



Can anyone explain why this can happen?



We are of cause at a “deadlock” now.. I don’t think we can add anymore disks to the aggregates as they are max size…

The only think I can think of is either delete a volume from the affected aggregates, and re-sync the volume and hope it doesn’t fill up again…



Another way would be to add disks and build a new aggregate, and move some of the volumes…



Is there something I have missed? ????



/Heino

I do remember faintly the Dedupe Metadata bug, that was persistent
through quite a few 8.1 releases.
It would cause "inexplicable" space loss, because the metadata would
just grow and grow...

Are all controllers (source & destination) on the same patch release
(8.1.4P10?)?
Is there a reason not to update them to 8.2.5P5?

IIRC 8.2.5 at the latest had the problem solved...


/Sebastian


On 05.08.2022 16:31, Heino Walther wrote:
>
> Hi there
>
> We have two systems that mirror eachothers volumes via snapmirror.
>
> We are talking 7mode ONTAP 8.1.4
>
> The two systems have the same controller: FAS3240
>
> They have the same disks and aggregate configuration (70TB aggregates)
>
> On the source side we use volumes that are thin-provisioned with LUNs
> that have space reservation enabled, the LUNs are mostly close to 16TB
> (which is max)
>
> All volumes are snapmirrored to volumes on the destination system with
> the same size and placed on the same aggregates that mirror the source
> aggregates in size…
>
> The aggregates on the source are all below 95% used.
>
> Yet.. we are now at the situation where a few destination aggregates
> are 100% full, while the source aggregates are still under 95% used…
>
> I have checked almost everything, like aggregate snapshot reserves
> etc..  but they should be the same…
>
> Can anyone explain why this can happen?
>
> We are of cause at a “deadlock” now.. I don’t think we can add anymore
> disks to the aggregates as they are max size…
>
> The only think I can think of is either delete a volume from the
> affected aggregates, and re-sync the volume and hope it doesn’t fill
> up again…
>
> Another way would be to add disks and build a new aggregate, and move
> some of the volumes…
>
> Is there something I have missed? ????
>
> /Heino
>
>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> https://www.teaparty.net/mailman/listinfo/toasters