Jump to content
Covecube Inc.

Mick Mickle

Members
  • Content Count

    83
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Mick Mickle

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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 auto
  6. 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 automati
  7. 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 b
  8. Apparently, yes: Either a crash or planned shutdown could result in corrupted Diskid files because they were being constantly written.
  9. 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?
  10. Thanks, Christopher. I agree. Currently, I have a SMART warning just for LCC, so I did permanently ignore it.
  11. 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:
  12. 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
  13. I've been noticing this as well several times with V. 2.5.4.3216 in a VM when it restarts. I thought this was somewhat related to the thread for preserving data when upgrading, because I thought the json methodology would keep this problem from happening when a machine was turned off or crashed. (I referenced this thread over there as well.) Anyway, the backup/restore settings function works well, especially now that it uses one zip file. But...but...but... if you haven't backed up recently, your scanning history will be older than the 30-day rescan default, and all the disks will need to
  14. Thanks, Christopher. That's what I thought from earlier comments you've made. How about this question concerning "Ignore S.M.A.R.T. Warning" in Scanner?
  15. Well, I should have checked other posts here first. I see a lot of relevant conversation on the pinned thread here: So I'll try out some of what's discussed. And I see that the current (a few years ago, anyway) conventional wisdom seems to be not to worry about high LCC on aggressive-park designed HDDs unless other problem indicators develop. Still, it's disconcerting to see the out-of-tolerance measurements in SMART reported by Scanner. Note that the referenced thread above doesn't address the newer Seagate drives such as Iron wolf which use EPC. According to Seagate, most of
  16. I've got a couple of ST4000DM000 4TB drives that I'm using in my server (removed from original external USB enclosures). One is now over the 300,000 Load Cycle Count limit, and another is close to it. So, basically, they have the green WDC drive problem that WDidle3 fixes by changing the timing from 8 to 300 seconds. Seagate now has a SeaChest program that will change timing of newer drives that use EPC (Extended Power Conditions), but ST4000DM000 apparently predates EPC. Any ideas on how to minimize the load cycle count on these drives to prolong their lives?
  17. Ha! Got it. Just had to put my mind in 3D mode. If I'd ever experimented with hierarchical pooling (or even thought about it deeper -- no pun intended, truly), I would have realized we weren't talking about parallel level folders.
  18. If you've already moved them, there's probably no need to do it again. Umfriend was describing in "Wrt step 4" how to move the location address of the files within each individual drive (E: then F: then G:) rather than physically copying and deleting the files themselves. As you probably know, if you move a file, no matter how big it is, from one folder to another using Windows/File Explorer, the action is almost instantaneous since Windows simply points to the new location -- like changing the page number in the table of contents or index. You can do the same thing by moving files betw
  19. If I understand the Drive Usage Limiter Balancer correctly, the way you've got it set up, the local drives, E: - G:, will have no duplicated files; only unduplicated. Since you only have one drive, the Google Drive (J:), checked to hold duplicated files, I'm not sure what the effect is. I think you need to have at least two drives for duplicated files, otherwise you have no protection or reason to duplicate if one of the drives fails. Perhaps if you also check one of the local drives (the one with the photo folder that you want to duplicate) for duplicated as well as unduplicated, DrivePool
  20. I'll not convinced that the json file scheme is a panacea, yet. (I had a power outage crash while using json structure, and lost the settings - one of my posts above. Previous file/folder versions in properties didn't help either, although I did have previous versions.) Best bet, so far, is the new backup/restore in advance settings. And, "Yes", an upgrade warming is in order.
  21. You didn't say which version you upgraded from, but it sounds like it was 3062 or earlier (pre-json files); otherwise, you'd probably have already encountered this issue. Jaga gave you good methods above, but you will have had to have a backup from which to restore the folders where the prior version Scanner settings are. If so, uninstall the new version, make sure the Scanner service is stopped, restore the old data folders from your backup (any old backup date is good, assuming you haven't done major physical HDD changes in a while), reinstall your previously well working Scanner versio
  22. This probably should be a new thread, but it ties in with the new JSON structure and the new settings backup/restore feature. First, I had occasion to restore the settings after a power outage crash, and that was a valuable feature addition. However, I don't recall losing all custom disk and scan status settings before JSON even though I'd had crashes in the past. In this case, I had a 3-hour power outage caused by a storm, and Scanner installations on both my physical WS2012R2 server and its VM WS2012R2E lost all settings. Most of the JSON files had new file dates after the outage.
  23. Sorry to be negative, but I doubt if 3198 fixed it. I uninstalled 3191, copied my previous folders for 3062 back in place and reinstalled 3062: all disk settings and data were then back to normal. Then I went directly to 3204, since that has the new settings backup and restore feature, bypassing 3198. The result was that no settings were retained (except for 1 of 11 disks, oddly) and all disks needed to be scanned for the first time. (This time, however, I did a printscreen of my names & locations, and re-entered everything into 3204. I'll let Scanner rescan everything and just move
  24. Thanks, Christopher. It sounds like the problem is solved moving forward from 3090 and 3091. Still to come is data export/print capability for specific disk details, settings, and locations, some of which will be available in the future in Stablebit Cloud, I understand.
×
×
  • Create New...