Shane

The service handles things like balancing and statistics; detecting pooled disks happens at the kernel/driver level. Note that in DrivePool 2.x each hidden PoolPart folder has a unique extension and associated metadata identifier (even removing and immediately re-adding the same disk will result in a different one); because SnapRAID's parity calculations rely on paths remaining the same you should use the PoolPart folders (e.g. "d:\PoolPart.6cbd4f77-9511-4356-a6b3-2ce26ba79d10") as SnapRAID's data disk mount points rather than the root folders (e.g. "d:\") so that you can update the appropriate data disk mount point in the snapraid config file when you replace a drive to avoid needing a rebuild. Presuming the above use of poolparts as data disk mount points is being done: Pause SnapRAID scheduling (if you've set anything up). Add the new drive to the pool. Stop the DrivePool service. Rename the "PoolPart" section of the old disk's hidden poolpart folder so it stops being an active poolpart folder (e.g. to "oldpart") but optionally leave its extension unchanged to make it easier in case you need to revert. Copy the content (except protected system folders, e.g. "System Volume Information", which you should have set as excluded in SnapRAID) of the old disk's hidden poolpart into the new disk's hidden poolpart, then update the data disk mount point, then verify. See https://www.snapraid.it/faq#repdatadisk If step 5 worked out, then you can delete the old disk's hidden poolpart and continue. Start the DrivePool service. The old drive should be detected as "missing" and then you should remove it from the pool. In the DrivePool GUI, choose Manage Pool -> Re-measure... to ensure it is accounting for your manual movement of content. Resume SnapRAID scheduling (if you've set anything up). P.S. Regarding multiple content list files in your SnapRAID config, keep in mind that due to DrivePool this means that - for example - "d:\poolpart.1\snapraid.content" and "e:\poolpart.2\snapraid.content", where "d:" and "e:" are disks in the same pool, are effectively the same file on the same disk; either keep content list files outside of the pool (e.g. "d:\snapraid.content" and "e:\snapraid.content") or use different filenames (e.g. "d:\poolpart.1\snapraid.content1" and "e:\poolpart.2\snapraid.content2").

If you haven't already, could you see how it reacts if you set the automatic balancing trigger balance ratio to 0% and the automatic balancing trigger data limit to... say... 650 GB? It's also possible the SSD Optimizer will still want to empty it to zero but when the balancing actually runs it's only then that it sees there's actually nothing to move due to the File Placement rules butting in and going "nope, not moving that".

The only thing a slower drive will affect is how long it takes for DrivePoool to access it. Otherwise no, you can have drives of different speeds in the same pool.

DrivePool doesn't need drives of the same capacity (e.g. one of my pools is three 12 TB, a 4 TB and a 3 TB). It will normally put new files on whatever drive has the most free space at the time.

The "real-time file placements set by the balancing plug-ins" only refers to new files, not files that are already on the pool. In short there are two types of placements that can be done by the balancing plug-ins: real-time and on-balancing. The SSD Optimizer can do both: it wants to place new files in the "SSD" drives, which it does in real-time, and place existing files in the "Archive" drives, which it does when balancing is triggered. If the above option is ticked, its real-time placement has priority over the File Placement rules; if the above is not ticked, the File Placement rules have priority over its real-time placement. https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Balancing Settings

Hi Roger, are you saying that with your current settings: files are never going onto the drives marked "SSD" in the SSD Optimizer plugin (except per the File Placement rules you've set)? you should tick "File placement rules respect real-time file placement limits set by the balancing plug-ins." files do go to the drives marked "SSD" in the SSD Optimizer plugin but are then being emptied faster than you'd prefer? the SSD Optimizer doesn't exclude files that would be prevented from being moved due to File Placement rules when calculating whether it should empty the "SSD" drives, so perhaps try lowering the balance ratio (maybe even to zero) and increasing the "at least this much data" value to compensate? something else?

Not that I know of. It's kinda problematic as balancing by absolute (rather than percentage/relative) used space risks running into the problem of moving files into disks with insufficient free space. As a workaround - I'm not familiar with SNAPRaid to know if this suits - could you perhaps resize the volumes on the drives so they're all the same size, or put non-pooled file(s) on the pooled drive(s) of a suitable size so that they all have the same "free" space? If you really need it though, I'd suggest making a feature request to add the option (perhaps to the Disk Space Equalization balancer?) via the contact form.

Not that I'm aware of. It should be listing the details in its history, is it giving any particular reason as to why?

If a single drive drops from a pool then it should have gone into read-only mode and duplicated files should still be present in the pool, regardless of why the single drive dropped out. If the drive is still present in Explorer / Disk Management and seems to be okay, but is no longer in the pool, DrivePool's metadata (the bit that says "the hidden poolpart folders on drives A, B, C, etc are part of pool X") may have been damaged. I'd try a Manage Pool -> Re-measure... and if that doesn't help try Cog -> Troubleshooting -> Recheck duplication... and if that doesn't help I'd consider lodging a support ticket with Stablebit since the metadata is supposed to be stored in a triply redundant fashion where possible to prevent this sort of problem.

YMMV but I wouldn't trust that drive for storing anything particularly precious that wasn't backed up or duplicated elsewhere; chkdsk /r should not BSOD on a good drive. My guesses: the BSOD happened because the chkdsk ran into the bad sector, tried to recover data from it and the drive behaved in an unexpected way (e.g. maybe it sent back "potato" when the code was only programmed to handle "apple" or "banana"). That's basically what a BSOD is after all - the OS going "something happened that I don't know how to handle, so I'm stopping everything rather than risk making something worse". the drive has either #1 replaced the bad sector with a spare from a reserve that the drive doesn't count as a reallocation (according to the drive manufacturer anyway), #2 performed its own internal repair of the sector and satisfied itself that the sector is no longer bad, or #3 zeroing the sector didn't trip the problem, so as far as it cares all is well in drive land. Anyway glad you haven't lost anything!

Hi, see https://community.covecube.com/index.php?/topic/11439-file-placement-rules-being-ignored/&do=findComment&comment=43160

You don't appear to have any files actually in the pool? Did you transfer the files to the H: drive pool (recommended), to the hidden poolpart folders on the D/E/F drives (requires knowing what one is doing) or to non-pool folders on the D/E/F drives (they won't be in the pool)?

Click on the affected drive in Scanner. Then click on the plus sign next to it. If any part of the disk is grey instead of green or red, click the Start Check button on the left (hover over the buttons to see the tooltips if needed) so that it can complete scanning (this can take a long while). Once all of the disk is colored there should be three green ticks below (indicating the disk is now healthy), however if there is a red cross instead of the first green tick click the underlined text beside it. This should bring up the File Scan window. Start the file scan to proceed with checking for damaged files and attempting to recover them. https://stablebit.com/Support/Scanner/2.X/Manual?Section=File Recovery Note: after you've used Scanner to run file recovery, if the disk is still complaining and you want to force the disk to go ahead and confirm the unused sector as good/bad, open a command prompt and run the command "chkdsk driveletter: /r" as an administrator (where driveletter is the drive letter of the affected drive). This will take a considerable amount of time however.

Looks like it might still be an issue - depending on the utility you're trying to use. I'm running some tests on my home server using DrivePool 2.3.2.1493 (latest version currently) with Read Striping temporarily enabled (it defaults to off). I haven't reproduced the issue with FLAC but I am using the more recent 1.4.2 release, HashCheck v2.4.0 (gurnec) sometimes returns MISMATCH or UNREADABLE (occasionally on the 1st and 3rd file of my first sample set of 79 files totalling 1.2GB) or just UNREADABLE (much more frequently on my second sample set of 82 files totalling 185GB), and HashTools 4.6 (Binary Fortress) hasn't had any problems at all on any passes so far of either sample set. Update: I also tested the Windows file comparison tool FC.exe and found it was susceptible too, sometimes returning either mismatching bytes or failing to find a file on the pool despite it being present. From what I can tell this issue does not affect normal file copy operations: both loop copy (a->b->a) and cascade copy (a->b->c) tests of the smaller sample set shows no corruption at all after 512 iterations, although I am still running these tests with the larger sample set and will edit this post with the result after they finish in a day or two. Edit: the larget sample set also showed no corruption after 24 iterations (cascade, could not run more due to available space) and 77 iterations (loop). Given the above: my guess would be that different file-checking utilities might be using different functions/calls to read the files and some of those functions/calls may be too low-level / not designed to allow for virtual drives, although I'm not sure how that results in different data being delivered from the virtual drive and only sometimes at that. Some sort of race condition or timeout? Thankfully, as mentioned above, the Read Striping option is not enabled by default (which might also be why this issue hasn't seen much light). @Christopher (Drashna) It might be a good idea to add a Y/N dialog warning (or at least update the tooltip) to the Read Striping option, perhaps along the lines of "some utilities that depend on reading files in chunks, e.g. for comparison or integrity checking, may experience issues with this enabled"?

If drivepool has duplicates available on other drives to replace damaged files that are detected and removed by chkdsk then drivepool will do so when it next does a consistency check (which you can also manually trigger: Settings -> Troubleshooting -> Recheck duplication).

Drivepool works in a way that doesn't keep an "original" and a "copy" - a duplicated file simply exists on multiple drives. Folder duplication has priority over file placement where they conflict - for example, if a folder should have 3x duplication but file placement is restricted to 2 drives, it will place 2 duplicates in those drives and another duplicate somewhere else - and will warn you with a banner in the File Placement tab that it was unable to fully comply with your placement rules.

1. If duplication is not set to real-time (Manage Pool -> Performance -> Real-time duplication) it will only run duplication every 24 hours or when duplication level is enabled/changed, and the duplication pass can take some time to complete depending on the amount that needs to be duplicated. Could that be the issue? 2. You may need to tick "Balancing plug-ins respect file placement rules" in Manage Pool -> Balancing -> Settings. Also if you have duplication enabled for a folder then you might want to check whether that is overriding any File Placement rules that say to store that folder in only one drive (because then Drivepool is being told contradictory things).

Did you have any luck with this? Otherwise I think you might have to submit a feature request to the developer via the Contact form.

Latest 64 bit edition of both should work with it? Do note that Drivepool requires simple, non-dynamic NTFS (or ReFS) drives though, as far as I know you can't pool drives that are created using Microsoft's Storage Spaces or Microsoft's software RAID (you can pool hardware RAID drives if they meet the aforementioned criteria).

It doesn't look like the option exists; you can submit a feature request via the Contact form or you could try a third-party utility (a quick google found three reviewed here) that adds it to Windows programs.

I don't think there's any option to adjust it. This probably merits being submitted via the Contact form as well I think; the consistency checking schedule being controllable to reduce wear and resource usage is something I think the community would be interested in but can only be added by the developer.

@Roger79 If the SSD Optimizer counts as "emptying" the SSD drives into the Archive drives, you might need under Balancing -> Settings -> File placement settings: (uncertain) File placement rules respect... (ticked) Balancing plug-ins respect file placement rules (unticked) Unless the drive is being emptied. The other possibility is that File Placement being told "use drive X as permanent storage" isn't compatible with the SSD Optimizer being told "use drive X as temporary cache".

Sounds like you'd want the following for each pool? Balancing -> Balancers -> only SSD Optimizer ticked under Drives, tick the SSD / Archive drives as appropriate to set your cache drive under Options, set sliders as desired (these only concern filling, they don't empty) under Ordered placement, leave both Unduplicated and Duplicated unticked (or, if you want to use it, make sure "Leave the files as they are" is selected). Balancing -> Settings under Automatic balancing, select Balance immediately, with the "Not more often than..." unticked under Automatic balancing - Triggers, select 100% / unticked (as you want it always moved straight away) under Plug-in settings, "Allow balancing plug-ins to force immediate balancing..." ticked (so it should move straight away anyway) under File placement settings, should be irrelevant since you're not using the File Placement section. This should result in any files copied to the pool going via your SSD cache drive first then being immediately moved to the others. As always with "production" data, I recommend confirming the behaviour is as expected with a test pool.

Marking a pooled drive read-only may cause drivepool to not write to the pool at all? EDIT: can cause it to complain that the disk is write-protected if an operation on the pool involves that disk. My suggestion (assuming otherwise defaults) would be: Manage Pool -> Balancing... -> Balancers tab -> Ordered File Placement plugin -> move the problem drive to the bottom -> select "Only control new file placement". Manage Pool -> Balancing... -> Settings tab -> tick "File placement rules respect real-time file placement limits set by the balancing plugins" This should still allow other disks in the pool to be written.

Given you've already chosen not to keep personal data, at this point personally I'd do a bare metal install of Windows - that is using external install media (e.g. USB or DVD) and choosing to delete the existing OS partition entirely so it doesn't retain any system files/configuration at all from the previous install.