Evacuating to specific drives?

[fleggett1]

I think I've got a real problem on my hands.  A few days ago, for unrelated reasons, I swapped-out my CPU for another.  SOMETHING happened after the swap, as my Windows 11 install became corrupted to the point that I had to perform a complete reinstall.  And it's been downhill since then, as my system will spontaneously reboot.  Doesn't crash or otherwise BSOD, but just does a fast reboot.  It's driving me crazy and, for possibly mystical reasons, I suspect my pool is the culprit.

Why?  Because whenever I do anything with the pool, a reboot seems to follow.  Sometimes it doesn't happen immediately, but it WILL happen and it's the only commonality I've seen, as I can go all day without seeing one of these reboots just so long as I don't touch the pool.

Now, I know that doesn't make much sense, as obviously DP is reading and writing stuff to the pool in the background, but it's the only thing I've been able to deduce.  I also suspect this because, when I install Scanner, the reboots really start to kick in.

I'm using a Sabrent 10-bay enclosure for the pool.  I have raging mistrust issues when it comes to this stuff, so the only thing I know to do is to completely rebuild the pool.  Fortunately, I have a spare bay I can use for this process, which I know is going to be a long and painful affair, but I'd really, REALLY like to save the 10+ TB of Linux ISOs I've amassed over the years.

My plan was to buy a new drive, put it into a spare bay, add it to the pool, evacuate drive 1 to the new drive, drop drive 1 from the pool, do a long reformat of drive 1, add it back to the pool (assuming it passes), then re-evacuate the files back to drive 1.  Rinse and repeat.

Problem is I don't know of a way to evacuate a drive to another user-defined drive.  I know I could simply evacuate each drive, drop it from the pool, reformat it, and add it back, but I don't know if the other "old" drives might also have problems, so I want to do the evacuations to a brand-new drive one-by-one. Some of my drives are cheap shucks from several years ago that might be failing in ways that Windows can't handle. In the end, I want to long format the entire damn lot to be 100% certain they're good to use.

So, is this possible?

[Shane]

Regarding the reboots, given you strongly suspect it's DrivePool-related then I would recommend opening a support ticket with StableBit. Though with any use of Scanner increasing the reboot frequency I'd suspect some kind of load/conflict trigger; I'd be giving your new CPU dubious looks too.

Evacuating follows the same rules as placing files on the drive - for example it will default to evacuating to the drive(s) with the most free space at the time - so it should thus be possible to force it to use a specific drive via the Ordered File Placement balancer, but I'd want to test that first.

However if your machine is often rebooting whenever you're using the pool then I'm not sure how you plan to successfully evacuate a drive via DrivePool's Remove function; you may have to do so manually:

• Add the new drive.
• Stop the DrivePool service.
• Copy your content from the hidden poolpart folder on the old drive to the hidden poolpart folder on the new drive. Don't include system folders (e.g. recycle, sysvol, covefs).
• I'd also suggest verifying the copy afterwards (e.g. using FreeFileSync, md5deep, et cetera) if your copy method doesn't include its own post-copy verification.
• Format the old drive.
• Start the DrivePool service.
• Amend any balancers or placement rules that specify the old drive.
• Remove the "missing" old drive.

[fleggett1]

Well, I don't think DP in and of itself is the problem.  I just think the disks themselves have gotten themselves into a degraded state for whatever reason.  When I did the cpu switch-out, one of the drives dropped-out of the pool.  I was really irritated and exasperated at the time, so I just shoved the drive back into its bay, made sure the door was 100% shut, and it seemed to stick, but it was one of those shucked drives, so it may (or may not) be actually healthy.

Another reason I suspect the pool has become problematic is because, when I reinstalled Windows, I noticed that some disks had the MSR partition and some didn't.  Also, one of the drives didn't have a gpt volume, which is hellaciously odd because I always use gpt volumes.  These sort of inconsistencies play havoc with my OCD.  Combine that with these intermittent restarts and I don't know what to do other than to try to get the pool back to a "baseline" state.

Oh, to make matters even worse, I took a look at event viewer and saw a bunch of these:

"Disk 9 has the same disk identifiers as one or more disks connected to the system. Go to Microsoft's support website (http://support.microsoft.com) and search for KB2983588 to resolve the issue."

So, something has definitely gone awry.  I was hoping to get lucky and let DP do the evacuations itself, which I know contradicts my suspicion that DP may in some bizarre way causing the restarts, but at this point I'm willing to sacrifice a goat if it'll make these problems go away.  I'm at an age where these things are no longer neat things to track down, but are real obstacles to my mental well-being.

If I do have to do things manually, I was simply gonna let Explorer do all the work.  Does it not verify file operations?

Thanks for the quick feedback!

[Shane]

Explorer relies on the underlying hardware's error-checking capability to indicate any problems when copying or moving a file. When dealing with a system that is rebooting by itself without explanation, I wouldn't trust that - let alone for anything critical or irreplaceable. You can use copier programs such as Teracopy or Fastcopy that have built-in checksum verification as an option when copying to a new target, or use syncing programs such as FreeFileSync or TreeComp which allow you to compare the contents of two existing drives/folders.

I would also suggest checking and resolving the disk identifiers issue before proceeding.

[Christopher (Drashna)]

For the MSR partiation, this depends if the drive is MBR or GPT, and sometimes, how it was initialized+partitioned.  Either way, the presence/lack shouldn't effect things.  My pool has a mix of these, and has for a long while. 

As for the non-GPT drive, it's possible that there was some partitioning error?  Eg, if the system was unstable and rebooting/BSODing, any time that the disk is being written to, there is a chance of corruption/damage. 

22 hours ago, fleggett1 said:

"Disk 9 has the same disk identifiers as one or more disks connected to the system. Go to Microsoft's support website (http://support.microsoft.com) and search for KB2983588 to resolve the issue."

You can use diskpart or powershell to fix this. IIRC.  But it shouldn't be too big of an issue.  And if you're using Windows Server, the Multipath I/O feature can "fix" this. 

Also, I would recommend checking the event viewer for disk, file system and controller errors.  They may point to a specific disk. 

But Also, if you haven't, run a CHKDSK pass on *all* of the disks (except to pool)

 

[fleggett1]

It's definitely pool related.  I installed another program which hits the pool fairly hard (NOT Scanner) and the restarts returned with a vengeance.

I checked all the disk id's using diskpart's uniqueid feature and every one was different, so I don't know why Windows was complaining about clashing identifiers.  I also chkdsk'd every single disk using Disk Management's tool tab and one of the pool drives had errors, which it fixed (I hope).  I used DM's tool because I had to assign drive letters before a scan could be run.

Oh, and >all< the drives are showing as gpt.  Gremlins!

I've also periodically seen file duplication consistency warnings from DP that have required manual intervention, but I don't have file duplication turned on, so I don't know what that's about.

I don't know what to do from here.  I could go back to the old cpu, but my instinct tells me that's not the culprit.  Maybe something has gone wrong with the Sabrent, but that also seems unlikely given that everything was running smoothly before the cpu switch-out.  I don't have a second Sabrent to try and buying another one when I don't know if my current one is going south is a financially risky endeavour (the damn things are $600).

I suppose the only thing I can do at this point is go back to the previous cpu.  It's just so odd and frustrating that the system runs normally otherwise.

Should I try rebuilding the pool from scratch by removing all the disks, rebooting, and adding them back?  Is it possible something has gotten corrupted in the pool's "config files"?

[fleggett1]

Just some more info, as the system rebooted itself just a couple of minutes ago.

In Event Viewer under Windows Logs -> Applications, I've run across a few of these in red:

Faulting application name: DrivePool.UI.exe, version: 2.3.6.1562, time stamp: 0x65e61092
Faulting module name: KERNELBASE.dll, version: 10.0.22621.3235, time stamp: 0x2b72307b
Exception code: 0xc000041d

I'm also still getting those notices claiming that I have duplicate disk id's.

Finally, I'm seeing a fair amount of these and have no idea what it means:

The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID
Windows.SecurityCenter.WscDataProtection
 and APPID
Unavailable
 to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

Any help?

[fleggett1]

My apologies for not answering this sooner.  I have been at war with my system for the past several weeks.  Why?  Some background.

I built a brand-new, from scratch AM5 system to replace my old Norco server, as it was showing serious age.  I figured a cutting-edge box would not only stave off obsolescence, but would also play even nicer with my Samsung TV with HDR 10+.   To that end, I got a well-rated ASRock motherboard, a ton of ram, and a Ryzen 9 7900X3D.

It didn't.  To this day, I cannot get a decent HDR signal to the TV.  It looks dim and fugly compared with SDR.  In fact, HDR looks so bad (and SDR so good, relatively speaking) that I wonder if the firmware for the TV has SDR and HDR inverted.

The igpu for the 7900 is effectively a few generations old and doesn't have any practical use beyond simple video out.  Which is fine in my case, as I wasn't planning on playing any games, just watching stuff.  It does play UHDs, which my old system struggled with.  However, the HDR thing has always been a sore spot.

So, what to do?  I figured the logical choice would be to current-up the igpu and AMD had recently released the 8700G, which has an embedded 790M.  Got it in the mail and swapped-out the 7900.

Problems after problems after problems started to occur, the first of which was a corrupted boot which I couldn't revitalize, so I had to reinstall Windows.  I then started to experience random reboots.  The system would run fine for hours, sometimes for as long as a day, but then I would experience three or four rapid reboots.  This beget other problems, like drive disconnects, which drove Drivepool crazy.  Scanner also began reporting bad drives.  I did everything I could, including updating the motherboard BIOS, running everything at defaults, and buying even more QVL-rated memory.

No joy.  I figured my problems HAD to be either the CPU or the motherboard, but gambled on the latter, so I replaced the ASRock with a more expensive MSI.

Incredulously, the problems got even worse.  While the machine ran okay for a few hours, it again started with the reboots and eventually corrupted the boot sector.  I was planning to reinstall Windows anyway, but this time I couldn't even do that and ran afoul of an obscure error during the install process.

It had to be either the CPU, the PSU, or the memory.  The PSU was an expensive 1000W unit and the memory was similarly priced and well-rated.  My hunch was that it had to be the CPU, as all these woes began when I installed the 8700G.  I still had the 7900, so I reinstalled it along with Windows, which this time went without a hitch.

The only thing I can figure is that a got a lemon for a CPU, as I haven't read of similar experiences, so it's going back to Amazon as defective.  The grief I have gone through over these past few weeks has probably aged me a good six months.  It wasn't as bad as the kidney stone I had this past Christmas, but it was getting there.

I have NOT restored the pool yet.  I'm taking things slow and want to make sure the system really is stable before adding the pool back into the equation.  I only did the CPU switch-out last night, so I'm letting the machine run for a few days without it (I have reinstalled DP and Scanner, though).

So, anyway, thanks a bunch for the advice.  I did buy another three Seagate 18 TB Exos, which will replace two cheap shucked drives that I have never 100% trusted, with the third being a completely new addition.  Oh, whenever I add a drive, I do a long format to ensure running confidence.  Takes several hours, but I believe it's worth it in the end.  Scanner will also be monitoring in the background.

So, that's why I've been so silent, as dealing with these issues has completely consumed me.  Originally, I believed the pool was the issue, as the machine seemed to bork whenever something was being written to it, but now I'm fairly certain the CPU was the culprit.  When I start tackling trying to salvage what I can from the pool, I'll post in here.

Wish me luck!