fleggett1

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?

Har har, you're assuming I have drives to spare. Remember that I'm taking a chance on the Sabrent because I suspect my Norco has been cooking drives and I lost a bunch last year. And there's a current drive that's throwing intermittent SMART errors (cheeky bugger). I ordered it last night. Should be here this weekend. I just hope the fans don't chase me out of my home, as I hear they're on the loudish side.

Okay, Christopher, I'm gonna get it. If all goes according to plan, I'll post in here. If something goes wrong, I'll also post in here, but I might also wind-up haunting your dreams. Wish me luck!

I'm on the cusp of purchasing this thingamajig, probably in the next 2-3 days: https://sabrent.com/products/ds-uctb I'll be attaching it via a USB-C cable. I just need to know if there's anything I need to do wrt Drivepool before removing them from my Norco. From what I understand, all the pooling information is stored on the pooled drives themselves and the order in which they're placed in drive bays don't matter, but I just want to dot all my T's and cross all my I's. I won't be doing anything crazy, like RAID or unRAID, just messing with DP (and Scanner). Please let me know before I put shotgun holes in my credit card, as the Sabrent ain't cheap. Thanks muchly in advance!

Urgghh. I need Sherlock Holmes to figure out what the hell is going on with my system. Right now, DP is going through an absolutely agonizing rebalancing process that, by my estimation, will take at least 24 more hours to complete. I don't know what spurred this, as it looks like it's evacuating an entire drive for no discernible reason. It's a good thing I don't drink. Anyway, thanks for the quick reply. I'm ASSuming that, when the filesystem error occurred, that's when Windows took the drive offline, which caused it to drop out of the pool. I'd still like to know what, exactly, happened to cause the error in the first place, but that's probably buried in some arcane unreadable logfile in a directory that's twenty levels deep. I'm 99.9999% convinced I just need to shuck the entire system and start from scratch. Save what drives look to be salvageable and throw some serious money at a new platform. My system is so ancient that I can't even upgrade to Windows 11 (well, at least not without some Rufus-style hacks).

Well, some more info. It's now at the brink of dawn here and I can't sleep, so I'm back at the computer. Scanner completed the scan on that dropped-out drive. Thinking I might be able to salvage the drive via a power cycle, I rebooted the system a second time and, this time, Windows found and fixed whatever filesystem problem it had encountered earlier. Why it didn't do that during the first reboot is anyone's guess. I have no idea if any actual files were affected nor, for that matter, which drive was repaired since Windows is stubborn about releasing such obviously critical information to the user. I know in the old manual chkdsk days that recovered files would be saved in a FOUND.000 directory, but I don't see anything like that. Maybe that's a good thing, but all this weirdness with intermittent SMART errors and out-of-the-blue filesystem problems is making me go more than a little batty. In any event, after the second reboot, the drive reappeared in the pool, thank the Gods. I don't know why the drive dropped in the first place and I suspect I'll never know, but I figured a follow-up was in order.

This question might already be answered, but I'm on the verge of a nervous breakdown with this system and could use some help along with a hefty bit of hand-holding. Had to restart the system today because Windows claimed there was a filesystem error that needed fixing. I have NO idea what drive it was referring to and, to make matters even more mysterious, no check happened upon reboot. However, when the system did reboot, Drivepool said that a drive was missing and no longer part of my pool. A big drive. An important drive. A drive storing terabytes of data. Upon looking at Drivepool, I identified the drive that had dropped out and then looked at what Scanner was doing. It was scanning the disk and still is given its size. The thing is, Scanner isn't reporting anything wrong with it. It can read the drive info, is reporting the sector map, there are no SMART warnings, and everything looks hunky-dory. So, has Scanner put the drive into some sort of "It's mine and no one else can touch it!" mode? Windows' own disk management isn't even reading the drive correctly, which has me REALLY concerned. The scan is probably going to take all night to complete and I don't want to abort it in case it really does need a complete read. So...help?

Oooohhhh, you're talking about a card with eSATA ports. Unfortunately, that's something way above my pay grade, as I've never fiddled with eSATA stuff. Maybe Chris might know something. Perhaps try using whatever driver Server 2022 pulls down for it instead of the Tempo driver?

No, I'm still a way aways from getting the Sabrent (if I get it at all). Your situation sounds really different, though. You're running a Sonnet what? Are you using an external enclosure of some sort?

Ugh, you're killing me, man, just killing me. I really had my heart set on that thing. SUPPOSEDLY, the enclosure presents drives to Windows as if they were directly connected to an HBA and/or the motherboard itself. I don't think it even requires additional drivers. I don't know what sort of demon sacrifices it's performing in order to do that over a simple USB cable, but if it's true, you'd still have doubts? I won't be using it in a (software) RAID configuration. JBoD is the most my arthritic brain can handle. RAID is like forcing me to use a third pedal in my automatic car.

Well, it just happened again and disappeared just as quick. Arrggh. I guess I will have to setup email notifications after all. Are these incidents logged ANYWHERE that's human readable?

Does DP/Scanner work with practically any external enclosure, particularly as it relates to SMART reporting? I suspect my aging Norco is in its twilight and I'm probably going to have to redo the entire system in the next month or so. I have 10 drives with the intent of getting more when prices are more favorable, but ran into the issue of finding a case that has the room along with an associated PSU with enough power leads (I don't want to resort to one of those cables with five power connectors that could cause a house fire). To that end, I was eyeing this cute little beast: https://sabrent.com/products/ds-uctb (The 10-bay version.) Should this work will full pooling and reporting functionality? If not, does anyone have any suggestions for an alternative that's NOT a rackmount chassis? Thanks in advance!

I think I'm gonna call the tray icon from now on the "Gold Shield of Worry" (GSoW). Kinda goes along with Blue Screen of Death and Red Ring of Death, only with less Death. Thanks, Christopher, for the likely answer. Still hasn't occurred again (thank God). I've already lost a bunch of drives over 2022 and didn't need this on the very first damn week of 2023. VapechiK, it's good to share misery, even if it is, y'know, misery. I'm actually on the verge of swapping-out my entire system, as I suspect my creaky Norco has been slow-roasting my drives for the better part of five years. Then again, I did modify it to support an AIO and probably blocked some critical airflow in the process. Never let me borrow a dremel.

Well, I found some logs in \ProgramData\StableBit Scanner\Service\Logs and looked at all of them, but didn't see anything that indicated a drive was homiciding itself. I used search terms like "predict", "heat", "failure", and "imminent", but no joy. I also stumbled across the \ProgramData\StableBit Scanner\Service\ErrorReports directory, but all the files are encrypted, so that was a bust. Can I chalk this up to poltergeists or some other spooky late Halloween shenanigans? I looked at the drive again in Scanner and it reports green across the board.

I'm running Windows 10 using the recently updated versions of Scanner and Drivepool. About an hour ago, I got the dreaded gold shield in the tray stating that a drive was going bad and was predicted to completely fail within 24 hours. Wonderful. So, I open Scanner, look at the drive, and everything looks normal. Not a single SMART value out of line. No bad sectors reported. Drive reports as healthy. I'm confuzzled and a little weirded out. What could cause this? Is this drive really going bad or was it some transient issue that has since self-corrected? I no longer see the shield icon, so there's that (at least). Does Scanner keep a logfile around somewhere about these (presumably dire) events that has more information?

Wow, well, that's good to know. Thing is, though, that drives outside of the pool were also affected. Were they also changed by Drivepool (or Scanner)?

Does Drivepool and/or Scanner mess with permissions? I had a drive fail recently and removed it from the pool, but suspiciously at around the same time, all my files on said pool was "reassigned" to another user. I had to go into safe mode to reclaim read/write permissions. When Drivepool does a rebalancing after a drive removal, does it do anything with the security settings of files & folders?

Sorry for doing yet another thread necro, but I'm having "one of those days". Got up today with Scanner reporting a smart error on one of my drives. Fortunately, it turned out to be an older 4 TB Red, which I can do without. I had already activated the plugin to automatically evacuate files in the event of a smart error. Which it SEEMS to've done, but now I'm not sure. I managed to pull a directory listing of the failing drive and all I saw were directories, but no actual files. Is that normal? Should I be worried that some of the actual files might not've made it to the other drives in my pool? The other odd issue which makes me wonder if the drive was truly and fully evacuated is that qBitorrent is now reporting weird i/o errors for some files. I've looked in my torrent directory and everything looks like it's there, so why would qBt be reporting such errors? My torrent directory is part of the pool. BTW, I've tried manually removing the drive with all checkboxes unchecked and it gets to the 3.2% mark and fails. As always, thanks in advance.

That's excellent to hear, as I was thinking of replacing my two stone-age Supermicro HBAs: https://www.supermicro.com/en/products/accessories/addon/AOC-SASLP-MV8.php With this Broadcom/LSI controller since it supports 16 ports on just the one card: https://www.broadcom.com/products/storage/host-bus-adapters/sas-nvme-9500-16i Any problems I might run into?

Outstanding. Thanks a bunch for the quick reply.

Sorry for the threadnecro, but due to some Best Buy sales, I was able to replace the four low-capacity drives with four 16TB monsters. However, because of the way my enclosure is put together (insufficient airflow), it looks like I'm going to have to separate them due to heat issues (as reported by Scanner). As such, I'll be repositioning these drives in my bays so that they're not immediately next to any other drives (they're low-capacity, so I'll probably just pull and retire them). This isn't gonna screw anything up, will it? Is Drivepool's drive identification bay-dependent or independent? I would think the latter, but I know some RAID configurations can get scrambled if drives aren't in their initially installed bays. I'm not doing RAID, but just want to make 100% sure. EDIT - I should've noted that I've already added these drives to the pool. If I need to evacuate them before the reposition, I can do that. Thanks in advance.