Scrubbing view-private storage

When a DO is first built by clearmake, omake, or clearaudit, its data container is placed in the private storage area of the user’s view. The first time a DO is winked in during a clearmake or omake build, the data container is copied to a VOB’s derived object storage pool. (The container is copied, not moved, because moving it might disrupt user processes that are currently accessing the DO.) This leaves a redundant copy of the data container in view-private storage. (When you wink in a derived object with the winkin or view_scrubber –p command, the data container in the view is removed after it is promoted to the VOB storage pool.)

Typically, you need not do anything about these redundant copies:

In a view that is frequently used for builds, build scripts replace old (and potentially redundant) DO data containers with newer ones.
There can be at most one redundant copy of each DO in a view. (Contrast this with the situation for VOBs: if the scrubber utility never runs, the VOB accumulates many DOs that are no longer used.)

Unless disk storage is extremely scarce, you might conclude that it is not worth the effort to clean up redundant data containers in view-private storage. If you decide that redundant DO data containers must be removed from a view’s private storage area, use the view_scrubber utility. You can also use this utility to migrate the data containers of unshared or nonshareable DOs to VOB storage.

See the view_scrubber reference page for more information.