p3x-749
-
Posts
115 -
Joined
-
Last visited
-
Days Won
6
Posts posted by p3x-749
-
-
...just to chime in here...remember that expanders have firmware too.
I am running 1x M1015 + 1x RES2SV240 in my 24bay rig for 5+ years now....I remember that there was a firmware update for my expander that improved stability with S-ATA drives (which is the standard usecase for the majority of the semi-pro users here, I think).
Upgrading the firmware could be done with the same utility as for the HBA, as far as I remember...instructions were in the firmware readme
Edit: here's a linbk for a howto: https://lime-technology.com/forums/topic/24075-solved-flashing-firmware-to-an-intel-res2xxxxx-expander-with-your-9211-8i-hba/?tab=comments#comment-218471
regards,
Fred
- Christopher (Drashna) and jmone
-
1
-
1
-
Hi,
...don't know if my problem is related to this, but it looks similar in some way:
...I just noticed two "problems" after switching from 2.2.x beta to 2.2.0.903 (and .906 afterwards).
My system contains 3x 8TB Archive disks and 1x 2TB "SSD".
In the SSD plugin, the 2TB is clearly marked as SSD and not as "Archive".
When bringing in new files to the pool, these land on the 2TB disk.
Problem 1: I now noticed, that the never got moved away and DP even start to use the Disk to duplicate them.
Problem 2: When letting the box sit/idle forever (+24hrs), DP tells me that it is rebalacing, when I leave, but never ever achieves anything of that when I return 24hrs later.
...what is going wrong here?
regards,
Fred
-
...AFAIR, when I re-installed windows, I had to add the disks to the pool manually...re-measurement started only after I added the first disk....but this was when Win10 hit GA and I moved from 8.1P to 10.
-
I understand that for DP to work properly with the pool, it needs to gather the data, i.e. by means of a remeasure.
What I don't understand is, that it started to do this, after a fresh install by its own.
I remember when re-installing windows or moving the disks (and the licence afterwards) to a new machine, when I installed DP, it did not remeasure automatically.although the disks were present upon install.
Hence my conclusion that the other method was not a clean/fresh install.
-
I may be just tired, but I'm not sure what you mean here.
But the guide posted is to completely remove the software. It goes over how to remove everything (short of shortcuts). It's there, because every once in awhile, we do see problems with the uninstallation process. Or in a few cases, a botched upgrade that left it on a "bad" state (mismatched files)
Well, my assumption was, that after a complete remove, why does DP automatically start a remeasure.....only if there are some remains (the remove was not complete, hence).
The fact that there are pool-part folders on some drives ?....I think this is not enough info to justify a remeasure (importing the drives into the pool before that, also silently), isn't it?
After a fresh install, I think the user should decide what drives to import, shouldn't he/she?
regards,
Fred
-
Sorry about this!
I'd forgotten about the ticket and didn't update it.
Unfortunately, the traces don't appear to be from either version listed (691 or 789), so it makes things problematic, at best.
If you could, do this:
http://wiki.covecube.com/StableBit_DrivePool_Q3017479
And then install this version:
http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.866_x64_BETA.exe
And could you confirm the OS version?
And re-grab the logs?
Errrmmmh...I followed your procedures and after the install of the newest beta DP instantly started to re-measure (so no chance for activating logs).
Is it supposed to do that, as I thought I purged everything from the DP software on my system?
Anyway...I am now down to 29GB, compared to 6.5TB (on 829beta).
Looks like your install procedure is having some unwanted shortcuts and leaves remains of the old version?
Thanks for your support...I'll consider that "fixed" or cured
regards,
Fred
-
Thanks for your fast response.
Uhmm...this is now several weeks old, but if I read my summary above, I must have been running 802beta when collecting the logs...the issue started with an older version and I updated in order to get rid of it.
I am on an ever newer beta atm.
....anyway, I think it'll be best to re-install and re-gather the logs.
I'll report back, as soon as I prepared them.
-
Hmmm...just let me chime in and kindly ask about the state of my similar issue, here? -> http://community.covecube.com/index.php?/topic/3068-files-not-accessible-via-pool-but-still-there-in-pool-part-folders/&do=findComment&comment=21235
I am very busy ATM and not having access to the box often...but the problem still persists...lots, lots of TBs in unidentified "other" category.
-
Thanks Christopher for the response.
I actually don't know if this is wrong...so far I only experienced the "smart" way of moving files, even with DP.
Yes, I totally understand what might have happened, because DP is physically build out of real disks, each with its own filesystem.
However, I was under the assumption, that DP has a"virtual" Filesystem layered on top, so as long as I move files between folders inside the pool, the operation would take place inside the virtual layer only and the smart way would always kick in hence.
...OK, maybe I had a too simple model in my head
-
OK, this is strange, maybe someone can clarify a bit...
I did a file move (using explorer, doing cut&paste) of a bunch of files.
The move was from one folder into another, inside the pool drive.
-> that was an instantaneous action , as expected.
A couple of minutes later, I moved the same files into another folder of the pool
-> this time, the whole bunch of 90+MBytes gets actually copied
...both actions were done locally, only working with the pool drive.
What is going on here, I don't understand that kind of behavior ?
regards,
Fred
-
Thanks you Christopher!
I did run the troubleshooter and it reported the upload successfully.
regards,
Fred
-
Thanks for your reply, Christopher and for your patience in looking into this.
I really appreciate it.
Ah, yes...here's a brief summary of the history of things:
- pool running on 2.2.0.691beta with 3x 8TB disks and 1x 2TB disk as "SSD".
- the "other" data reported on the pool was approx 400MB, which I didn't care about
- However the balance between disk usage was very uneven, so I decided to remove the SDD and deploy the "Disk Space Equalizer" plugin on the pool.
- had problem removing the SSD disk, so upgraded to 2.2.0.798
- removing SSD disk and re-balancing the disk usage went fine with that version, however this was when both problems, mentioned in this thread started to appear and being persistent over several reboots and pool re-measurement runs.
- the problem with files shown in the explorer view of the pool but reporting as non-existent when accessing them suddenly disappeared.
- the problem with too much data of type "other" remained....reporting approx 5.7TB at that time with version .798beta
- assuming that a newer beta would be able to gather better log-information, I upgraded to .802beta
- the other data reported, simply grew to 8.36TB with that version....staying there for several reboots and several re-measuring attempts.
- this is the state where I ran WinDirStat and took the screenshot, reporting 8.36TB of data
- from the other thread, reporting a similar issue, I ran the command "dpcmd remeasure-pool <DP drive letter> with elevated rights, as suggested there from @jsta
- after that, the pool reported 2.64TB of other data and I added a screenshot of that to the same photo gallery, too
OK,...I'll gather the logs now and upload them!
EDIT: ...done!...disable logging when the first disk has finished wasn't so easy, so I had to re-measure twice...hope this is not an issue.
FWIW: After the first run, the result of "other" data dropped to 1.7TB and stayed there for the second run.
regards,
Fred
-
...really don't know if we are in the same situation here.
At least the way both problems look alike made me post in this thread...but Christopher thinks that this is not the case.
EDIT: running that elevated command brought down the "other" from +8TB to 2.7TB now...still way too much. See -> http://imgur.com/a/rI0oH
-
Thank Christopher for your reply and your support.
I did run WinDirStat (as Admin) on the pooled disks -> http://imgur.com/a/rI0oH
There is nothing in the individual recycle bin(s) and +95% of all data on the disks is media data....at least, that is what I see.
The disks are disabled from holding restore-points (if that is what you were referring to as versions/shadow copies ?!?) as well.
I am also not using deduplication willingly (don't know how to configure it...running Win10-Pro which is a desktop OS...does it have that feature at all?)
As for your request for the logs...what do you mean by "Disable logging as soon as it hits the "other" data on the drive" ??
When I start re-measuring, DP seems to start with only one disk (showing progress in the UI "bars") but at first, there everything is of type "other" on all disks...that's the situation where DP seems to start it re-measurement from
Can you elaborate on how to do what you suggested, as this confuses me...don't want to bother your time with sending unnecessarily log-files along, please?
TIA,
Fred
-
...I'll second that.
Without having touched a single file, my Pool changed the measurement dramatically as well, see here: http://community.covecube.com/index.php?/topic/3068-files-not-accessible-via-pool-but-still-there-in-pool-part-folders/&do=findComment&comment=21178
-
run a disk check on the affected disks (chkdsk /f), and then remeasure the pool once its done.
As for the issue .... those are LITERALLY the worst. Consistent issues are nice, because they're easy to reproduce and address. These sort of issues .... are very hard to troubleshoot.
...all disks passed the chkdsk process without problems...remeasure of the pool did not change a thing, same result....5.8TB still reported as "other".
Edit1: ...moved to 2.2.0.802_BETA (64Bit)...after remeasure now 8.9TB are reported as "other"
Is it feasible to go back a DP revision (I installed .798beta because this fixed a problem with removing a good disk).
EDIT2: maybe this part of the problem is related to what is being discussed here: http://community.covecube.com/index.php?/topic/3044-other-data-but-shouldnt-be/&do=findComment&comment=21175 ??
-
Well, it did say something like "file does not exist" (sorry, not on the english version of Win10).
And yes, as already stated, the files were in the individual pool-part folder(s) and were accessible just fine...only the pool showed that issue.
OK, ...back for the weekend and brought up the box to test what you suggested....the problem has disappeared
...don't know what to say.However, 5.8TB of my 12TB, sitting on 3x 8GB disks, are now shown as "other" (before the "issue" there were less that 1GB show as other).
Checked the native disks, all files are in the pool-part folder(s).
...what can I do about that?
regards,
Fred
-
I am almost sure, I am missing something here, but since DP is working so flawlessly in general, I cannot recall if what I see is a problem from my side of the keyboard or from DP.
Did an upgrade to 2.2.0.798 BETA to solve a problem with being unable to temporarily remove a good drive from the pool, as stated elsewhere here in the forums.
After that, DP (re-)gathered all data and everything looked well.
Now, a couple of days and reboots later, I am seeing the effect, that some files are not accessible from the pool.
Explorer sees them, but opening gives an Error, that the file is not there.
I normally don't use the native drives, just the pool...after enabling the disks and accessing the pool-part folders directly, the files are there and can be accessed, as expected.
However, the problem with accessing the files via the Pool persists.
I issued the command to re-gather the pool information manually, several times to no avail.
Since when I enabled the native disks with drive letters, a large part is now shown as "other" instead of duplicated/non-duplicated...don't know if this is related though.
...what is the recommended procedure to get DP up to the correct state and functioning again?
I am on Win10-Pro 64bit BTW.
TIA,
Fred
-
....not with the speed performance of a teamed link, in a way you've had in mind.
However, with a spinning disk, a sustained performance of 120MBytes/sec and above is only achievable with striped reading (for drivepool, AFAIK striped writing does not exist).
So, the typical limit here is the drive speed, not the link speed, isn't it.
-
...a single client connection will not benefit from a teamed link...only multiple concurrent clients will, i.e. a 2xGbit teamed link will give each client up to a full 1xGbit link at the same time
-
...ok, Win10-Pro fails to upgrade from 1511 to 1607 on my system...I'd gather Stablebit Drivers are not the issue then.
Found some people mention in the win support forums, that non genuine drivers are suspect to cause this effect.
Missed this, apparently.
I upgraded to 1607 with drivePool installed without any problems. Our drivers are signed, so there shouldn't be any issues with them.
Chances are, that the failure occurred elsewhere, and yay for microsoft logging......
If you are having issues, uninstall our software, reboot, and then try upgrading.
Once it's upgraded (or if it fails), then reinstall our software. it should retain the settings and pool info, without any issues.
My rig runs on a server - X8SIL-F (Socket 1356) with a PCIe x1 ATI HD-6450 ... and ATI flagged them as legacy now.
I suspect these drivers to be the issue...I am now on a GT-520 (which never worked in this rig prior to Win10)...being in the process of upgrading to 1607 now....we'll see.
If this fails, I'll try your method....another cause might be the LSI-2008 card and drivers....these I will try/touch last.
Edit: update fails with GT520, too....I now de-installed StableBit Scannner and DrivePool ... we'll see.
Edit2: OK, after I striped the rig from literally everything, the upgrade finally went through after I pulled the USB connection to my UPS :-(
-
Anyone install the Anniversay Update yet?
Yup, and no issues.
...ok, Win10-Pro fails to upgrade from 1511 to 1607 on my system...I'd gather Stablebit Drivers are not the issue then.
Found some people mention in the win support forums, that non genuine drivers are suspect to cause this effect.
-
That is because the "/scan" command actually skips a number of checks. And yes, I've fallen victim to this myself.
You need to omit the "/scan" command and just use /f (or /r, if you want a more thorough check). In this case, it should detect that the "Volume Bitmap is incorrect" (or similar) and fix the issue.
Thanks for the fast response.
Well, as this is my system volume, a chkdsk /f and /r is deferred upon the next restart.
I've done that already (with /f only) with no effect....will redo with /r and report back.
However, I don't ave access to the system console output of that early booting stage...I am running a server board with IPMI and an extra GPU card for desktop...IPMI GPU is deactived hence... the system boots basically headless.
Edit: the deferred run of "chkdsk c: /f /r " seems to have fixed it...re-scanned the FS with scanner and it reports as being healthy now.
-
...after upgrading from Win8.1pro to Win10pro today (did a clean install and installed SB-Scanner beta), I am hitting the same problem with my C-Drive (toshiba enterprise SSD).
The log-file reports problems, while a manually performed "chkdsk c: /scan" reports that everything is OK.
...uploading the service-zip file now.
Q: 2 x M1015 or 1 x M1015 + RES2CV360?
in Hardware
Posted
...I'd try the tools from intel to check the FW version of the expander.
Maybe this would give away some more info about the inner specs and if another FW would work.
At least from the naming it looks like an Intel or similar one...