Model instance ipm files are not getting deleted after completion of Workflow

Hi we have an issue in that the ModelInstance files are being left at the end of completed and closed workflow resulting in 100k+ files in the the iwadmin/.../modelinstance folder. We have "delete_jobs_on_completion=true" set in iw.cfg however it doesnt seem to work. Please any help would be really appreciated.

TS Version: 7.2.1 and OS: Windows

Thanks,

Narayan

Find more posts tagged with

Comments

Adam Stoller

You should probably check with Support. I don't think the iw.cfg directive has any control over that directory - but since that directory is within the iwadmin content store - you shouldn't have to worry abou the number of files that appear to be within it as TeamSite actually stores the files in a different manner such that there really aren't that many files within a single diectory - it just looks like there is when viewing the directory through the UI / IWFS.

chnkumar

Thanks Ghoti for your prompt response. In our case, it's generating 1K files everday and is there a way to disable them at workflow configuration level?

Untitled1.png

Untitled.png

Adam Stoller

As I said - "You should probably check with Support."

And, you should report back here what you find out.

chnkumar

Sure Ghoti. I have one more question, please bare with me.

We have around 30 branches in default store and each has a assets folder with size around 15GB and these folders are submitted to Staging. My question here is "doesTeamSite consume space for files in Staging?"

Thanks in advance.

Adam Stoller

TeamSite is, at the core, a version management system that provides virtual views of the content.

Each version of each asset exists once in the backing store. The most recent version of each asset is what you see in the staging area.

A workarea is essentially a bunch of virtual / symbolic links to the versioned files in the backing store (staging) except when the file is edited - at that point it becomes a modified copy of the versioned file in the backing store.

Editions are essentially lists of references to specific versions of files - thus when you have 10 editions all referencing the same version of a specific file you are only paying the storage cost for the data in that specific version of that specific file once; beyond that you are paying for a very small amount of disk space / memory sufficient to support the reference pointer.

It is for this reason that trying to figure out the "size of branches" is very difficult; you cannot just run something like [Unix]: du -s /default/main/some_branch_name - because to utilities like 'du', each reference to the file appears as if it is an actual file rather than just a symbolic link - and you'll end up with numbers in terabytes (if not more) on servers that have less than 900 Gb of disk space.

Does that answer your question?

chnkumar

Yes, Ghoti, you have answered my question.

Thank you so much for your help.

Capture.JPG

Capture-1.JPG

Adam Stoller

You're welcome, but besides spelling my "name" correctly - it would also be nice if you marked my post as a "solution".

chnkumar

Sorry Ghoti, thats a typo. Sure I will do that.

chnkumar

I have just tried copying 1 GB file to one of the Workareas and submitted the file to staging. I have checked the size of Y drive and it's +1 GB. Then what I did is I have deleted the file and submitted to staging and I don't see any change in size on Y drive?

How can we completely delete a file from TeamSite without running any other commands(iwfsshrink)?

Adam Stoller

You cannot delete a version of a file without having deleted every reference to that version of the file. That means:

No reference to the file can exist in any workarea on that branch
No reference to the file can exist in the staging area on that branch
No reference to the file can exist in any edition (named or hidden) on that branch

The last one is the difficult one because anytime you submit a file you are, in fact, also creating a hidden edition that references the files in that submission.

You may be able to identify the name of the hidden edition and then use a CLT like iwrmed on it - afterwhich TeamSite may do "garbage collection" and actually remove the file from the backing store. However, if there were versions of other files that also only existed within that hidden edition - those would also be subject to removal as well (if they still exist in the staging area, which is likely, than it becomes very unlikely that they'll get completely removed, but ...)

How / when TeamSite physically removes the version of the file from the backing store is essentially "proprietary" logic and thus you have no real control over it other than laying all the groundwork (as indicated above) to make it reasonable for the file to be physically removed from the backing store.

chnkumar

It makes sense now. Thank you.