• Content count

  • Joined

  • Last visited

  • Days Won


garycase last won the day on March 8

garycase had the most liked content!

Community Reputation

32 Good

About garycase

  • Rank
    Advanced Member
  • Birthday 12/22/47


  • Gender
  1. Filling disk1 and then copying all that data to another location will definitely cause it to be thoroughly tested -- you'll be writing the entire disk and then reading all of the data you've just written. I'd make a copy of the SMART results before and after you do this -- and then see if anything changed (other than the obvious -- i.e. it will have more power-on hours). At this point, I think it's likely that nothing will change and you'll simply confirm that your issue was the cabling.
  2. Deleting data doesn't cause any reads of the data -- it just updates the directory structure. Writing data also doesn't read it back unless you're using a tool that does verification.
  3. ... another thought: If you don't have space to copy all of the data, you could copy it in groups (as much as you have space for) ... and then just delete the copied files in-between copies until you've confirmed that everything is okay.
  4. What you really need to do is anything that will read all of the data -- and then compare the SMART results before & after the process to see if anything changed. That's essentially what the pre-read phase does, but as you noted you can't do this for a disk in the array. Do you have another disk in the array with enough space to copy everything to it? (or a disk somewhere else on your network) ... if so, just copy all of the files to that other location (put them in a folder called "TrashforTest" -- which you can simply delete after the copy completes. One thing that will NOT do is read the sectors that don't have data on them -- but from the tests you've done so far it seems reasonably certain that if you can read all of the data then the disk is fine.
  5. Looking good -- sounds like it was indeed the cable (or perhaps loose connections that were resolved by switching to the other cable).
  6. Did you ever change the cable? The simplest way to confirm if this is a cable issue is to simply replace the SATA cable with a high-quality cable and be sure it's firmly seated on both ends.
  7. Absolutely agree with Frank. BEFORE you do anything, run a parity check and confirm all is well before you start. Then you can Stop the array; unassign the parity drive; and restart the array so it shows that parity is "missing". Then shut down; replace the parity drive with the new one; and reboot the array -- when you Start it there will be a checkbox to click on confirming that rebuilding is what you want to do ... just check that and then it will update to the new parity drive.
  8. That should be fine, although I'd confirm that the "... some data on it " is data that's also on the array in another location. As long as you were COPYING, and not MOVING the data, then that should be the case; but clearly you don't want to format the drive and wipe out that data only to later discover it's not on any other disk at this point.
  9. You can always recopy them from your original discs ... but in the future you might want to start keeping backups as well, which are far more convenient to recover from.
  10. If the rebuild was stopped VERY quickly there's a chance some of the data could be recovered with xfsrepair -- but remember that the array is in an unstable state at this point -- it "thinks" there's a disk that needs rebuilt. I would do a New Config with all of the disk EXCEPT this disk, and let parity build. Then try xfsrepair on the new disk -- and if you DO manage to recover some files, then copy them to the array or, if you don't have space, do yet another New Config to add that disk and let it do another parity sync.
  11. The process you followed resulted in losing all of your data, and there's no way to recover it at this point. After you pre-cleared the new disk, if you had simply replaced the old disk with the new one, then the system would have rebuilt the contents of the old disk onto the new one. Basically this is what you eventually did -- but you first emptied the old disk ... so parity was updated to reflect those changes ==> and when you then replaced the old disk with the new one, the system dutifully did exactly what it's designed to do ... it started to rebuild the contents of the old disk onto the new one you just replaced it with. Unfortunately, the contents of the old disk were nothing ... since you had already removed all of the data from it. You can NOT add a new disk that contains data to an existing array. What you should have done, since you wanted to replaced a disk, was simply do exactly that -- replace the disk -- and UnRAID would have rebuilt the contents of the old disk onto the new one. But after you had already moved all of the data to the new disk, what you needed to do to preserve the data on that disk was to do a "New Config" ... and let the system then rebuild parity. Unfortunately, at this point you've lost all of that data. You'll need to recopy it to the array from your backups (if you have backups), or re-acquire the data if you don't have backups.
  12. No need to worry about the port assignments -- UnRAID tracks the drives by serial #'s, so as long as they're all available (i.e. plugged in to a SATA port) then the array will boot just fine.
  13. The most convenient method is to simply use the SetMax feature of HDAT2 HDAT2 is mentioned in the link above that outlines the issue, but it says you need a CD drive to use it -- that is no longer the case. Just download an ISO from the HDAT2 site; then download Rufus, and you can create a bootable flash drive that will let you easily run HDAT2.
  14. You can get thermally controlled fan controllers that would run the fans at low speeds most of the time, but would ramp them up when the drives got warm (you just put one of the sensors for the controller on a drive).
  15. Basically I just "fiddle". But I do run a lot of VM's to "play" with various OS's, and the new i9 seems like a really nice unit for that. However ... based on the above comments, I've been reading about some of the issues with the new X299 boards, and I may have to reconsider whether or not I want to do this. My original (pre-i9) plan was a high-end Xeon E5 setup for my next desktop -- and I may just stay with that.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.