fleggett1

I went into the power settings and disabled USB selective suspend. I also made sure the system wouldn't turn off any disks. I just did this, so it'll take a little time to see if it had any results. I actually had no idea the Sabrent had flashable firmware. I downloaded and applied the one linked in that thread. Again, I just did this a few hours ago, so results (if any) may take a day or two to manifest. Thanks for the link! However, after flashing, I did try to do another chkdsk /b on the Exos, but it did the same thing and got jammed at 5%. I'm doing a "clean all" on it now, but if I'm reading things right, that'll take awhile, so I'll leave it overnight. I'm beginning to think the PSU for the Sabrent might be underpowered, as others in that forum also complained about disk drops, especially when it came to SSDs. I have all 10 bays populated with various Seagate and WD spinners, which could be causing issues. If the flash and power settings don't improve things, I'm thinking of ditching it for a 6-bay Terramaster: https://www.amazon.com/gp/product/B0BZHSK29B/ref=ox_sc_act_title_1?smid=A307CH216CTGMP&psc=1 I don't like the fact that the Terra seems to use old-school drive sleds, but I'll gladly accept that hassle if it means I can get the pool back to 100% (I can settle for only six disks in the meantime). I might even take apart the Sabrent to see if the PSU can be upgraded (probably not, but it's worth looking into). More to come!

I've resisted saying this, but I think there's a problem with the Sabrent. Which, if true, really screws me. I'm beginning to suspect the Sabrent because I tried long formatting a brand-new 18 TB Exos and it also failed. I started the process in disk management, made sure that the percentage was iterating, and went to bed. Got up and nothing was happening and the disk was still showing "raw". So, at some point, the format failed without even generating an error message. I'll also periodically wake up to a disk or two having randomly dropped-out of the pool. I'll reboot the machine and those same disks will magically (re)appear. I'm currently doing a chkdsk /b on the new Exos after doing a quick format in order to assign it a drive letter (which worked). It started-out fine, but is now running at less than a snail's pace, with chkdsk reporting that it won't complete for another 125 hours. Scratch that, now chkdsk is saying 130 hours and it has stubbornly stayed at 5% for the past two hours. I do have another machine I can try long formats on and will do so, but I'm not sure what that'll prove at this point. I've also tried consulting Event Viewer, but so much data gets dumped into it that I can't really pinpoint anything (maybe that's just me being an idiot). I was really, REALLY relying on something like the Sabrent since it seemed to be a Jack-of-all-trades solution to having a bunch a disks without resorting to a server-style case or expensive NAS. If anyone has any suggestions as to a similar device, I'd love to hear it.

What do you guys think about a drive that fails a long format (for unknown reasons), but passes all of Scanner's tests, isn't throwing out SMART errors, and comes up fine when running chkdsk?

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!

Got it resolved by submitting a support ticket. Huzzah!

I'm having the same problem.

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?

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"?

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!

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?

Oh. That's...interesting. Well, at least that's something I can rule out when it comes to pool mysteries, as I thought for sure I had a huge problem after the chkdsk thing. I suppose I could chkdsk the individual disks myself manually, but I expect Scanner does all that periodically and then some (at least, I hope so).

I actually tried several variations of the copy command, like *.* and *?.?* and none of them worked. However, for some cosmically unknown reason, now it's working under cmd with no elevation. I'm 100% serious. I can only surmise that an application had gotten ahold of the directory at the same time I was attempting the copy command and had temporarily made it exclusive, as I haven't rebooted. However, even if that was the case, it doesn't explain why xcopy and Powershell's copy worked. It gets even better, though. I did an admin-level chkdsk in both cmd and powershell on the pool and got this in return: The type of the file system is RAW. CHKDSK is not available for RAW drives. I don't know what the frak is going on. The pool seems to be working just fine and disk management reports that each drive is NTFS'd, but chkdsk thinks the pool isn't formatted? Is the Sabrent enclosure futzing with things in ways DP and Windows can't understand? Do I need to bring in a witch doctor? I suppose another thing to consider is that the pool wasn't created in my current Windows 11 environment, but in my previous Windows 10 one. I'm beginning to fear that I'm gonna have to start things over from scratch, but that's probably going to necessitate getting a second enclosure since this one is full and I just don't have that kind of cash lying around right now.

The pool is healthy and I'm not using any duplication. I haven't run chkdsk, so that's something to try. No hidden files, no long paths, and no weird unicode stuff involved. I am running the pool off of a Sabrent 10-bay enclosure, but I don't see why that would be a factor. I'll run chkdsk when I can get to the pool again. I just want some stability in my life at this point, as I built a new machine with a screaming Ryzen 9 cpu to replace my old Norco and have had all sorts of problems, with this being just another one. No crashes, just strange stuff that isn't really DP or Scanner related (most of it involving the igpu/HDMI).

What in the sam hell does this mean when trying to do a cmd-based copy using a filename mask? "The system cannot find the file specified." This is what I get when trying to do a "copy * [destination]" in a few directories in Windows 11 on my one (and only) Drivepool pool. I can copy the files if I don't use a wildcard, but I've never seen this sort of error and it's got me really, REALLY spooked. All of the files just have the "A" attribute and there aren't any other hidden or system files in these directories. xcopy under cmd works. And the internal copy command in Powershell works, so it's something endemic to vanilla cmd. I'm confuzzled!

gtaus, the Sabrent is a really nice enclosure. Looks to be all-metal and would undoubtedly kill someone if dropped on their head, even empty. Doesn't even need drive sleds, which a lot of server-style enclosures force onto people, like my old Norco (now Secdin). On the expensive side, but the build quality and it only needing the one USB-C port are terrific selling points. Unfortunately, I have no idea regarding drive speeds, as I haven't run any tests. I would guess that it's just as quick as if the drives were directly connected to the motherboard. I've streamed several near-100 GB UHDs and haven't run into any stuttering, which is all I wanted. It sounds like DP is, to put it charitably, "slow" when it comes to drive evacuations. I'm not sure a faster USB connection would help in this regard, as DP seems to have its own game plan when shuffling stuff around. If you have any other questions about the Sabrent, feel free to ask.

BTW, Amazon has the 10-bay version at 10% off rn, making it $540 (before tax). Dunno how long it'll last. If I had the money, I'd get a second during this discount.

Hmmm. I thought I ran another scan shortly after the long formats were complete, but a lot has been going on in my life for the past couple of months and I can't say with 100% certainty that I did so. So, if the bad sectors were remapped as part of the long format and Scanner is now showing them green across the board, would you re-add them back to the pool or get rid of them?

About a month ago, Scanner reported that two of my drives were exhibiting unreadable sector issues. I evacuated and removed them from the pool, but kept them installed intending to do something about the pair "later" (I'm a master procrastinator). Since they remained installed, Scanner could still access them and do surface scans. As such, all this time, the Scanner tray icon has been gold (I think it's gold) indicating continuing drive problems. Until today. I woke up today with the Scanner icon blue. Weird. I initiated a manual scan of both drives and no unreadable sectors were found. I'm more than a little confused. Did the drives automagically fix themselves at some point? Is it possible the onboard drive firmware remapped the bad sectors to good sectors when my back was turned? Do I dare try to use them at this point or should they still be tossed? I should note that I did a long format of the drives shortly after Scanner reported the bad sector issues. I was hoping that might trigger a remapping, but it didn't seem to do anything, as Scanner still reported that both drives had bad sectors after a scan.

They seem to be alright, though I haven't done any formal testing, just eyeballing the speeds given by Windows when doing copies/moves. I can stream UHDs with no problem. I've since assembled a system with native USB-C, which seems to've solved the spin-up issue I mentioned earlier. It's a really nice enclosure that's built like a tank. If/when I run out of bays, I'll probably get another one. It's expensive, but only needing the one USB cable (two if you count power) is REALLY nice. I also haven't seen any temperature issues since converting from the Norco.

I'm just full of questions lately. This might be a dumb question, but what's "safe" to do with files on drives that are in the process of being moved around, like with a (re)balance? I mean, can you just use the pool as normal (reading, writing, deleting, etc.) or should you wait until the rebalance is done to ensure the pool remains 100% intact? Also, does DP "lock" drives that are being (re)balanced or restrict them in some fashion from being used?

Well, I'm using a Sabrent external enclosure - https://sabrent.com/products/ds-uctb - so I dunno what sort of performance hit I'm running into versus if the drives were plugged directly into a motherboard. But if you think several days to evacuate a large drive is reasonable, that's fine, I just wanted to make sure I wasn't seeing a big problem with my setup.

Is it common for an almost-full 16 TB drive evacuation to take several days? I started the process this past Tuesday and it's not going to complete until tomorrow (Friday). The source and target are bog-standard 6 Gb/s drives (WD and Seagate). I haven't done the math, but the time it's taking just seems a little excessive. All drives are in an external Sabrent enclosure.

Hmmm. HMMMM. I think you might be onto something, as the freespace on my drives was spanned across all of them instead of one or two drives having the 800 GB. I don't know how Sonarr (pre)allocates space on the target, but it may not've made any difference given how that 800 GB was spread across the pool. Yeah, it must've been that, as Sonarr was able to resume transfers once I installed the new drive. DP is now rebalancing everything, which looks like it'll take a couple of days to complete. I'm definitely not turning things off until that's done. BTW, the scrollbar in DP isn't working in my installation - I have to use the scrollwheel, instead. It does work in Scanner, though. Thanks for the quick feedback. I would never have thought of that being the answer.

I recently built a new Windows 11 system, as my old 10 box was showing its age, and I'm running into a very strange problem with Sonarr in conjunction with DP. Both Sonarr and DP report 800 GB of free space. This is based on a target pool with a total of 83 TB (soon to be 101 TB, as I just received another drive today). I know weird things can start to happen when a file system approaches zero space, but 800 GB seems like plenty of play. The problem is that Sonarr can't import anything to the pool, as it doesn't think it has the necessary space. These are (relatively) small episodic files at around 7 GB each. I know this because I went through the latest Sonarr log and saw this rather alarming entry: "System.IO.IOException: There is not enough space on the disk." I've done a few Google searches of this error as it relates to Sonarr, but it looks like whatever bug caused this was fixed long ago. I also scanned their Discord to see if this is a new bug, but no one has reported anything. As such, I can only surmise the problem is on DP's end. So, any ideas? Is there some invisible drivespace overhead DP employs to manage pools that isn't reported to the user? I'm not doing any duplication, but even if I were, 800 GB is still 800 GB of presumably usable space. I'm using the latest versions of both DP and Scanner. Thanks in advance.

It's alive, it's alive! ...but with a caveat. My system is so old that it doesn't have a native USB-C port, so I had to buy an internal card with several that's natively recognized by Windows 10/11. I don't know if that affects anything, but the caveat is that it takes the Sabrent a few seconds after the desktop appears to fully spin-up all the drives. This screws with one application I'm running in a fairly minor way, as the pool isn't initialized at that point, and is work-aroundable. Scanner is...interesting. Every drive on the main menu shows-up as an "ASMT ASM235CM SCSI Disk Device", but if you look at the disk information, it's all good, with the correct manufacturer, model, serial, etc. SMART data also appears to be coming through. This same label also appears in Device Manager for every drive. If you assign a manual name, though, that label appears in Disk Management (I've labeled all mine). The "labeled" name also appears in Drivepool. I guess it doesn't particularly matter, but maybe you can try to have the "labeled name" display in Scanner in a future version, as that would be much handier. Oh, something else that's neat - you don't have to do the 3.3V hack with the Sabrent, which is something I had to do with the Norco. This is doubly good, as you then don't have yellow tape potentially gunking-up the SATA connector. Apart from the spin-up delay and the device names, everything seems good. The fans are super-quiet, so I don't know why people were complaining about that. The one bad thing is that it came with a ridiculously short power cord, so I had to dig-up one of my own. Anyone have any questions?