Jump to content

bidmead

Members
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

2 Neutral

About bidmead

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. The catch about migrating ever upwards to these very impressively engineered huge drives is that we begin to run into one of the issues that drove us away from RAID: the rebuild time and the pressure this exerts on the reliability of the other drives in the array. With UnRAID, I'd have thought, much of the USP is the ability to use a large number of rather smaller drives, recovering from drive failure over a tea-break rather than during a three day vigil. And, particularly, if failing to recover, at least not losing data on the other drives of the array. -- Chris
  2. I pursued the rebuild of the Maxtor drive. But, as we might have expected, the work taxed the dear old drive beyond endurance. It failed the rebuild and UnRAID looped around several times trying the rebuild afresh until I put it out of its misery. I'm now running the rebuild on the second IronWolf Pro, which was always my original intention, to demonstrate that expanding capacity is a lot simpler with UnRAID than with, say, TrueNAS Core. -- Chris
  3. Interesting question, jonathanm, but I may not be the one to answer that. I have 40 years experience as an IT journalist, but only a month's experience of UnRAID. For what it's worth, it seems to me that "array turned good" was misleading once the physical drive was replaced. After all, what is the change from the previous state, emulating the missing drive, to the present state, emulating the drive but the drive is back in its slot? The goodness quotient hasn't changed: we're still emulating the drive and therefore sacrificing our insurance on all the other drives. The goodness is only restored once the physical drive has been fully successfully rebuilt. This should surely be a yellow alert, saying something like: Disk 2 emulated, rebuild required. Bottom line, though: the punter should alway keep an eye on the browser tab icon. If it's not a green ball, action is needed (or maybe ongoing). -- Chris
  4. Recommend to UnRAID management how the reporting of the replaced drive might be better handled? Or recommend to readers (as we certainly shall) that keeping an eye open for errors is crucial for a trustworthy NAS? -- Chris
  5. Excellent point, of course. But thanks to the small size the rebuild times are short, which is what I need if I'm going to get all this written up before the end of the year. I'm anticipating that the Maxtor will end its days as an unassigned device with a btrfs encrypted file system. Tested Technology is very grateful to Seagate for the donation of these very large drives, but we also want to show readers that UnRAID is good for older, smaller drives too. I take your point, of course, about failed drives jeopardising the entire array. And an array built entirely from 12 year old drives like this Maxstor would be unreliable. But the combination of UnRAID's clear test, its very explicit surfacing of the SMART data, the opportunity for regular parity checks and the option of running a pair of parity drives, to my (newbie) mind does open up the option to get into UnRAID very economically, mustering a bunch of drives that happen to be lying around to create something non-mission-critical like a multimedia server. -- Chris
  6. And, of course, you can happily insert a drive while the array is running---as long as it's not part of the array. -- Chris
  7. My newbitude is showing through here. We're not just rebuilding the drive, we're rebuilding trust across the entire array. -- Chris
  8. Sorry, trurl, I was late reading this. Yes, that's what I've done. Rebuilding now. -- Chris
  9. So we're saying the rebuild is mandatory. That seems to be a real shame. OK, I'm going to spin down the array, leave the drives physically where they are. Then restart the array in maintenance mode, unassign the drive from the Disk 2 slot. Then spin down the array, reassign the same drive to that slot and spin the array up again. It should then rebuild? I see "Replacement disk installed", which does suggest a rebuild is being triggered. And indeed... But this rebuilding of a perfectly good drive seems to me suboptimal. Is there really no user intervention that can say, trust this drive until the next scheduled parity check*? I assume a workaround would be to leave it as an unassigned drive and share it out from there. Any views on this? (*I guess the problem might be that if the reinserted drive is accepted into the array on trust as I suggest, it's not just the integrity of that drive that's at stake. The parity check across all the drives is in jeopardy.) -- Chris
  10. You're right, jonathanm. The drive is still marked as emulated. So what the green message is saying is "There are no read errors because I haven't actually read the disk. And if I do read the disk, I'll be reading the emulation, which by definition, won't have any read errors." So the question arising from this is how do we get the array to acknowledge the physical drive and use that instead of the emulation? -- Chris
  11. OK, I said I'd try a clean rerun of this without a) the senior moment about which drives are where and b) my misunderstanding of when you can hot-swap. This is that clean rerun. 1. I start with an entirely sane array. It's running but I then pull the Maxstor, simulating a sudden drive failure. 2. UnRAID flags the failure and straightaway goes into emulation mode. In this mode I'm able from my Hackintosh to tap into the (emulated) Maxtor share, use VeraCrypt to mount the encrypted disk image therein and play any of the multimedia files it contains. No buffering or glitches. Exactly as if the Maxtor were present. 3. The big mistake I made last time (I believe) was to plug the drive back in with the array still running. This appears to confuse UnRAID and it keeps using the emulated drive instead of the real one. This time I spun down the array before reinserting the drive. With the array spun down, UnRAID appears to recognise the returned drive almost immediately. I'm not clear how it does this. Is there a checksum of the whole drive somewhere on the Maxtor that corresponds to a checksum retained by the parity drive? What I've learnt here is that, yes, you can pull a drive while the array is running without affecting services across the LAN to client devices. But it's a good idea (probably mandatory) to spin down the array before returning the drive. And I'm assuming that if your hardware supports hot-swapping you should be able to follow all the similar procedures suggested in the manual but WITHOUT having to power down the machine. But do spin down the array. -- Chris
  12. This suggests to me that I should be able physically to stick these drives into any position in the 8-bay (remembering to spin down the array first) and UnRAID will carry on regardless. Is this the case? -- Chris
  13. You're right, jonathanm. With the Maxtor reinserted I did create an empty folder on the emulated drive in the hope that this would wake UnRAID up to the realisation that the drive was physically present. That idea didn't work and I think I now understand why. So, yes, the data on the emulated drive would now be different from the data on the physical drive. And, as you've predicted, what we're getting now isn't just a parity check, it's a Parity Sync / Data Rebuild. Currently at 40%---thank heavens this old Maxtor (circa 2009) is small. For my re-run I'll make sure a) only to pull and plug drives when the array is down and b) not to change the data on the emulated drive while Maxtor has left the building. Would I be wrong in that case to expect as smooth return to the status quo (no parity activity or rebuilding) when Maxtor makes his come-back? I'm truly grateful to you guys for sharing my pain here and steering me back to sanity. -- Chris
  14. I couldn't do much with maintenance mode. But now I know not to pull or plug drives while the array is running I think I've managed to re-establish the status quo. What seems to work is: 1. Shut down the array. 2. Pull the drive that claims to be emulated. 3. Start the array. The drive slot is now declared unassigned. 5. Use the pull-down to find the Maxtor and load that back into the slot. 6. Start the array. 7. Warning message: Drive not ready. Content being reconstructed. I'm hoping that "reconstructed" is different from "emulated" and that the drive's physical presence is now being acknowledged and some parity checking is going on. At some later stage I'm going to have to walk this whole sequence through again (Start with a solid array, pull a drive, check the emulation, replace the drive) to understand how it's meant to work. My grievous error (apart from my gross misreporting of which drives were where---apologies once again) was not grokking that UnRAID doesn't support drives being plugged and pulled while the array is running. Yes, it's parity syncing now and the physical presence of the drive has deffo been acknowledged. What I'm headed for next is replacing this small Maxtor with a much bigger drive and getting the Maxtor emulation pasted onto the new drive. But I'm going to run this pull, emulate, replace once more first. Oh, and I'm marking the drives externally so I won't get them mixed up again! -- Chris