Bugzilla

Note, it is potentially suboptimal to put caches on a different partition to task directories, since caches then have to be moved with copy/delete semantics, which can be a very expensive operation e.g. when there are many files in the cache.

Mounting a cache from the same partition essentially involves updating a single inode.

Originally, on gecko windows workers, caches were put on Y: drive and task directories on Z: drive because OpenCloudConfig formatted the Z: drive on reboot, since generic-worker was not always able to delete previous task directories.

If that is no longer the case, the format-on-boot strategy could be revised.

Note, it is potentially suboptimal to put caches on a different partition to task directories, since caches then have to be moved with copy/delete semantics, which can be a very expensive operation e.g. when there are many files in the cache.

Mounting a cache from the same partition essentially involves updating a single inode.

Originally, on gecko windows workers, caches were put on Y: drive and task directories on Z: drive because OpenCloudConfig formatted the Z: drive on reboot, since generic-worker was not always able to delete previous task directories.

If that is no longer the case, the format-on-boot strategy could be revised. I have a nagging feeling there might be an open issue though whereby some tasks were creating files or folders and then denying all other users delete permission, so I suspect we might need to first take ownership of the files/folders and their subdirectories before deleting them (or doing this if the initial deletion attempt fails).

Note, it is potentially suboptimal to put caches on a different partition to task directories, since caches then have to be moved with copy/delete semantics, which can be a very expensive operation e.g. when there are many files in the cache.

Mounting a cache from the same partition essentially involves updating a single inode.

Originally, on gecko windows workers, caches were put on Y: drive and task directories on Z: drive because OpenCloudConfig formatted the Z: drive on reboot, since generic-worker was not always able to delete previous task directories.

If that is no longer the case, the format-on-boot strategy could be revised. I have a nagging feeling that there might be an open issue whereby some tasks are creating files/folders and then denying all other users delete permission, such that the worker did not have permission to delete them. I suspect we might need to first take ownership of the files/folders and their subdirectories before deleting them (or for a slightly more optimal solution for the common case, only taking ownership if the initial deletion attempt fails, and then attempting to delete again).