The output entries from Search for Files and Folders in Starting Entry (Search Repository).    The only thing I can think is that the Try Catch is making it loop over and over again somehow.    The number of entries in the result are correct. 

Here is the query if that is useful.

Oh... I think you led me to the answer though!   The Migrate Entry is set to Starting Entry!    That would do it I would think!   

What is interesting is WHY does Laserfiche allow that movement to happen 1000+ times and just take up space with duplicate identical entries!   Really hard to see all of this without attaching a debugger.

What exactly filled up the space? Because Migrate Entries does not make copies, but running it over and over could generate extra activity in SQL (and its log) and audit logs in the repository.

I have no idea.   It is all data though.   It is all contained inside the volumes.   The primary LF volume is only 30GB in size.   I moved a 6GB file to a BLANK new volume and it has taken up 118GB and only stopped there because I terminated the workflow.   Looks at the time stamps starting with Archive000002.   This is the workflow filling it up.     If you know of a way to look inside I am interested.   There was nothing in the error logs or anything.  SQL is on an entirely different server.

Your search criteria would return nothing if the starting entry was a document. If it was a folder, it would return all child entries recursively.

I'm assuming it was a folder if the activities following Search Repository have run. Migrating a folder would migrate all its child entries. Given the incorrect entry configuration in Migrate Entries, this would end up migrating all child entries of this starting entry, once for each entry found. So the same entries would be migrated multiple times.

You should be able to look in the instance details on the Messages tab and see how many results it returned. Then the total number of migrations would multiplicate rapidly from there as each child  subfolder would trigger its own duplication because calling migrate on the folder would migrate its own child entries.

With a rollover volume, you would see those subfolders get created as the documents migrated and the current one fills up.

The reason you're seeing it take more space than the original 6GB is because the Laserfiche Server performs a copy+delete under the hood and does not remove the originals until the migration is complete. This is done to ensure that no data is lost if the migration fails in the middle.