Hi Michael and Uwe Thanks *a lot* for your replies. This is excatly what I was looking for.
Did you adjust those options ? How ? I've was unable to find those server options in the Admin Reference Guide and not visible with a standard Q OPT or with a generic Q OPT *DEFR*. I was required to use Q OPT DEFRAGCNTRTRIGGER and Q OPT DEFRAGFSTRIGGER. Both options are set to 50% (default). I've found some words in a 8.1.5 presentation : 8.1.5+ Defrag uses a new path in MOVE CONTAINER process to read in the chunks of a given container and rewrite them via the standard ingest path, redistributing them in available container space Move Container with defrag allows the user to achieve the goals of previous workarounds much more easily Container defrag can be invoked manually, with “MOVE CONTAINER <container name> DEFRAG=YES” Auto-defrag engine periodically checks for container fragmentation If containers surpass DEFRAGCNTRTRIGGER & DEFRAGFSTRIGGER thresholds : Automatically runs defrags If % of available filesystem space or the % of container space which is usable/available falls below these thresholds : Auto-defrag will periodically start defrag processes for fragmented containers @Uwe For one of the servers (the smallest one, Est. Cap of 12,5TB, Pct. Util of 45%), upgrade has been made at the end of august. The conversion had been made monthes ago, when the server was still in 7.1. For another one (the biggest, Est. Cap of 235TB, Pct. Util of 65%), upgrade has been made at the end of august too, then I started conversion and it has just finished. -- Best regards / Cordialement / مع تحياتي Erwann SIMON ----- Mail original ----- De: "Michael Prix" <mich...@prix.one> À: ADSM-L@VM.MARIST.EDU Envoyé: Mercredi 14 Novembre 2018 19:25:10 Objet: Re: [ADSM-L] AW: [ADSM-L] Move Container (Automatic) filling up the directories Hello, and, to tell the rest, as both server options are not documented until now, I quote my documentation from a PMR: DEFRAGFSTRIGGER 0-99 dynamic server option DEFRAGCNTRTRIGGER 0-99 dynamic server option If the percentage of free filesystem space is lower than (100-DEFRAGFSTRIGGER) and the percentage of container free space is lower than (100-DEFRAGCNTRTRIGGER), where those percentages are calculated by fsfreespace / (fsfreespace + dedup/nondedup cntralloc space) and (cntrFree - pool unaccessible ) / ( cntrFree + dedup/nondedup cntrUsed ) If either threshold is met, then we'll look for containers with a fraglevel higher than 80 to auto-defrag. -- Michael Prix On Wed, 2018-11-14 at 15:48 +0100, Uwe Schreiber wrote: > Hi Erwann, > > did you recently update to version 8.1.5.100, or was the convertion from > sequ. Filepool to Directory Container Pool done using version 8.1.5.100? > > Spectrum Protect server version 8.1.5 introduced automatic container > defragmentation for directory-containers. > The server checks for container fragmentation and automatically runs > defragmentation for containers surpassing thresholds controlled by the > DEFRAGCNTRTRIGGER and DEFRAGFSTRIGGER. > > Regards Uwe > > -----Ursprüngliche Nachricht----- > Von: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> Im Auftrag von Erwann > SIMON > Gesendet: Mittwoch, 14. November 2018 15:26 > An: ADSM-L@VM.MARIST.EDU > Betreff: [ADSM-L] Move Container (Automatic) filling up the directories > > Hi all, > > I'm using Directory Container Pools on a couple of servers. Servers are at > 8.1.5.100 level. > > Those servers were using legacy File Pools with deduplication enabled that > have been converted into Directory Container Pools. > > I'm seeing a lot (a lot !) of Move Container (Automatic) that fills up my > directories (free space is occupied by Containers in Pending State). Those > Containers in Pending State can be as many as the ones in ReadWrite State > (reusedelay is set to 4 days). Is there a mean to have more control on this > ? > > Another strange observation regarding fragmentation evaluation. > > 13.11.2018 13:09:55 ANR4392I CONTAINER DEFRAGMENTATION started > processing stgpool PRIM_CONTAINER. Containers are only using 98.12% of > 150053.46 GB due to fragmentation. (PROCESS: 14462) > > and one hour later, fragmentation is higher (with no other process, such as > Expire Inventory, that have run) : > > 13.11.2018 14:08:34 ANR4392I CONTAINER DEFRAGMENTATION started > processing stgpool PRIM_CONTAINER. Containers are only using 97.00% of > 149378.75 GB due to fragmentation. (PROCESS: 14516) > >
