micokeman

Members
  • Posts

    59
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

micokeman's Achievements

Rookie

Rookie (2/14)

0

Reputation

  1. Hello, Not sure if anyone can help, but I just updated to the latest build. (I believe I was on the build 5.1.0). I was able to transfer 4TB from one drive to another on 3 days ago, but after the update, transferring no longer seems to be happening. I select one drive in the 'FROM' column and one drive in the 'TO' column and then select all the folders. I go to the next stage and the page loads with all the stats, but transferring does not seem to be happening. It has no 'end-time'. Last time I did this I immediately saw '28 hours' to go. Now when I try to go to the UnRAID main page or the UnBalance page ("https://10.10.10.201:6237" or "https://10.10.10.201") I get "The connection has timed out". This has happened twice already. This last time was after a server reboot.
  2. I thought you just edited the title and added [SOLVED] in the front of it.
  3. Thank you! There wouldn't be much writing. Actually, there would be some deleting of duplicate files (same content, but named differently), but not adding.
  4. I am looking to replace upgrade a current drive from 3 TB to 5 TB. Due to a system freeze (which is another story) the machine had to get rebooted, so it started a partity "check nocorrect". The check returned this: Feb 27 12:57:15 VVData kernel: md: recovery thread: PQ incorrect, sector=18302032 Feb 27 12:57:15 VVData kernel: md: recovery thread: PQ incorrect, sector=18302096 Feb 27 12:57:15 VVData kernel: md: recovery thread: PQ incorrect, sector=18302104 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670056 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670064 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670072 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670080 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670088 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670096 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670104 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670112 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670120 Feb 27 12:57:22 VVData kernel: md: recovery thread: P incorrect, sector=18670128 It finished last night with this: Feb 28 18:53:45 VVData kernel: md: sync done. time=107974sec Feb 28 18:53:45 VVData kernel: md: recovery thread: completion status: 0 I then came in this morning expecting to replace the drive and found the partiy check at 30.5%! After flipping out and then realising that it was doing its monthly check, I looked at the logs an found this: Mar 1 00:00:01 VVData kernel: mdcmd (58): check Mar 1 00:00:01 VVData kernel: md: recovery thread: check P Q ... Mar 1 00:00:01 VVData kernel: md: using 2304k window, over a total of 4883770532 blocks. Mar 1 00:00:04 VVData kernel: md: recovery thread: P corrected, sector=60672 Mar 1 00:00:04 VVData kernel: md: recovery thread: P corrected, sector=60680 Mar 1 00:00:04 VVData kernel: md: recovery thread: PQ corrected, sector=60952 Mar 1 00:03:24 VVData kernel: md: recovery thread: PQ corrected, sector=18302032 Mar 1 00:03:24 VVData kernel: md: recovery thread: PQ corrected, sector=18302096 Mar 1 00:03:24 VVData kernel: md: recovery thread: PQ corrected, sector=18302104 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670056 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670064 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670072 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670080 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670088 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670096 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670104 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670112 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670120 Mar 1 00:03:28 VVData kernel: md: recovery thread: P corrected, sector=18670128 Mar 1 00:03:28 VVData kernel: md: recovery thread: PQ corrected, sector=18679960 Mar 1 00:03:28 VVData kernel: md: recovery thread: PQ corrected, sector=18679968 Mar 1 00:03:28 VVData kernel: md: recovery thread: PQ corrected, sector=18679976 Mar 1 00:03:28 VVData kernel: md: recovery thread: PQ corrected, sector=18679984 Mar 1 00:03:28 VVData kernel: md: recovery thread: PQ corrected, sector=18679992 . . . Mar 1 04:39:38 VVData kernel: md: recovery thread: stopped logging My questions are: Should I rerun the parity check with correct enabled before I replace the drive? Can I write data to the server while the parity is running? If I do write data to the server while the parity check is running, won't the parity check be off (since new data is now on the data drives) Should I wait to replace a drive until there are zero errors after a parity check. Thank you for any help!
  5. Excellent point! I never really thought about that. As it turns out, I have never purchased more than 3 drive in one shot, so I have been adhering to this without knowing I should, but thank you for that excellent pointer! Good tips there as well! Trying to decide how to go about both upgrading our current system and deciding if we should get a whole new system for backup. Or get a new system and use the current one for backup. I'll know by the end of the week.
  6. Thank you for your feedback! I will probably go with the 8TB drives. Not sure if red or black yet. "Rules"? What "rules"?!? Sorry, I really can't think of what you might be referring to. Perhaps, but you lose the expand-ability of the server.
  7. Thanks for that reminder. I've got a few threads I'm going to have to revisit once my restore is done. I can't really proceed to the next step until that is done, and that just takes... time! They are running about 40 C. That's a bit higher than the other drives. That brings up a REALLY good point! Hard to believe that there are 10 TB drives out there! (yes, I am a few years behind...) So it looks like Seagate has greater option for the 6-10 TB range. I am guessing that the Seagate IronWolf 6TB NAS is comprable to the WD Red. Since I am going to have to get quite a few new drives, I might as well get what I need in the long run. Am I correct that the currently $200.00 Seagate IronWolf 6TB NAS https://www.newegg.com/Product/Product.aspx?Item=N82E16822179004 drives are an good choice? I like to stay about one or two models back, if possible. That way hardware is already tested plus cost is usually reasonable for those older items. Hmmm, I was meaning to look into the multiple parity drives, as I just saw it available in version 6 (only recently upgraded). My understanding is that if I have two 8TB parity drives than that would be a good thing, no? Now up to two drives could fail without losing data. I take it that your idea is that the more drives I have, the great the chances that more than one will fail. Thus having 10TB drives... So I can either have less more costly drive with 1 parity drive or more smaller drives with 2 parity drives. So back to the Red vs. Black question... If starting new, would red or black be better? It seems that Red (Seagate or WD) would be best. Is that correct thinking?
  8. Would you be kind enough to either list or point me to a list of recommended hardware? I want to believe that unRAID will work in a business environment - my environment, specifically - but there was some hard drive failure and once that was fixed another problem happened and although there were individual issues that came up, my boss clumps them all together and 'wants a solution that works!'. Meaning two things, a solution that will have a mirror of the live data, synched via the internet to either a second unRAID or NAS and a data server that communicates well with Macs. So I am tasked to find that solution. Either unRAID or another solution. My feeling is that the drives are the culprit, which brings me to my next question. Would WD Red or WD Black drives be better? Sites seems to say that Black is basically Red+, but that Red is designed for NAS while Blacks are just faster - and yet WD Blacks https://www.newegg.com/Product/Product.aspx?Item=N82E16822236971 are cheaper on Newegg than WD Reds https://www.newegg.com/Product/Product.aspx?Item=9SIABZ053G6539. Are WD Blacks ALSO good for NAS devices? Another point that is worth mentioning is that we currently have over 50TB worth of data. I'd like to have a solution with about 80TB. Also, we will never have many users connecting simultaneously, but we will have a Windows and up to 5 Macs connecting. The Windows box could be taken out of the picture if I were able to get excellent transfer rates with a Mac. Any thoughts are eagerly welcomed!
  9. Thank you. Mine is set to 'Auto'. There has been to suggestions to convert my drives to XFS format. The large amount of writing to the drives is probably the problem.
  10. Thank you all for you replies and suggestions!
  11. So formatting each drive would be the best course of action? Edit: Thanks for that very helpful piece of information!
  12. Here is my diagnostics file if it will help any. vvdata-diagnostics-20170110-1152.zip
  13. Hey, thanks for your reply! I actually DID give up on AFP and started using SMB, but that started getting flaky and I about burst yesterday when I tried to save my Word, single page, document to the unRaid server (over SMB)mand it refused to connect twice and killed other FTP connections as well, so I started looking into AFP, but it sounds like that is worse. I am copying (via FTP) four files at a time and that will be going on consistently for a while as I am restoring data. Our files are usually over 50GB, so it will take a while. I feel like that should cause these connection issues, but it may be just that - too many connections at one time.
  14. Is that the same as "Tunable (enable NCQ):" I am thinking that something on my Disk Settings is not set correctly. I am at 4 GB and am researching the best settings
  15. Were you ever able to get AFP to work successfully? I am have real issues trying to connect my Mac machines to my UnRaid server.