BSOD when removing last drive & unable to move files without all drives in original pool.

[PocketDemon]

As the slightly lengthy title describes, there's 2 notable issues which weren't there the last time that I needed to do something like this - on an unknown previous build.

Well, it's only spasmodically that I need to do something major with the pools that's better done by creating new ones from scratch.

 

So firstly, whilst removing other drives from a pool works fine, removing the final one *always* causes a BSOD - this occurring on 2 different machines & with the drives on Intel, Marvell & a LSI controller; as well as if the final drive's connected via USB... ...& irrespective of whether there's any user data on the last drive in the pool.

(it can be worked around by either booting into safe mode & deleting the partition in Computer Management / or connecting to a machine without DP installed - however these aren't exactly user friendly)

&, secondly, if any drive is missing from the pool, it's making all of the files/folders read only - again on both machines - which, given that there are finite SATA/SAS ports (& a USB dock), means that the new pool(s) cannot be made with all of the drives that 'should' be there; leading to time wasting with the new pool having to move data around again once it's possible to add the remaining drives.

(obviously the data can be 'recovered' from the RO drives, using something like R-Studio, however this really isn't a great solution - as 'if' instead the issue was a failed drive & someone couldn't afford to replace it instantly then this significantly limits the ability to use the data)

 

Okay, so having moved most of the data around - 5 new pools created / 4 of the new pools having all of the data on / & 4 of the 5 pools removed - then any solution probably won't be in time to help...

...so it's simply reporting that these issues have been a b nuisance & they really need sorting.

Oh, & (obviously) using v2.2.0.906 - the 64bit Windows version.

[Christopher (Drashna)]

Unfortunately, I can't reproduce this behavior, at all. 
If you could, upload the crash dump: 
http://wiki.covecube.com/System_Crashes

 

14 hours ago, PocketDemon said:

secondly, if any drive is missing from the pool, it's making all of the files/folders read only

Yes, this is normal, and expected.  This happens so that duplicated data doesn't get out of sync, causing duplication issues. 
And even if you're not using duplication, there are some settings stored on the pool that is (the .covefs folder, namely).  

Reconnecting the drives, or removing the missing drives will fix this. 

 

 

[PocketDemon]

38 minutes ago, Christopher (Drashna) said:

Unfortunately, I can't reproduce this behavior, at all. 
If you could, upload the crash dump: 
http://wiki.covecube.com/System_Crashes

 

Yes, this is normal, and expected.  This happens so that duplicated data doesn't get out of sync, causing duplication issues. 
And even if you're not using duplication, there are some settings stored on the pool that is (the .covefs folder, namely).  

Reconnecting the drives, or removing the missing drives will fix this. 

 

 

Right, there's no memory.dmp file, despite it being set up as shown, but the minidump files - which are correctly (as this was the BSOD message) showing that there was a PNP_DETECTED_FATAL_ERROR - are reporting a 0x000000ca Bug Check Code in partmgr.sys each & every time; which then leads to an error in ntoskrnl.exe...

...&, as said, this occurred every time when removing the last drive in a pool on the 2 different systems - &, including the USB dock, 4 different controllers.

Oh, & as I possibly wasn't entirely clear, I was also blocked from deleting the last drive in Computer Management, without going into safe mode - hence going into safe mode.

 

As to the 2nd part, it was largely just a comment - but it's a really frustrating change, as it significantly slows down the process of replacing a pool with larger drives. Well previously it's always been possible to set up a few drives for the new pool & copy data from some of the drives from the old pool... ...which, with half decent controllers, is vastly more efficient than doing them one by one d.t. being forced to have all of the drives in the old pool connected (with one being shifted to the USB dock).

[Christopher (Drashna)]

By chance, are there any minidumps on the system (C:\Windows\minidump, IIRC)?  If so, uploading those may help. 

Also, in case it helps, the dpcmd's ignore-poolpart command may work here, too. 

 

2 hours ago, PocketDemon said:

As to the 2nd part, it was largely just a comment - but it's a really frustrating change, as it significantly slows down the process of replacing a pool with larger drives. Well previously it's always been possible to set up a few drives for the new pool & copy data from some of the drives from the old pool... ...which, with half decent controllers, is vastly more efficient than doing them one by one d.t. being forced to have all of the drives in the old pool connected (with one being shifted to the USB dock).

I understand that, but I did want to explain why, so you had a better understanding of why the software does that. 

As for replacing the drives, you should be able to just remove them.  We've made that feature MUCH better in this version.  The pool shouldn't go read only, actually.  And if you use the "Duplicate Data later" it should go much faster .... if you had duplicates. 

There are ways around the issue, but yeah, I can understand the frustration. 

[PocketDemon]

Okay, so these are a couple of minidumps from one of the machines - Minidump.rar 

 

As to the other bit of it, d.t. the controller not passing SMART commands on then I wasn't 100% sure which drive was faulty on the other machine - so easier to kill the pool & test them independently... ...well, in theory at least.

& separately I could obviously see that you'd made a change &, with the explanation, can understand the reason why you've decided to do so - but, whilst this may be positive for some people, if no one comments that they're finding that there's significant downsides then there's no chance that you might either revert it to the way it was historically OR create an option for enabling/disabling the new behaviour in the menus.

Anyway, no point in saying any more on that score, as reiterating further won't help either which way.

[Christopher (Drashna)]

You're running SSDKeeper, right?  Or DisKeeper? 

If so, that appears to be what is causing the crash.  
From the looks of it, it caches writes to the drives, ... which may be the problem here.  The disk unmounts and the software doesn't know what to do.