Nick_J

Members
  • Posts

    15
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Nick_J's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Ah yes, right you are! I completely missed that subtlety! Thanks @ChatNoir!
  2. Thanks heaps @hoppers99! Have you tried with 6x SATA disks hooked up, as well as the 2x M2s? MSI's spec seems to read that at least one SATA port will be disabled in this configuration (SATA2 unavailable if M2_2 is populated, or both SATA5 and SATA6 unavailable if M2_3 is populated):
  3. Hey there @hoppers99, How did your build go? I've been trying to spec up my next build to replace my current server that's been running for 12-13 years. Pretty certain I'll be going with an LGA1200 CPU, probably an i5 just from a power usage perspective... but I'm having a real tough time deciding on a motherboard. I'm scared I'll have problems with Unraid. How did the MSI MAG z590 Torpedo go for you? Did it work out of the box, even the onboard network interface? It looks like the 2.5gbps NIC is a I225-V, which it sounds like Unraid supports fine in 6.9: Cheers, Nick
  4. Parity check completed with no errors found, so back in business! I also enabled turbo write mode and I'm seeing some much more respectable speeds. The first gig or two I'm getting 106mb/sec (ie pretty much maxing out the 1gbps network!), then seeing about 40mb/sec sustained thereafter. Thanks again for your help @SpaceInvaderOne and @itimpi!!!
  5. The parity check is still running, all looking good though! I just wanted to say - this is exactly why I chose Unraid many years ago. If what happened to me here had have happened on a normal RAID-5 array, chances are I would have lost everything. Even the 2TB drive which had been removed would not contain any useful data because the data would have been striped across the drives. So kudos for a great product!
  6. Very interesting indeed! That reads quite well - I'm going to give that a try after the parity rebuild completes (later tonight) and then the parity check completes probably tomorrow night/next morning.
  7. So copy completed in less than a day in the end. Average speed was around 25-30mb/sec. The 2tb HDD had 1.8tb of data on it. It was over USB 2.0. However in saying this - my array has always seemed to max out at about 25mb/sec sustained write speed. I get one or two GB in at about 80-90mb/sec, which I assume is Linux writing into memory cache before it fills and has to flush to disk, before it drops down to 25mb/sec or so where it remains indefinitely. I always assumed this was normal, without having a cache disk. Should I start a different thread about that issue with the diagnostic details to see if we can bump up the performance a bit? Regarding the issue at hand, I've kicked off the parity sync and it's proceeding nicely! It's way past where the UDMA CRC errors were hit last time (almost immediately, around the 700mb mark).
  8. Mate, you are an absolute legend! I've formatted (as XFS - looking at that as a bit of a bonus here!) and have started the file copy from the old 2tb drive. Gonna take quite a while by the look of things, over a day. In hindsight - it might have been faster if I disabled parity altogether as it looks like it's calculating it as it writes even though parity is marked as invalid? But all good, I'm patient. Once all the data is there, I'll kick off the parity sync. Will report back here as it goes! Thanks again SpaceInvaderOne!
  9. Hi SpaceInvaderOne, You are an absolute lifesaver! I've followed the process you described, and I can see all my data! Thank you so much! Now the only thing is it did not recognise that 6tb drive as not having a file system. It's quite odd, it mounted the drive and I can see files there but I don't have permission to any of them - even doing an ls fails to get permission detail back, although the files are listed. I'm assuming these are just pointers from the file allocation table or something to files which actually don't exist on the disk... the allocation table might have partially rebuilt during the data rebuild that ended up failing? I'm using ReiserFS still for what it's worth. I'm guessing I should somehow instruct Unraid to reformat this disk, and then once that's done, copy the files back from the old 2tb disk? I've installed Unassigned Devices and Krusader, and I've mounted this 2tb drive over USB (I'm maxed out my SATA ports) using Unassigned Devices. Cheers, Nick
  10. Hi everyone, I fear I've lost some data here. Basically I was carrying out the parity swap procedure. I had already copied parity (6tb) to the new larger disk (10tb), and I had started up the array and it had commenced a rebuild of the data disk (2tb) that had been replaced by the old parity disk (6tb). Shortly after the rebuild had commenced, it halted due to read errors being encountered on one of the other disks. I pressed resume, which may not have been the best idea. It then started speeding through at 2-3gb/sec which clearly was incorrect so I stopped the rebuild. There were a few UDMA CRC errors present in the SMART report of that disk. At this stage Unraid was reporting that disk (disk3) was missing. I figured it might have been a cabling issue, so I shutdown the machine and checked all the cabling and powered it back up. Now that disk is present, but is unassigned in Unraid. When I select the disk that was already assigned as disk3 though, a blue icon appears next to it indicating it's a 'New Device'. The array won't start due to 'Too many wrong and/or missing disks!'. Is there a way to 'remind' Unraid that that disk was already existing? Or is it a lost cause and I need to basically start a new array and cope with having lost the data on that disk (the 2tb one which was being rebuilt at least I still can mount outside the array and restore the files I guess)? Thanks, Nick