Jump to content

Mick Mickle

Members
  • Posts

    86
  • Joined

  • Last visited

  • Days Won

    3

Mick Mickle last won the day on November 29 2018

Mick Mickle had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Las Cruces, NM

Recent Profile Visitors

1667 profile views

Mick Mickle's Achievements

Advanced Member

Advanced Member (3/3)

10

Reputation

  1. Yeah, I figured as much. Thought you'd like to know the latest challenge, though. 🙂
  2. (Added from the Scanner General Forum, since the Norton flag is primarily on DrivePool.) FYI, Norton has the download website for either Scanner or DrivePool - I don't remember which - flagged as malicious. I did give a quick "Safe" review for it at the Norton "full report" website tonight. (Hopefully, it wasn't hacked.) You probably want to dispute the warning. Alao, some more "community reviews" besides my one review on Norton would be helpful for the software and website reputation. Also, I noticed that StableBit.DrivePool_2.3.2.1493_x64_Release was missing from my downloads folder, so I found that Norton 360 had quarantined it - probably just too new. No issues at all at VirusTotal (even from Symantec).
  3. FYI, Norton has the download website for either Scanner or DrivePool - I don't remember which - flagged as malicious. I did give a quick "Safe" review for it at the Norton "full report" website tonight. (Hopefully, it wasn't hacked.) You probably want to dispute the warning. Also, I noticed that StableBit.DrivePool_2.3.2.1493_x64_Release was missing from my downloads folder, so I found that Norton 360 had quarantined it - probably just too new. No issues at all at VirusTotal (even from Symantec).
  4. Some honorable mention for Scanner in the comments of this new article: https://lifehacker.com/how-to-check-if-your-hard-drive-is-failing-1835065626
  5. It makes a lot of sense to point to 3216 as the sole cause, and the constant rewriting of the Diskid files may be partly to blame in this case, but this is why I think some other factor is involved here: 1. The manual settings backup I made before upgrading didn't restore the custom names for three disks under 3246. (Perhaps the frequent Diskid file writing resulted in corrupt data written to the backup file also?) 2. On the two machines that experienced lost settings after the 3246 upgrade, I uninstalled 3246 and reinstalled 3216 after my post above: Voila! All the settings were back just as before the upgrades. (If the Diskid files had been corrupted, I don't think the reinstallation of 3216 would've brought back correct settings.) (I don't mean to minimize the problem you identified earlier about 3216's frequent writing to Diskid files and the corrupt state they may be left in. That would seem to be a valid cause of lost settings sometimes.)
  6. I upgraded from 3216 to 3246 Beta on two machines. On my WS2012R2E VM, all the settings persisted through the upgrade on 3246, but on my laptop, Scanner lost the settings (disk names, last scanned date). I restored the settings from the last backup made on March 16, but the last scanned time is never -- I guess because March 16 is more than the 30 days I have set for scan interval. I think this is another example of why automatic periodic backups would be a good feature. Edit: I upgraded from 3216 to 3246 on a third machine, WS2012R2, with mixed settings experience. Seven disks kept their custom names and three disks lost all settings. However, for some of the seven disks that kept their names, "Last Scan" data was incorrect, e.g., 286 days when it was actually last scanned within 30 days. Restoring a settings backup made on April 19 didn't change anything.
  7. Thanks, @Wiidesire! Your discovery looks like it might solve the this CDIDW (constant Diskid write) root problem for a number of threads, including the ones I've enumerated below. A useful new Scanner feature, now that the program has effective settings backup and restore, would be automatic backups, for example, weekly. That way, a backup that would more accurately reflect the scanned state of drives might exist when needed. (Manual backups are less likely to have been made within the last scheduled scan window; thus, even though disk names and other settings can be restored, scan history may be older causing new scans of all disks.) https://community.covecube.com/index.php?/topic/3831-scanner-lost-all-data/ https://community.covecube.com/index.php?/topic/4099-stablebit-scanner-loses-all-settings-on-unexpected-shutdowns/ https://community.covecube.com/index.php?/topic/4265-scanner-2543216-upgrade-loses-my-setups/ https://community.covecube.com/index.php?/topic/3707-bug-prior-scan-data-and-settings-not-preserved-on-update/ 
  8. Thanks, @Wiidesire! Your discovery looks like it might solve the root problem for a number of threads, including the ones I've enumerated below, where I've added a duplicate of this post to help close the loop. According to Christopher, Beta version 2.5.4.3246 addresses and fixed this CDIDW (constant Diskid write) issue by increasing the interval from once every second, allowing shutdowns and upgrades with low risk of corrupting the Diskid files and losing scanning history. A useful new Scanner feature, now that the program has effective settings backup and restore, would be automatic backups, for example, weekly. That way, a backup that would more accurately reflect the scanned state of drives might exist when needed. (Manual backups are less likely to have been made within the last scheduled scan window; thus, even though disk names and other settings can be restored, scan history may be older causing new scans of all disks.) https://community.covecube.com/index.php?/topic/3831-scanner-lost-all-data/ https://community.covecube.com/index.php?/topic/4099-stablebit-scanner-loses-all-settings-on-unexpected-shutdowns/ https://community.covecube.com/index.php?/topic/4265-scanner-2543216-upgrade-loses-my-setups/ https://community.covecube.com/index.php?/topic/3707-bug-prior-scan-data-and-settings-not-preserved-on-update/ 
  9. Thanks, @Wiidesire! Your discovery looks like it might solve the root problem for a number of threads, including the ones I've enumerated below, where I've added a duplicate of this post to help close the loop. According to Christopher, Beta version 2.5.4.3246 addresses and fixed this CDIDW (constant Diskid write) issue by increasing the interval from once every second, allowing shutdowns and upgrades with low risk of corrupting the Diskid files and losing scanning history. A useful new Scanner feature, now that the program has effective settings backup and restore, would be automatic backups, for example, weekly. That way, a backup that would more accurately reflect the scanned state of drives might exist when needed. (Manual backups are less likely to have been made within the last scheduled scan window; thus, even though disk names and other settings can be restored, scan history may be older causing new scans of all disks.) https://community.covecube.com/index.php?/topic/3831-scanner-lost-all-data/ https://community.covecube.com/index.php?/topic/4099-stablebit-scanner-loses-all-settings-on-unexpected-shutdowns/ https://community.covecube.com/index.php?/topic/4265-scanner-2543216-upgrade-loses-my-setups/ https://community.covecube.com/index.php?/topic/3707-bug-prior-scan-data-and-settings-not-preserved-on-update/ 
  10. Thanks, @Wiidesire! Your discovery looks like it might solve the root problem for a number of threads, including the ones I've enumerated below, where I've added a duplicate of this post to help close the loop. According to Christopher, Beta version 2.5.4.3246 addresses and fixed this CDIDW (constant Diskid write) issue by increasing the interval from once every second, allowing shutdowns and upgrades with low risk of corrupting the Diskid files and losing scanning history. A useful new Scanner feature, now that the program has effective settings backup and restore, would be automatic backups, for example, weekly. That way, a backup that would more accurately reflect the scanned state of drives might exist when needed. (Manual backups are less likely to have been made within the last scheduled scan window; thus, even though disk names and other settings can be restored, scan history may be older causing new scans of all disks.) https://community.covecube.com/index.php?/topic/3831-scanner-lost-all-data/ https://community.covecube.com/index.php?/topic/4099-stablebit-scanner-loses-all-settings-on-unexpected-shutdowns/ https://community.covecube.com/index.php?/topic/4265-scanner-2543216-upgrade-loses-my-setups/ https://community.covecube.com/index.php?/topic/3707-bug-prior-scan-data-and-settings-not-preserved-on-update/
  11. Apparently, yes: Either a crash or planned shutdown could result in corrupted Diskid files because they were being constantly written.
  12. Chris, I've been using 2.5.4.3216 for a long time now, and it's working well on multiple installations, with this exception: Almost any reboot of my WS2012R2E VM, planned or otherwise, results in Scanner losing all its data. I've been making backups in advanced settings, but not regularly, so even though I can get back to tailored names, the scanning history is usually too old and requires all the drives to be rescanned. Do you think the disk id's being updated too often, as summarized above, would also be the cause of my problem? And 2.5.4.3246 could be the remedy?
  13. Thanks, Christopher. I agree. Currently, I have a SMART warning just for LCC, so I did permanently ignore it.
  14. CrystalDiskInfo worked fine so far to reduce the timing on Seagate. At least it will ease my mind even if the LCC isn't critical. I posted results at the pinned thread:
  15. Thanks for this tip! CrystalDiskInfo 7.8.3 x64 worked better for my Seagates than WDidle3 for WD, and I didn't even have to remove them from the server. Over a 5-day period of testing, one ST4000DM000 drive that had a LCC of nearly 250,000 in 2 years dropped to a rough estimate of 1 head park per 8 minutes after I set the APM midway at 80h, and the other ST4000DM000 that was sitting at 369,149 LCC had the park timing reduced to about once every 20 minutes when set to highest performance FEh. The first setting should result in an annual LCC less than 70,000, and the second should be less than 30,000 a year. It might not be critical to lower the parking rate in aggressive parking drives, but it should minimize Scanner's red flag for high LCCs that would otherwise be thrown, and it can be one less thing to be concerned about.
×
×
  • Create New...