Dynamic workspaces cache

Unity Services
,
1

We’ve been starting to use the Dynamic Workspaces, and I have some questions.

Back in the release announcement, it said:

  • They use a Least Recently Used (LRU) cache system, meaning the actual space used by workspaces can be controlled, and files not recently accessed will be removed from the local cache, freeing up space.
  • The same cache is used by multiple workspaces that point to the same repo, so you can have as many copies as you need, but the actual space will be just a single copy.

There’s some interesting stuff here for multiple copies of the same workspace. But I wonder, what is the max cache size and is there any way to change that? It would be bad to have two copies of a workspace if added together with other dynamic workspaces blew past the cache size. You’d constantly be having to redownload files.

Second, is there any way to move the cache off the C: drive (where LOCALAPPDATA is located)? We have a lot of users that are using dynamic workspaces because their C: drive is tight on space.

2

Hi,

what is the max cache size and is there any way to change that?

You can specify the max amount of disk that you want to use for the cache using the parameter “–cachemaxsizeingb” As a sample : plasticfs.exe --cachemaxsizeingb 100 . By default, it depends on the size of the disk where it’s located:

  • Disk size <200GB → Cache size 10% of the disk size
  • Disk size <500GB → Cache size 25GB
  • Disk size >=500GB ->Cache size 50GB for cache

is there any way to move the cache off the C: drive (where LOCALAPPDATA is located)?

Please see the command below on how to set cache path:
plasticfs --cachepath d:\_cache\_plastic

How to use the parameter "--cachepath"

*** every time starting PlasticFS use the parameter manually**
*** Make sure to move previously cached directory to the new directory**

Please let us know if you have any questions.

3

Thanks for the answers!

There’s no way of setting this in the GUI (or with a config file, especially through plastic-global-config), though, so what you’d need to do is tell users to go and change the startup shortcut item added, correct? And it wouldn’t take effect if they stop/started dynamic workspaces from the GUI (for example, when they updated Plastic, so they weren’t getting plasticfs started from the startup item).

4

I played with changing it a bit, and I did find that if you start plasticfs from the button in the gui, it always just uses the params “–install”. That’s pretty unfortunate, if a user has needed to use dynamic workspaces due to disk space concerns (I’d think a common use case).

Best scenario would probably be to have it configurable in the GUI. I realized a plastic-global-config probably isn’t workable, because different people will have different drive letters for additional drives (and some will have only C: drives and won’t need it, anyway). So there’s no blanket setting I can give everyone.

Then when you change settings in the GUI, it’d change the settings of the startup shortcut. Or plasticfs would have a conf file, and wouldn’t need usually need command line parameters. And the GUI would just write the changes to that and restart plasticfs.

I also noticed a bit of a bug that I should enter a report on. When you switch plasticfs to use a cache on a different drive, it seems to corrupt the dynamic workspaces you previously created. You can’t open them any more, and you can’t delete them from the GUI. You have to manually remove them from plastic.workspaces.

5

Hello @jasonpierce, sorry for the late response. Let me address your points one by one.

I also noticed a bit of a bug that I should enter a report on. When you switch plasticfs to use a cache on a different drive, it seems to corrupt the dynamic workspaces you previously created. You can’t open them any more, and you can’t delete them from the GUI. You have to manually remove them from plastic.workspaces.

This is the most important point, so I want to comment on this first.

A) Note that dynamic workspaces have both, a mount point and a backing storage. The backing storage contains the workspace metadata among other things, so if you lose it, you lose the entire workspace.

B) Also note that the cachepath option does not actually tell where the cache is to PlasticFS. What it really does it to tell it where the entire PlasticFS storage lives, including not only the cache, but also all the backing storages of ALL your workspaces.

C) Lastly, your UVCS setup contains a plastic.workspaces file. That file tells PlasticFS which dynamic workspaces it must mount on start up… except, if you changed the “cachepath” (B) without moving the storage directory to the same location first, PlasticFS will create a new storage folder, it won’t find the workspace as listed by plastic.workspaces inside (A), and a pop-up error window will be shown.

In normal circumstances, users do not need to tweak the paths this way. If you get into this situation, let me suggest you two workarounds.

To get back to a fresh state:

  1. Check that PlasticFS is stopped (check for the tray app in the lower right corner, in the task bar).
  2. Go to your plastic.workspaces file (located at %LocalAppData%\.plastic4) and edit it to remove all your dynamic workspaces.
  3. Check that the default cache folder does not exist (%LocalAppData%\.plastic4\plasticfs-storage). If it does exist, remove it.
  4. Pick your intended destination path (let’s say, d:\_cache\_plastic) and check if it does not exist. If it does exist, remove this one too.
  5. Restart PlasticFS now using the --cachepath d:\_cache\_plastic option.
  6. Create a new dynamic workspace. You should be ready to go!

To change the cache/storage location after some use:

  1. Check that PlasticFS is stopped (check for the tray app in the lower right corner, in the task bar).
  2. Locate your current “cache” directory (%LocalAppData%\.plastic4\plasticfs-storage by default).
  3. Pick your intended destination path (let’s say, d:\_cache\_plastic) and simply move the directory there. Rename it if needed.
  4. Restart PlasticFS now using the --cachepath d:\_cache\_plastic option.

Remember that removing plasticfs-storage\plasticfs-shared-cache is okay, but removing plasticfs-storage will remove the workspaces themselves.

Also, if PlasticFS cannot locate the plasticfs-storage directory where a workspace was created, the pop-up error window will be triggered every time it tries to mount the workspaces. Keep in mind that you can stop PlasticFS as soon as that happens, move the directory to the right location and restart PlasticFS to fix it.

Now, going back to the other topics:

I played with changing it a bit, and I did find that if you start plasticfs from the button in the gui, it always just uses the params “–install”. That’s pretty unfortunate, if a user has needed to use dynamic workspaces due to disk space concerns (I’d think a common use case).

The install option is meant to create the shortcut. Note that the GUI is not meant to start and stop PlasticFS, instead, PlasticFS should start up by itself when rebooting the system. Right now most users do not change the storage location, but our suggestion is to follow these steps:

  1. Enable dynamic workspaces in the GUI. The shortcut gets created as a side-effect. PlasticFS is started too.
  2. Follow the instructions from “To get back to a fresh state”, but edit the shortcut to include the “cachepath” option.

You can find the shortcut if you press “Windows key + R”, and then type “shell:startup” and press Enter.

Note that, besides not accounting for the storage relocation, the install option should not increase your disk usage on its own.

Best scenario would probably be to have it configurable in the GUI. (…)

Sadly, there is no plans to add this option. Such a feature is unlikely to come soon because the GUI is not in charge of the life cycle of the PlasticFS process by design. However…

Or plasticfs would have a conf file, and wouldn’t need usually need command line parameters.

This will be implemented soon. You will need to edit it manually, but at least you will be able to set up your storage path in an easier way.

Do you need something more? Does this information help you?

1 Like
6

This is all incredibly helpful information. It will help a lot, and I appreciate it! But I have a couple of points.

First, if the GUI is not meant to stop and start PlasticFS, I think perhaps it’s a bad idea to have a section of the GUI that leads people to think that. It really does lead you down a potentially wrong path of using it. If nothing else, a really easy fix would be for the GUI to check for an already exiting starting item and run that (with whatever parameters it has) rather than always run plastic --install.

Second, there’s the problem of upgrading. When there’s a plastic update and you run it, and exit plastic fs as directed, it finishes and restarts plasticfs. But it restarts it with the default parameters. This means even if the user has done everything correctly, updating plastic breaks their custom plasticfs location.

7

First, if the GUI is not meant to stop and start PlasticFS, I think perhaps it’s a bad idea to have a section of the GUI that leads people to think that.

True, but bear in mind that PlasticFS is still in beta state. Even if you use PlasticFS, the UVCS client has dynamic workspaces support disabled by default.

Moreover, this option is meant to kick-start users and allow them to opt-in into dynamic workspaces by enabling their support, and is not that much about starting PlasticFS. The actual meat of the option changes how the GUI works. It’s a GUI focused option, that enables PlasticFS as a startup application as a side effect.

Still, I’ll make sure to share this feedback with the team to revise if we can make it more clear and useful. : )

Second, there’s the problem of upgrading. When there’s a plastic update and you run it, and exit plastic fs as directed, it finishes and restarts plasticfs. But it restarts it with the default parameters. This means even if the user has done everything correctly, updating plastic breaks their custom plasticfs location.

Totally true. It happens due to a limitation in the installer, and it will be solved thanks to the configuration file you mentioned before.

In the meantime, as you are using an special configuration, the workaround is to stop PlasticFS before running the installer. After the upgrade, you can start it manually with the right options.

Luckily, it won’t take long for this to be fixed. Stay tuned!

8

Unless I’m mistaken, this doesn’t fix it. You have to manually stop PlasticFS before running the installer, or the installer won’t proceed. But after the installer proceeds it starts plasticfs again. :thinking:

Good to hear that other changes might be coming soon.

9

Yep, just had an update, and just verified that it’s auto-starting the plasticfs without any command line params afterwards:
image

I do understand that if a user was sophisticated enough and had a good enough memory, they could workaround this by remembering every single time to exit the newly started plasticfs and navigate to their start menu and run the shortcut there.

Alas, this is a bad assumption for the dozens of users we have. :laughing:

10

You have to manually stop PlasticFS before running the installer, or the installer won’t proceed.

To be clear: the installer won’t stop PlasticFS automatically no matter what. But, in this case, you need to stop PlasticFS right before running the installer at all. This means you must stop it before the installer can possibly request you to do so.

Otherwise, the installer will remember that PlasticFS was running and it will restart it for you.

It goes without saying that this workaround is far from ideal. We will fix it soon.

12

Okay, I think I see what you’re saying, but still think it’s a very bad design. Because there’s no way for users to know that it restarting the installer for them is a bad thing.

13

I don’t disagree at all. But as said, this won’t be the case for too long. Stay tuned.

14

We have released the following task: Plastic SCM - Release Notes - 11.0.16.9184

NOTE: If you still have a shortcut located at this path:C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, If such shortcut already contains a --cachepath, you should remove the option from it so this configuration file can take effect.

Windows - PlasticFS: Relocate the storage into a separate disk

By default, PlasticFS backing storage is located at %LocalAppData%\plastic4\plasticfs-storage. Now you can relocate yours into a different directory or disk.

For that, you can just create a plasticfs.conf file next to your client.conf file, also located by default at %LocalAppData%\plastic4.

Then write something like this inside the file:

storagebasepath=D:\plasticfs-storage

The plasticfs-storage directory contains the PlasticFS shared cache among other things. The size of this subdirectory will grow as PlasticFS downloads file data on demand. If you want to move the shared cache in isolation, you can also do it, like this:

sharedcachebasepath=D:\plasticfs-shared-cache

Now follow these steps:

  1. Stop the PlasticFS tray application.

  2. If you already have a plasticfs-storage directory, move it to its new location. The same goes for plasticfs-shared-cache if you want to move that one.

  3. Restart the PlasticFS tray application, so the configuration file takes effect.

== WARNING ==

If you want to preserve your existing workspaces, but you didn’t follow the second step correctly, a brand new storage directory will be created at the new location and you will be prompted with an error by the tray application. Don’t panic! This can be fixed by stopping PlasticFS and replacing that new storage directory with the old one.

1 Like