Questions in this catagory:

  1. Why does my Vesta disk keep getting more and more full?

  2. How do I purge old builds and reclaim space?

  3. Help, my disk has completely filled up! How do I recover?

  4. When does the weeder pause / stop serving client requests?


Why does my Vesta disk keep getting more and more full?

Every time you perform a build using Vesta, the results of the build get stored in Vesta's persistent cache. Until you tell the system to delete some builds by running VestaWeed(1) (aka "the weeder"), it keeps the results of all builds.

How do I purge old builds and reclaim space?

Run VestaWeed(1). The easiest way to use it is to simply tell it to keep all builds performed more recently than some time in the past. For example, to keep only those builds performed in the last three days, you could do:

VestaWeed -keep 3d /dev/null

(Note that both the cache and repository servers must be running to use the weeder, and you must run the weeder as the special vadmin user.)

Help, my disk has completely filled up! How do I recover?

  • 1. Shut down the cache server if it's running.

    2. As vadmin, run EraseCache(1). This will completely erase your entire cache of previously done builds. It should get you enough space to proceed with the next steps.

    [reason / explanation ]

    [reason / explanation ]

    3. Start the cache server back up. Also make sure that the repository server is running. (Both servers must be up to do step 4.)

    3. As vadmin, run QuickWeed -i -no-cache QuickWeed(1). This is a limited alternative to the normal weeder that keeps all builds in the cache, but may cause the repository to reclaim space. Since you've just erased your cache in step 2, this will clear away the derived files produced by builds that were in the old cache.

    4. As vadmin, run QuickWeed(1). This is a limited alternative to the normal weeder that keeps all builds in the cache, but may cause the repository to reclaim space. Since you've just erased your cache in step 2, this will clear away the derived files produced by builds that were in the old cache.

    4. Start the cache server back up. Also make sure that the repository server is running.

    5. Warm the cache by building popular models

    6. Remember to keep an eye on the disk space, and run the normal weeder before this happens again!

  • When does the weeder pause / stop serving client requests?

    Here's how to find the exact start and end times of the two periods during weeding within which the repository stops answering user requests, I've gone through the messages for a recent weeder run and the corresponding repository daemon log. Hopefully this will help others find the exact times of those two pauses.

    From the weeder log (/vesta-srv/autoweed/logs/060919-150129-weed.log):

    This is when the weeder asks the repository to begin performing deletions the first pause in responses to client requests occurs right after this.

    From the repository daemon log (/var/log/vesta/repository/logfile):

    This is the message that indicates that the repository has gotten the request from the weeder to begin deletions. The timestamp on this line is the time that the first pause in client requests begins.

    From the repository daemon log (/var/log/vesta/repository/logfile):

    This message shows when the repository finishes computing the set of source files to keep. The timestamp on this line is the time that the first pause in client requests ends. After this the repository will resume responding to client requests.

    From the repository daemon log (/var/log/vesta/repository/logfile):

    This message shows when the repository has completed the sort and merge of the list of source files to keep and the list of derived files to keep. The timestamp on this line is when the repository begins reclaiming disk space by deleting files.

    From the repository daemon log (/var/log/vesta/repository/logfile):

    This message shows when the repository has completed reclaiming space by deleting files.

    From the weeder log (/vesta-srv/autoweed/logs/060919-150129-weed.log):

    As you can see, the repository does not tell the weeder that it is done deleting files until long after it has resumed responding to user requets.

    From the weeder log (/vesta-srv/autoweed/logs/060919-150129-weed.log):

    This is when the weeder asks the repository to write out a checkpoint of its internal state. Writing the checkpoint is the second period during which the repository stops responding to user requests.

    From the repository daemon log (/var/log/vesta/repository/logfile):

    These two messages are the start and end of the checkpointing process. Between the times on these two messages, the repository will be paused again, unable to respond to user requests. After it finishes checkpointing it will immediately resume answering user requests.

    From the weeder log (/vesta-srv/autoweed/logs/060919-150129-weed.log):

    As you can see, the timestamps on the messages from the weeder about checkpointing line up very closely to the repository daemon messages which is very different from the time between the weeder messages about deleting dead repository files.

    --Ken