nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

disk space

msrich

W2K TS 5.5.2 + SP2B

Is there any way to tell how much disk space a branch is using?

Find more posts tagged with

Comments

Adam Stoller

To the best of my knowledge the only reliable way to do this is (a) you have only 1 branch, or (b) you purchase MultiStore and migrate a branch to its own store and then look at the amount of disk space used by that store. And actually, in the first case, it's still not entirely reliable as you'll probably pickup data regarding the workflow backingstore as well as the content backing store.

Approximations can be come by through looking at the size of a particular branch's staging area, and your own knowledge of what size files change how frequently, and how long they've been doing so within TeamSite. Clearly this is not a real formula, just an approach. And of course there's a degree of overhead that needs to be added into the calculations (e.g., storage of metadata)

Do you really care how big a specific branch is within the backing store - or how big the backing store is as a whole and how fast it's growing?

--fish
(Interwoven Senior Technical Consultant)

msrich

I really want to know how much room each client is taking on the server.

I understand the 2nd-backing-store option you describe. This makes sense, but it's not too practicable.

Does it do me any good to know the footprint of a branch on the Y: drive (IFS share)? Is there any calculation I can do --with #editions, #files in Staging, etc., in combination with the total-byte value on the Y: drive for the branch -- to learn how much room the branch takes up when you factor out copies of files that are simply held as pointers?

Adam Stoller

Start with the first edition - get the footprint
Go to the next edition, and for each file which changed since the last edition, get it's size and add it to the footprint (unless the change was a deletion, in which case don't add it - but don't remove it from the total either)
Repeat for each subsequent edition.
Add a fudge-factor for overhead

Alternatively, and perhaps more accurately, run iwrlog on each file in the branch, and use iwvpath -o for the objectid for each version of the file, and then add up all the sizes of all the versions of all the files - and add a fudge-factor for overhead.

One could probably conjure up a perl script to help facilitate this - but I haven't had the need (and don't have the time now) to do so - and the result is still not 100% accurate.

--fish
(Interwoven Senior Technical Consultant)

james1

ghoti

Your edition-to-edition methodology doesn't capture any file revisions that may have occurred in between edition publishes. Depending on the usage model (the frequency of submits vs. the frequency of publishes), this may or may not be significant.

Also your iwrlog methodology needs to make sure it doesn't vector to another branch, as a file's history can span branches. This can result in either counting revisions on a branch that we don't care about, or counting revisions more than once, or both. There is also the possibility of a file being renamed and then living on under both the old and the new names; in that case, iwrlog for each file will include the entire history of the original. Obviously, these are corner cases, but they could lead to an inflation.

In short, there is no really good (and easy) way to calculate this. The best way is probably ghoti's original suggestion -- migrate the branch to a separate store.

-- James

--
James H Koh
Interwoven Engineering

PSUwin

This is something I've repeatedly mentioned to Interwoven personnel we've dealt with. Since we are working in a "leveraged" environment, multiple customers (at least from a billing standpoint), it would be VERY useful to have at least a somewhat accurate EASY to use method for getting the space each branch uses.

on_runtime_level.jpg

Migrateduser

I checked wiith IWOV product management. This feature is on the list of items we are investigating for a future release.
Regards,

lissa

Adam Stoller

If you're working in a leveraged environment, as you put it, then it makes sense for you to purchase licences for MultiStore - it allows you to have different backup times, different administrative times [e.g. iwfsck] and the ability to have different 'root' branches in different stores which will then let you get more accurate disk space utilizations.

The only "gotchas" as far as I know are:
1) We only officially support 8 active stores simultaneously. So if you are hosting more than 8 sites you should consider having a new server for each group of 8.
2) The workflow backing store is maintained as one store within the "default" backing store, so you may need to add this as an overhead "fudge factor" in your calclations (I don't know if there's an accurate per-job, or more likely per-task, disk usage formula - but you can probably make use of iwquerytasks to get a count of tasks existing for a particular vpath and ascribe some nominal value to it)

--fish
(Interwoven Senior Technical Consultant)

markg

This is also something I have asked for repeatedly. The 1 branch per backingstore is not a scaleable solution. I have roughly 300 branches!!

This is why I would like to know which branches are using up space and how fast they are growing.

OpenText StreamServe 5.6 Document Broker Plus User Guide.pdf

OpenText StreamServe 5.6 Document Broker for FastObjects User Guide.pdf

Adam Stoller

The problem is that within a backing store - the data for the branches are spread across a multitude of directories with (from a users perspective) there is no definitive way (to my knowledge) to determine which entries refer to files within which branch.

When you say you have 300 branches - are those all top-level (/default/main/****) branches? Or are you counting sub-branches (/default/main/****/yyy)? I'd assume that you'd have different top-level branches for each customer you host ... well, I guess that might be 300 - but if so, you're probably going to want multiple servers anyway and multiStore still gives you the benefits previously sited ... however - I don't think there is any [existing] method for [easily] deriving the data you are seeking.

There is an open feature request (38852) - if you are not one of the customers who have already requested this, please contact Interwoven Support to get on the list.

--fish
(Interwoven Senior Technical Consultant)

JeremyH

Has this feature made any progress? (Is it expected to make it in to a release, or is it still being investigated?)

JeremyH

On epotential solution if you can accept some downtime:
1) Backup the backing store.
2) Freeze backing store and get disk usage.
3) Delete branch
4) Get disk usage
....
X) Get space remaining after all branches are deleted, and allocate evenly among all branches.
Y) Restore backing store.

Migrateduser

This feature request is still being considered for a future release.

There is a very rough approximation supplied in the feature request which might be helpful:

An estimate of the physical size of the branch may be made by applying proportionality to the size of each staging area against the size of the total backing store. This method is a very rough estimate which is vulnerable to many errors and inodes or blocks cannot be calculated using this manner. For example, you can take the following steps (in Unix):

1. Execute "find branch/STAGING -ls -exec iwattrib {} revisionnumber \;"
2. Multiply the revision numbers against the file size
3. Sum to determine the total size of the revision numbers *file size
4. Divide by the total size of the backing store to create a percentage of the total size of the backing store
Hope this helps you in estimating size of your branch.

I will forward a link to this thread to interested parties, to let them know that this FR is getting visibility.

Regards,

lissa

rwinterpacht

It sure has been a while for this, any updates to this feature request? We, too, are looking for ways to determine how much space is taken up by a particular branch (thus site and business group.)

Raf Winterpacht
HSBC Technology Services
TS 6.5

Adam Stoller

You might want to check out this thread to see if that will help in the absence of an official solution...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Sharon

Ghoti,
"this thread" does not link properly. Would you please give the title or something else that I can search on to find this link?

Adam Stoller

Ghoti,
"this thread" does not link properly. Would you please give the title or something else that I can search on to find this link?

I've sent a message to the DevNet maintainers asking if they could figure out how to fix the reference in that post (which was made about a year ago - in the "old" forum software). I have no recollection of what information might have been referenced there anymore - sorry.

IwovHeather

Hi Adam,

Sorry for the delay, I have been out of the office for the last couple weeks.

Is this the link you want?

http://devnet.interwoven.com/forums_vb/showthread.php?t=8495

Thanks,

Heather

Adam Stoller

Hi Adam,

Sorry for the delay, I have been out of the office for the last couple weeks.

Is this the link you want?

http://devnet.interwoven.com/forums_vb/showthread.php?t=8495

Thanks,

Heather

Yeah - I think that was it - thanks.
If I ever find myself with time and a server to play with, I may try the script out again and see if I can find/fix any of the problems that Nipper noted. However at this point it's still "free code" - so use at your own risk, modify at your own desire.