Christopher (Drashna)

another note, is that the pool will maintain the NTFS permissions from the old install, too. If you used system specific accounts in the permissions (like "MyUser", "(name)", etc), then you may need to update/replace the permissions on the pool, once it's remounted.

the archive option when removing a disk should also do this. But yeah, simply moving the files out of the poolPart folders will work. Just note that the contents of the pool may be spread out all over the pool

Have you tried running a CHKDSK pass on the disks? Sometimes when they appear "RAW" this can work and recover the file system. However, it's kind of a long shot. Aside from that, it would be data recovery, most likely.

Some external enclosures do some funky things with the file system, that make it not portable.... however, this is very rare. In most cases, you shouldn't have any issues moving from SATA to USB. As for a specific enclosure, sorry, no. I .... actively avoid usb enclosures, personally.

I haven't used windows containers specifically, but have used Docker Desktop on Windows, and use volumes on the pool for storage, without any problems (using wsl2)

Fixed sized is good. Other than needing to fit on the underlying drives, it should be fine.

If the "allow balancer plugin to trigger balancing", then it should be immediately. Otherwise, it should be the next time that a balancing pass occurs based on the balancing settings

Just a heads up, read striping doesn't guarantee that it will read from the different drives.

When recovering the drive, do you see a hidden PoolPart on the drive(s)? You may need to enable the "show hidden files" option in Windows to see it. If these files are no longer on the underlying disks, then the pool will be removed, since there is no longer a pool. If the folders are there, try restarting the "StableBit DrivePool Server" on the system, and see if that helps.

Shane is stop on, as usual. Any files that are open are usually "locked". And when measuring, duplicating and balancing, StableBit DrivePool avoids locked files, since we can't ensure the state of these files while they are locked. (which is part of why they get locked by the OS, in the first place, so nothing else can mess with them). Once they're no longer locked, they should be fine, and should be updated during use. Though resizing VHD files are ...tricky. And if you have the space, fixed sized VHDs would be better to use, if they're stored on the pool.

there are some flags that can help with the scan. Namely "/scan", but this also skips a number of important checks (like checking the MFT itself), which is why I don't like recommending it)

I agree with shane in that untested backup/redundancy is just catastrophic data loss in disguise/waiting. "trust but verify". Also, knowing how to restore/repair things rather than having to desperately figure that out ***when*** (not if) things fail is always a good idea (and not just because panicking can lead to even more data loss, but that's definitely a factor too!)

That's ... very odd. And StableBit DrivePool doesn't use nor create any special folders like this. You might need to take ownership of the folder, and then change the permissions before you can delete it. This guide is meant to be applied to the whole pool, but you can follow it for a specific folder, if needed: https://wiki.covecube.com/StableBit_DrivePool_Q5510455

When removing a drive from the pool (using the UI), it checks the files on the pool, and based on the options, moves files. All of the pooled data is in the hidden PoolPart.xxxx folders. Unduplicated data is moved during a removal. Duplicated data is moved unless the "duplicate data later" option is enabled.... and in this case, only data that is unique to that drive (eg, unduplicated data on the drive, and any duplicated data that may only be on that drive) is moved off of the drive. Once the drive is removed, a duplication pass is triggered, so that the data can be reduplicated. The process is outlined in the manual: https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Removing a Drive from the Pool

If you open up disk management on the system, does the drive show up as "dynamic"? Also, have you run a CHKDSK pass on the drive? Worst case, you should be fine to remove the missing disk, and re-add the drive to the pool. You may/will need to migrate the contents from the poolpart folder (as outlined here: https://wiki.covecube.com/StableBit_DrivePool_F1655

That's odd. In "services.msc", in the properties for the StableBit DrivePool service, in the "Recovery" tab, make sure that all three dropdowns are set to "restart the service". If it continues to happen, setting the startup type to "automatic (delayed)" can help.

Well, the biggest ones are probably the bypass file system filters and network i/o boost the Network I/O Boost option uses some CPU time to identify where the requests are coming from and prioritize network traffic over local access. This can make playback over network shares more snappy. The other is the "Bypass file system filters". I don't recommend leaving this one enabled, but ... may be the most likely culprite. specifically, file system filters are drivers that "sit" ontop of the file system. They intercept and can modify any file system API access... and this is explicitly how realtime virus scanners work. The complication comes that when accessing a file, the file system filter is called for the pool itself (normal), and then for each instance on the pooled drives. The bypass does what it says and bypasses this... for the underlying, pooled drive access. This can speed things up, but stuff like deduplication, some encryption software, and other disk tools may be impacted by this because they aren't being called correctly when the bypass is on. However, conversely, it means that the same file may be "scanned" multiple times, and for some software ... that can cause issues.

You should be able to use the "remove" option, and use the "Archive" option to remove the disk from the pool and not move the files off of it. Alternatively, on the H:\ pool, if you enable "show hidden files", you should see a "poolpart.xxxxx" folder. Note this folder name. From the command line (elevated/administrative), you can run "dpcmd ignore-poolpart poolpart.xxxx" which will immediately eject the disk from the pool and cause it t show up as "missing". You can then remove the "missing" pool from the Y:\ pool. And I'm guessing that you were moving around disks when this happened?

If you have mutliple drives with data on them, the simplest option would be to add them to the pool, and seed the pool. https://wiki.covecube.com/StableBit_DrivePool_Q4142489 This will effectively combine the folders into a single structure Eg, the "tv" example you have, all of those would appear on the pool in the /tv/ folder, with all of the convents from each drive. But given your folder structure, you want/need to just rescan your library. As for the issues, it depends on how exactly you had things configured, and what options you used with robocoby. However, I would recommend using something like WizTree to see where all the files are on your disks. No affiliation here, but I do use it personally, as it makes finding where all your data is at very simple. If the files are still on the disks, then moving them into the "poolpart" folder structure is the quickest and simplest option. Just make sure you remeasure the pool after doing so.

You can double check the current state of the permissions. If you see entries with a long string of letters/numbers, then yeah, you'd want to use it

Check the Event Viewer. Specifically the "System" section. You may see disk, ntfs or controller errors. This can be very helpful for tracking down problem drives. (and is one of the things I do in tickets when people report these type of issues). More often than not, there is a drive causing problems and it shows up here. It's not always a failing drive, there have been cases of a bad connection (and is something I've been hit with myself, actually).

That's very odd. The "COVECUBECovefsDisk_____" disk is definitely the pool driver. Though, in some cases, a lot of disks connecting at once can cause problems for Windows, and double enumerates drives. I've seen this with the pool, but I've also seen this with normal drives (especially USB). That said, there is also a "controller" driver for the pool, in addition to the disk driver. It's a slightly different name, but is pretty close. Is that what you're seeing here? Also, if it's not causing any issues, you should be okay to just ignore it. Though, you can also uninstall the extra devices from Device Manager (and this may help long term, actually).

Is this for the access time, the modified time or created time?

Isn't this the KB that is killing SSDs? If so, it's likely some bad drive code.... If you're able to roll back, hopefully there is a fix to this patch. If not, system restore *may* work for you here. And if not .... Well, hopefully, there is a patch to fix this. For real.... Makes me wish that we did have a linux version. 😕 Between this, copilot creep, windows recall (aka spyware)...

If you're still experiencing the issue the refresh command may help. Also, try rebooting the system, and see if that helps. If not, open a ticket at https://stablebit.com/Contact