yerep

Thanks very much for this suggestion, this does actually make the game launch. However, I expect that when it tries to update it'll run into the same issue, so undoing and redoing junction links every time isn't really scalable with the number of updates i'd have to do this for. Is there anything else you know of I can try? Any of Drivepool's advanced options maybe? Given the error from the Oculus log, it seems to me that the issue points to an issue with the Drivepool emulation of NTFS?

Hey guys, Using DrivePool and loving it, however it seems that Oculus is unable to write to the pool to install games. I get the following error (from Oculus logs): [Debug] [14/05/2018 21:47:33] Starting up OVRLibraryService v1.16.0.0. [Debug] [14/05/2018 21:47:33] Starting up. [Debug] [14/05/2018 21:47:33] IPC connection opened. [Debug] [14/05/2018 21:47:33] App libraries for this user: [21398abf-36d1-4949-82a9-2dc9358f0bd9, 47743d8f-1b96-4260-ae83-8bf22c5ab743, 5ef47725-c013-4e27-890a-03846d32855f, CORE_DATA] [Debug] [14/05/2018 21:47:33] OVRLibraryService starting in direct mode. Arguments: [library, install-chunked-package, 5ef47725-c013-4e27-890a-03846d32855f, \\?\Volume{97ef64b6-5cc9-405b-bb76-6a4eef7c95d5}\Oculus\Downloads\oculus-first-contact\12\oculus-first-contact.zip, \\?\Volume{97ef64b6-5cc9-405b-bb76-6a4eef7c95d5}\Oculus\Downloads\oculus-first-contact\12\oculus-first-contact.sig] [Debug] [14/05/2018 21:47:33] IPC thread running; waiting for Oaf to connect. [Debug] [14/05/2018 21:47:33] IPC connection established! [Debug] [14/05/2018 21:47:33] Creating NTFS transaction. [Debug] [14/05/2018 21:47:33] Operation failed. Rolling back changes. [Error] [14/05/2018 21:47:33] Error starting chunked install! Daybreak.OVRLibraryService.Libraries.LibrarianException: Error clobbering zombie temp folder. ---> Daybreak.Core.Io+IoException: Error creating directory '\\?\Volume{97ef64b6-5cc9-405b-bb76-6a4eef7c95d5}\Oculus\tmp'. ---> System.ComponentModel.Win32Exception: This object is not allowed to be opened in a transaction --- End of inner exception stack trace --- at Daybreak.Core.Io.CreateDirectory(Nullable`1 transaction, String path) at Daybreak.Core.Io.RecursivelyCreateDirectory(Nullable`1 transaction, String directory) at Daybreak.OVRLibraryService.Libraries.LibrarianOperation.ExtractPackages[T](IntPtr transaction, IEnumerable`1 zips, String tempDir) --- End of inner exception stack trace --- at Daybreak.OVRLibraryService.Libraries.LibrarianOperation.ExtractPackages[T](IntPtr transaction, IEnumerable`1 zips, String tempDir) at Daybreak.OVRLibraryService.Libraries.LibraryController.<>c__DisplayClass9_0.<InstallChunkedPackage>b__0(IntPtr transaction) at Daybreak.Core.TxF.PerformBlockInTransaction[T](Func`2 block, Nullable`1 existingTransaction) at Daybreak.OVRLibraryService.Libraries.LibraryController.InstallChunkedPackage(IEnumerable`1 zips, ChunkedProgressUpdater updater, OafCancellationHandler oafCancellationHandler, IChunkDownloader chunkDownloader) [Warning] [14/05/2018 21:47:33] Oaf IPC connection lost! [Debug] [14/05/2018 21:47:33] IPC connection destroyed. [Debug] [14/05/2018 21:47:33] Exiting with code 6 (ErrorDeletingTempDirectory). Steam/Uplay can install to the pool OK, so I assume this is an Oculus specific problem. It installs on non pooled drives fine. Are there any settings I can play with to get this to work? Thanks

Thanks for your response, amazing software Yep, read striping is enabled - admittedly it wasn't a very scientific test, however I was keeping an eye on task manager whilst loading the game, and whereas before it would insta-load from my SSD, it took significantly longer after running it after it was added to the pool and duplicated across the HDDs. Would you be able to shed some light on how drivepool assumes a drive is "busy"? Presumably this works well when the pool is made up of all HDDs or SSDs, but mixing the two may mean that it may "assume" an SSD is busy, when actually it would save time waiting for it to become available again because of the much faster read speeds?

Hello, I have a quick question regarding Drivepool's use of HDDs and SSDs in the same pool. My setup is a pool with a mix of HDDs and SSDs. I have my pool set to 2x duplication, and as space on the SSDs is limited, I have file rules set up so that games I am currently playing store one of their duplicates on the SSDs. However, when running a game, it looks like Drivepool will still try and load some data off of the HDDs, even if the SSDs are idle. Is there a better way to do what I am trying to achieve? Is there an option to "prefer" reads off of an SSD if the requested file is on one? Would this be difficult to implement? (obviously this would bypass drive busy/active wait time logic) I dont want to disable duplication for my game data, but if that's the only way to make sure they are loaded off of the SSDs it seems like a sub-optimal compromise to have to make considering all the other complicated logic that Drivepool does Thanks!