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) > >
